3 ms·

Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of t

Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of them in top JS engines. Starting fresh would take many more than two years, and very likely end in tears. This assumes browser vendors could spare the effort to do JS and the new thing (most cannot, even Google arguably can't). For why the best VMs are focused on one language, see https://www.dartlang.org/support/faq.html#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart https://www.dartlang.org/support/faq.html#q-why-didnt-google... and https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/ from the Dart team. See also http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web... from Alon Zakai of Mozilla.

lorddoig 12y ago
Those links are very interesting, I didn't know it was such a common question. However I still wonder - is bytecode the only way to go about this? Every compile-to-JS language I've used has either been sugar over JS or had JS's semantics/syntax seeping through the cracks...what if the base language was a Lisp? There's a big difference between being bound to the semantics of a language like JS or dart and those of Lisp. I have no doubt that a new VM would be a herculean undertaking and be riddled with all sorts of problems, but I remain unconvinced that it wouldn't pay off in the end. Maybe I'm being naive, but if what we're doing now really is as good as it gets then it seems either I'm much more ignorant to the issues at play than I thought or this hole is significantly deeper than even I imagined.
- BrendanEich 12y ago
  JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39. Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.
  - WorldWideWayne 12y ago
    Slowly evolving a huge platform to keep backward compatibility at all costs is how Microsoft runs many of it's properties. At some point I think an Apple is going to come along and take a byte out of the HTML/CSS/JS hegemony by introducing a new type of browser that is easier to build applications with. At least I hope so! As long as the web remains a broken mess of designed-by-committee compromises, I think there will, at least, always be some motivation to invent a replacement. Maybe you disagree that what we have is broken, but maybe you also know too much to think that building something new is a good idea. Many people have succeeded though, by being ignorant of the fact that X seems like a bad idea to the experts.

lorddoig 12y ago

Those links are very interesting, I didn't know it was such a common question. However I still wonder - is bytecode the only way to go about this? Every compile-to-JS language I've used has either been sugar over JS or had JS's semantics/syntax seeping through the cracks...what if the base language was a Lisp? There's a big difference between being bound to the semantics of a language like JS or dart and those of Lisp. I have no doubt that a new VM would be a herculean undertaking and be riddled with all sorts of problems, but I remain unconvinced that it wouldn't pay off in the end. Maybe I'm being naive, but if what we're doing now really is as good as it gets then it seems either I'm much more ignorant to the issues at play than I thought or this hole is significantly deeper than even I imagined.

BrendanEich 12y ago
JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39. Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.
- WorldWideWayne 12y ago
  Slowly evolving a huge platform to keep backward compatibility at all costs is how Microsoft runs many of it's properties. At some point I think an Apple is going to come along and take a byte out of the HTML/CSS/JS hegemony by introducing a new type of browser that is easier to build applications with. At least I hope so! As long as the web remains a broken mess of designed-by-committee compromises, I think there will, at least, always be some motivation to invent a replacement. Maybe you disagree that what we have is broken, but maybe you also know too much to think that building something new is a good idea. Many people have succeeded though, by being ignorant of the fact that X seems like a bad idea to the experts.