Two problems here worth calling out: even when the forms packages worked, they produced apps that looked like crap. HTML is worse in this regard, you get poor quality mobile apps (imagine if your app needs an interactive map...JS maps are terrible in mobile browsers), and you have a bunch of places where JS/CSS/HTML/XHR differs b/t browsers and it's painful to get them all working.

Second problem, at least initially, I'm sure it's better now, was JVM implementations in the mid-90s were not super consistent and you'd run into runtime issues that were difficult to work around.

Are you arguing WORA with Applets worked and moved the industry forward? Flash pretty much took over this charter but even then getting performance on many devices out of a Flash runtime was pretty damn hard, so even it fell down on this.

Much better to have a shared core (if you can) and write customer-centric, awesome device-native UI experiences.

I think some abstractions are more enduring than others. At one point everyone wrote assembler, then C came along and offered a write once and run everywhere. It so happened that C nailed the performance / expressiveness efficient frontier and created a world where people arent writing assembler anymore.

The question I find interesting in this context is - is it possible to write a rendering pipeline and UI toolkit all the way down in a garbage collected language that is performant. It appeared that we in industry have taken a step back and are now content with the bottom layer being all native. I dont know if its because the Sun UI team didnt have the right people or if the abstraction of a garbage collected high level language does not scale down to writing graphics apis.