Hacker News Reader

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...

and

https://www.dartlang.org/articles/why-not-bytecode/

from the Dart team. See also

http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web...

from Alon Zakai of Mozilla.

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.

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.

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.

> Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth.

I've always wondered: why not LLVM? It's low-level, so the speed is there, and I think should be trivial to compile as it arrives at the browser. Tons of stuff already compiles to it. You can compile it to JS. Of course, you'd need to make sure it doesn't make a syscall that's not allowed (and I'm not sure how hard that is), and that it has bindings into JS APIs and/or the DOM, but aside from that…

I'm sure some people will suggest things like the JVM or the .Net CLR, but I feel like those have certain qualities (e.g., GC) that don't appeal to all languages.

I have been wondering the same thing. JS might be a good language. But we should still have a choice to choose other languages.

I'm seeing efforts with asm.js turning JS into a byte code language aka. LLVM IR. I'm not sure if turning JS into a byte code language is the best way either. It is still too high-level language. And it seems like a ugly hack.

> I've always wondered: why not LLVM?

Because LLVM is not hardware independent.

Also, LLVM IR has undefined behavior and was not designed as a network format (it's large).

LLVM is simply not a good starting point for the problem here, nice as LLVM is for what it does do well.

That didn't stop PNaCl. (Which has its share of problems, of course, but I think it makes the hardware dependence meme pretty moot.)

PNaCL is probably closest to what you want.

There was a talk by Matz about ruby 2 and how they were tweaking the runtime to improve garbage collection. I don't remember the details but a lot of work went into seeking the best collection behavior to match the language, optimizing for the most common cases, checking the patterns favored by the language and tweaking the behavior to ease these cases, etc.

The intersting thing is that there's jruby for the JVM, and it makes the different tradeoffs surface better. Looking at this benchmark for instance [0] it's easy to see how the tweaked runtime gives a very different performance profile from the generic VM.

I have a feeling the highish-level intermediate layer you are talking about would be equivalent to have only some specific tradeoffs despite the optimizations that could be done on a language per language basis.

[0]http://benchmarksgame.alioth.debian.org/u64q/jruby.php

Agreed. A more generic VM seems the way to go.

.NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc

I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.

Spelling is hard on my cellphone. Would be nice to have a longer editing window.

Synchronization primitives are being suggested for addition to JS,

https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...