Holding to as brief a reply as possible given short time to write it (apologies to Blaise Pascal): * Python 1.3, stripped of most of its C extensions, may have

Holding to as brief a reply as possible given short time to write it (apologies to Blaise Pascal): * Python 1.3, stripped of most of its C extensions, may have been substantially better than JS1, I grant -- that was your digression and straw-man, not the point of the text to which you replied. I do dispute that a forked-and-stripped Python 1.3, slowly evolved thereafter, would be materially better than what JS became. Just consider whitespace-based indentation vs. minification, for one issue. * I'm very well acquainted with the sunk-cost fallacy. But that is not why JS endures. JS endures because given the scale of the Web and the consequent backward-compatibility imperative for browsers, the switching cost is extremely high for web developers and browser hackers. The cost of adding a 2nd runtime faced by browser hackers is also high (but less high). Most important, the conserved evolutionary-kernel of JS is "good enough" (worse is better, look it up -- sorry about the warts but not sorry, we have to deal with the world as it is). Therefore no browser (not even Chrome yet) has both the means and the motivation to invest lots of megabucks in engineering high-performance, multiple language runtime tenants sharing the DOM and the rest of the browser APIs. Compile to JS sucks away the oxygen from any such boondoggle. There are multiple Python-to-JS compilers out there. With modern JS (both language and VM-level optimizations), you can get higher fidelity Python this way than you would have by forking and freezing Python 1.3. * XHTML2 was revolution, not evolution. It proposed to replace HTML on the web, not even interoperating well with HTML via the DOM, before we founded the WHATWG and did HTML5. HTML was originally an SGML fork that, as it evolved, bent or violated lots of SGML rules in favor of flat vocabulary, ad-hoc error correction, implicit content models (I perpetrated implicit CDATA for <script>), and worse-is-better. XHTML would yellow-screen-of-death if it didn't validate, and because IE loading the most popular MIME type would error-correct as HTML, even hard-core XML purists would commit errors to published content, unaware. This plus the better-is-better overhead and complexity of authoring XHTML (XML namespaces in particular) led to ~0 adoption. * On me vs. Dart, as on your assertion that multiple runtime integration is much less complex than unstated Mozilla work, you have yet to cite sources. I'm bored by such cheap shots, so will wrap up here with a few thoughts about Dart and its opportunity costs. Feel free to have last words. If you care to read my past HN comments, I railed against the Google "Dash" memo for being two-faced about "we <3 JS; we must REPLACE JS", about the latent and very large conflict of interest for Google as self-congratulatory standards bearer: investing in Dart at the expense of JS. Indeed Google has probably sunk tens of millions into Dart with very little to show for it. Elsewhere here, you asked or assumed that Google uses Dart in its web properties. Does it? So far, I hear it does not, and I've asked Googlers. You should not assume. UPDATE via twitter, thanks to @rightisleft -- some Google services use Dart now: https://www.dartlang.org/community/who-uses-dart.html https://www.dartlang.org/community/who-uses-dart.html This means dart2js, which means Google should've already helped get bignums into ES6 :-|. END UPDATE LOL Dart cost Google some V8 competitiveness, vs. other engines. The whole Aarhus team (except for moonlighters) switched to Dart; a new V8 team had to be recruited in Munich. You could say it's Google's choice on how to invest, and of course I agree, just considering business ethics. But not for "Google the good" as standards bearer. There, the effect on JS standardization and real progress vs. the feared/hated mobile native stacks' languages (C++, ObjC on iOS) -- by such evolutions as asm.js/WebGL for games, and something like SoundScript for larger hand-coded apps -- was significantly delayed. Big companies can work for and against the grain of the web. Elsewhere on this thread, a commenter replied to me about how ActiveX went against the grain (very true). Stuff like NaCl, Pepper, and Dart run the same wrong way, at first and even in the long run -- whether open source (open-washing a project dominated and controled by paid contributors is a hazard, even at Mozilla) or even de-jure standardized (Ecma is pay-to-play). The only way they'd get into other browsers is via market power of the 95% monopoly share kind that IE enjoyed around 2002. Anyway, that's why I railed against the "Dash" memo. The delay in reconstituting the V8 team, and in coming up with something like SoundScript instead of Dart, is relevant to this current thread. If the topic of what's both practical to evolve from JS, and better for developers over against compile-to-JS approaches, is worth arguing about, then I'll argue that Google let the world down by doing Dart. Evolution delayed, but not denied, still hurts. I'm glad to see the new V8 team proposing experiments like this one.