Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing.

Nor do we all buy the same make and model of car. That's implementation monoculture.

Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake.

Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives.

Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout).

Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!).

Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?).

So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5).

Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency.

Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow.

Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit:

https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

I'm mostly being descriptive so far, but let me prescribe:

Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper.

That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS.

Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines.

I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed.

/be