First, jashkenas isn't held up by standards committees -- he's able to experiment with cool new client-side web tech on whatever schedule he wants. And building on this, even more new stuff is happening, like Tim Disney's contracts.coffee [1].

Second, your ability to ship the coolest new client-side technology isn't being held up by TC39, or by the HTMLWG -- nothing we or they could do would make MS ship IE 9 for XP (or make people upgrade from Debian Stable :).

Third, the reason that design takes a while is because it's hard. I'm really glad that Dave Herman and I haven't iterated the ES6 module design in shipping versions of a browser -- that's not the right thing for anyone.

Finally, you mention Scheme. If you want to see a truly disastrous example of language progress held up by politics, check out the last 5 years of Scheme standardization.

[1] http://disnetdev.com/contracts.coffee/

I guess I was wrong when I said every browser innovation. I also, more or less, agree with your other points - my goal wasn't to bash HTMLWG but to point out that the standardization of a lower level api will help us skip some of the other parts of the standards process by allowing us to do things like compile an sql library directly. Design is indeed hard, but with people free to implement different alternatives, it can happen in a distributed way with more possibilities explored even in production systems. Of course, something as basic as a module system should definitely have a standard. Which would also lead me to agree with your comment on scheme standardization while noting that some of the experiments with first class environments and f-expressions seem to be a genuine exploration a new part of the design space and not a gratuitous incompatibility, but maybe the standardization process should ignore them for the time being.

Quick comment: lower-level APIs can be harder to standardize than higher-level ones, depending on the diameter of the API-set and the implementation dependencies. Running native binaries requires a new compiler and a bunch of runtime API support (Pepper).

OTOH adding typed arrays or binary data to JS is narrowly targeted and pays off for higher-level API builders. And the typed arrays and binary data specs are being standardized.

You have me wrong: NaCl is great, perhaps as near to ideal as it can be (it's still nowhere near "done"; it's experimental where it isn't in DLL hell, libc hell, "portable" LLVM bitcode hell, etc.).

The quality of the NaCl work is not the problem.

The problem is that none of the other browser vendors can or will afford to get on Google's treadmill, trust Google as much as they would have to, then try to implement Pepper (for which the code is the spec, including bug for bug compat), take on all the toolchain dependencies, and hire people to co-maintain on their own release schedules. Not gonna happen.

The OS-specific toolchain-and-runtime alternative looks likelier to me. It solves the distribution problem, sinks the costs at the OS vendors, and avoids requiring coordination at the price of the safe plugins still being OS-specific binaries (which we live with today).

Another problem I have with your comment is the hope that innovation speeds up when we have more native-code plugin options. I doubt that greatly.

Web developers can choose different tools today, but their complexity is mostly confined to the server side and to the development lifecycle there.

Moving some or all of this complexity to the browsers via a large and growing menu of "DLLs" that are required to be downloaded along with primary app source? No way. Remember, the whole gambit of NaCl requires the humongous and messy Pepper API, the API that is nowhere near standardized or ready (or able) to be standardized, which non-chromium.org browsers are not going to support.

It's like the >1000 MS-COM interfaces that ActiveX plugins can and do use in old IE versions.

My bet is that the client side will not grow to look like your random Apache installation with (magically memory- and control-flow-safe) multiple programming language DLLs lying about. We may get to a post-JS future but it won't be that Tower of Babel, not on the client -- especially not on the mobile client.

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role.

Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming language and the ability to compile to a reasonably low level target for performance while still being cross-platform. Now, this somehow needs to be done without the security nightmares of ActiveX plugins. (Though, I dont see the non-security problems with a bunch of shared libraries stored on the browser. This is essentially what the OS does, and my goal is to replace the OS with the browser. Bandwidth will probably improve so that downloading libraries shouldn't be a problem and if not, the web site maintainer can still choose not to develop in a large library environment The popular ones will be cached in any case.)

You seem to be saying that the technical difficulties of doing this in a well-specified (memory and control-flow), secure and cross-platform way are intractable. Maybe this can be solved by moving the VM to a more abstract level.

I don't know how to be more clear. I'm not talking about the technical difficulties by themselves, out of context. The technical difficulties are formidable -- but not insuperable for Google with its many engineers.

I'm saying that in context of market realities, the other browsers won't use shared Google-source as the "implementation is the specification" for NaCl/Pepper, and no one can write a real NaCl/Pepper spec by which any browser could implement an independent and interoperable workalike in less than decades.

So why try if the OSes can do their own non-interoperating workalikes? (And they are already doing this, from what I hear.) If safe native code on the web is mainly for plugins, there's no problem. Plugins are OS-specific today and likely to remain so, safety or no.

Moving the Web VM to a more abstract level... hmm, sounds like JS as better compiler target over time. See also https://github.com/kripken/emscripten/.

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

In the very long run, could OS-specific CFI enforcement toolchains and runtimes merge into a single standard, usable on the web?

Maybe, but that is beyond my prediction horizon. Either OS vendors or browser vendors (if there's a difference) would have to standardize a butt-load of APIs.

Since the '60s, researchers have dreamed of universal object files (ANDF, e.g.). It would be too funny if far-future JS merges into this single standard too!

("too funny" in my experience means this will definitely happen...)