You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job.

However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform.

HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.*

> Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed.

Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al.

> Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off.

Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.

I remember. I also remember there have been people arguing all along (back into the mid-90s, at least) that this document-centric approach has been totally unsuitable for a broader platform.

And yet, it's been more successful at delivering applications to the widest possible audience than any other platform. Why is that?

Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years. Then explain why you're certain that having a VM instead of a browser act wouldn't erode those advantages.

(This is the most important part of my comment. Feel free to ignore the rest.)

> HTML has fallen over in this context; > the DOM is ill-suited towards standard > re-usable UI widget programming,

I don't think the evidence is on the side of your claims. Given the sheer number of web pages and apps out there vs the number of desktop apps, the widgets built in to HTML are more widely used and re-used than most desktop API widgets, and the sheer proliferation of derived DOM-composite UI elements out there (particularly contrasted to the desktop) belies any claim of unsuitability for use: DOM elements are creatively styled and glommed together with a regularity that dwarfs anything from the desktop world.

That's use and suitability. Re-use? There are also several well-known and a lot more lesser known libraries that do indeed provide widgets at higher level of abstraction. JavaScript provides ample facilities for abstracting the DOM manipulation behind object and method calls. Whether or not it's used is another question, but any developer that can't learn to do that job in JavaScript either can't do it because they're unwilling to learn how to wield JavaScript, or because they'd be unable to do it with any language and API.

> JS is frustrating for building large applications

How so? There are plenty of developers out there who've found that if you embrace the features the language and most runtimes offer, it isn't any more difficult to build large systems with it than any other language. Though despite that, the language seems poised to embrace some of the features from others if for no other reason than to make developers who already know another language more comfortable.

> Moreover, Adobe Flash was not standardized

Standardized enough that the runtime was successfully targeted by a number of non-Adobe products.

> the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

And of course, our shiny new standard VM will avoid all these problems over its lifetime. ;)

> the performance profile is tremendously bad on mobile devices

It's actually better than I'd expect in a lot of cases, but it's true that it's not good enough for a lot of kinds of apps. But the language is not what's causing the problem, so adding other languages won't fix it, and might introduce other problems.

Ubiquitous cross-platform adoption. Done.

The web grew popular (relative to the Internet population) before it got JavaScript, not after. It wasn't JavaScript that drove widespread adoption, and it wasn't applications built in JavaScript.

Well, that's at least part of the reason why we disagree. The list is longer, and includes (but may not be limited to):

* view source - up until minifiers, there wasn't anything happening on the client side that you couldn't see how it was done yourself.

* gentle learning curve - the entry level to simple web publishing was achievable for anybody who could transfer "view codes" style word-processing concepts to markup and manage file transfer client. A little learning or some copy and paste could take you up the next gentle step to limited scripting.

* Hypermedia nature of the platform - instead of applications being little silos that only interoperate with a relatively small number of apps from the same organization (or other organizations where they've made deals), hypermedia docs were a sprawling web of connections constantly pointing to other document-applications. If you'd dropped a perfect universal VM on every desktop in 1995, it's extremely unlikely things would have fallen out like this. It certainly didn't for the imperfect one.

> The web grew popular (relative to the Internet population) before it got JavaScript, not after. It wasn't JavaScript that drove widespread adoption

A 1995 release means that the first statement is only defensible given the flexible nature of popular. The second statement is truer in decreasing terms through 2004 or so, when it bottoms out.

That's tangential, though. The real question is more along the lines of whether the web would be everything it is now if instead of passing around a single strain of fairly standardized (though expanding over time) markup, we instead were sending drawing instructions and collecting events. Or maybe even a single binary-encoded standard for abstracted document trees designed for optimal machine consumption, generated from various different applications or compiled from other document schemes.

Their answers to that question are why a lot of people think it might be a better idea to have single scripting language, and the one we've got has turned out to be pretty capable so far.