4 ms·

Javascript has several disadvantages that make it less than ideal as a general compilation target. * Javascript is verbose because it's plain text and was 'opt

by mafribe 11y ago

Javascript has several disadvantages that make it less than ideal as a general compilation target. * Javascript is verbose because it's plain text and was 'optimised' for human readability, rather than machine-parsability. That means parsing Javascript is expensive, too expensive for high-performance applications. * Javascript's being a dynamically typed language means a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML. Likewise, JS allows us radically to modify the behaviour of even built-in objects such as arrays. All this prevents the Javascript JIT compiler to optimise as aggressively as we'd like. * Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.

aardvark179 11y ago
Your third point isn't just a problem with translating Javascript, it is a problem in the VM designs (because it's much faster to support the required dynamism if you don't need to worry about concurrency). For me one of the most interesting things about web assembly is that it ditches so much of the current JS VM requirements that it finally allows for a path toward multi-threaded concurrency. It's going to be a long road to get high level languages on there (because I'm not sure I want to implement optimising method dispatch & GC in web assembly, and I predict those will take some time to arrive in wasm itself), but it is at least a start.
- mafribe 11y ago
  I agree with this. Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.

by mafribe 11y ago

aardvark179 11y ago

Your third point isn't just a problem with translating Javascript, it is a problem in the VM designs (because it's much faster to support the required dynamism if you don't need to worry about concurrency). For me one of the most interesting things about web assembly is that it ditches so much of the current JS VM requirements that it finally allows for a path toward multi-threaded concurrency. It's going to be a long road to get high level languages on there (because I'm not sure I want to implement optimising method dispatch & GC in web assembly, and I predict those will take some time to arrive in wasm itself), but it is at least a start.

mafribe 11y ago
I agree with this. Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.