This should come as no surprise. It has always been an epic architectural mistake to use the same single non-reentrant Javascript engine to both render the UI and run JS for webpages in Firefox. This change will finally undo that huge mistake made so very long ago.
JavaScript was little more than a toy scripting language used to animate stuff and change layouts when html/Css wouldn't fit for the greatest part of firefox's early existence. At the time it was probably the appropriate decision.
Now, it's a huge burden on Firefox and it's good to finally see progress on this front.
> JavaScript was little more than a toy scripting language
No, back then Mozilla was trying to do the entire UI logic in JS. That was the whole point behind reusing the same JS engine for both: https://en.wikipedia.org/wiki/XUL
Since Javascript is just a language that happens to execute client-side within the browser, why can we not use an existing language syntax (or an existing language entirely) for this purpose? For example, Go, Python, Rust, or perhaps Perl? It feels like a broken shell scripting language that really should have been replaced.
You can, but you should not run the UI script code on the same non-reentrant JS engine that executes scripts delivered from the internet at large.
By doing so (running both the UI code and scripts from the internet on the same non-reentrant JS engine) means that only one gets to run at a time (either UI code or JS from the internet). That's why FF's responsiveness sucks at times, any long running JS script from the internet also prevents the UI code from running.
The JS engine should either have been reentrant (so UI code could run even though some random internet script was still running), or there should have been two independent JS interpreters loaded, one used for the UI code only and a second for all the JS from the internet.
Since the introduction of ES2015, JavaScript has actually been a really nice language to work with. It's been really well implemented and optimized by browsers lately. So I don't really see a good reason to switch languages suddenly. That being said you'll probably be able to compile and run all sorts of languages for the web with WebAssembly in the near future.
Multi-processing is an orthogonal issue to single-threaded JS.
The same asynchronous logic used to have multiple browser engines with multiple JS runtimes talk to each other could also be used for multi-threading while making shared, thread-safe datastructures of non-JS parts much easier.
Yeah, I never understood why they did it, it was obvious a single unresponsive tab would block the whole browser, but I guess fresh blood at Firefox needed to gain experience...
