|
|
|
|
|
|
by mccr8
4532 days ago
|
|
|
> What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it If nothing else, Mozilla does not have nearly as much money as Google, and really cannot afford a "tear down everything and rebuild it" approach like PNaCl. An advantage of OdinMonkey is that it is able to reuse a huge chunk of the SpiderMonkey infrastructure. If you look at the diagram in the article with the red arrow, the "Ion-compile" step is the same size as the others, but in reality is a huge number of line of code, representing multiple engineer-years of ongoing work. Much of the work the article describes, such as parallel Ion compilation, was carried out mostly for the benefit of non-asm.js compilation, but because OdinMonkey shares the infrastructure, it was able to benefit from it without having to create a new implementation from scratch. Beyond the engineering of the implementation itself, asm.js itself is a natural evolution of Emscripten-style JS, which had already successfully demonstrated that it can be used for large applications, and that other non-Mozilla browsers are interested in it enough to have done optimization work for it. This reduces the risk that the design itself is technically broken in some way that wouldn't be apparent until people try to run large production-ready applications, as well as the risk that only Firefox will ever be able to run asm.js code at a decent speed. |
|
|
The rest of your post is spot-on, but this part isn't really true. The barriers to "tear down everything and rebuild it" are much more systemic and less monetary (just look at the small JS engine teams that got us where we are today).
Meanwhile, Mozilla Research certainly continues to grow, and Rust is a perfect example of a "tear down everything and rebuild it" project now run by them, albeit in a different domain than JS.