4 ms·
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
by 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 agoI 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.