It's interesting you mention Web Audio, because Web Audio, AFAIK, is based on a tried and true mature Audio API (Core Audio on OSX, Chris Rogers worked on both) that has had tons of feedback from the professional audio community for years. I wonder, how much of the objection is based on Mozilla because their counter proposal to essentially delegate DSP to JS was rejected?

And how do you define working in the open? Isn't dropping design docs and sample implementations into open repositories, and then iterating on them in public, open? Asm.js was just dropped like a bomb on everyone. When they announced it, they had running code already, and V8 at the time ran it very poorly. When Mozilla announced their Device API effort, they completely avoided the parallel W3C effort at first (I don't blame them) There's a kind of bizarre mismatch in the treatment between Google's work on projects in the open, and Mozilla's code dumps which get a pass.

The specs-first-implementation-second approach is IMHO a ret-con of how things are done in the industry. Rough consensus and running code is the usual model. You need experience from implementations in the wild to inform the specification, feedback from actual people trying to develop applications or implementations. Pretty much everything that went into each revision of OpenGL started life as a "behind closed doors" OpenGL extension, that was subsequently generalized, and incorporated into the base spec.

We tried the "do everything at the standards committee level first" in the 00s at the W3C and the Web stagnated. XHTML, XForms, XSL, XPath, XPointer, SVG, SMIL, on and on. A long list of mostly failed standards that took forever to get standardized, and by the time they did, the world had moved on. Really, only SVG remains viable and the spec is crazy complex.

Look at how C# evolved vs Java. Java worked via a community process "don't break existing semantics", and as a result, we got really shitty generics, and hardly any improvements to the bytecode or VM. Microsoft took a shotgun to C# 1.0, and as a result, IMHO, C# 3.0+ is way better than Java.

Frankly, I don't believe Javascript's semantic model can be evolved without breaking backwards compatibility. For example, Javascript is fundamentally single threaded and non-shared memory, yet today's devices, even mobile ones, have 2-8 cores on them. You can introduce shared memory, but then what, how do you implement concurrency primitives? You're retrofitting a memory model into a language that didn't have one, unlike Java which introduced the JMM early on. To me, Javascript's memory and execution model makes it fundamentally incompatible for something like an intermediate representation for portable code for high performance games. Yes, the demos are impressive, but who is going to ship Infinity Blade 3 as asm.js on mobile if there's a native OpenGLES API? The TC39 committee is essentially operating with design constraints that inhibit solving real problems with the language due to concerns with backwards compatibility. It's mostly syntactic sugar.

Everything has to start somewhere. Java started out from zero, backed only by Sun. C# as well. A whole community of libraries and tools had to be built. All languages go through this process.

I work on GWT, it outputs JS, so I understand the power of leveraging existing libraries and toolchains. But there are always pioneers and early adopters who want to work on fresh new platforms and throw away existing paradigms. Why oppose them?

I think it is important for people to sometimes ignore what exists and see what can be done if you start from scratch. That's how we get breakthroughs instead of incrementalism.