Does JS need to be single-threaded? I wonder if browsers could speculatively run JS event handlers in multiple threads, then block and transfer to a central "main" thread iff they mutate any global state.
Modern browsers use separate threads for Javascript and rendering. But if you have a (non-passive) scroll event, the rendering thread has to block on the Javascript thread, and that's why scrolling is janky.
But it seems like a big use of scroll handlers is to reposition some elements on the page, e.g. for parallax scrolling. Ideally that should synchronize exactly with the rendering thread, so elements don't jiggle slightly out of position as you scroll. The best way to do that is to run the scroll handler in the scrolling thread -- as long as you can avoid waiting for another thread.
I guess what I have in mind is roughly like managing DOM and JS state via STM, and speculatively parallelizing the JS. I don't know enough about STM to know how well it works out in practice, and for what kind of workloads. The goal would be to improve JS latency (ability to run small functions quickly) even if it reduces throughput.
This is all pretty speculative, I realize, I'm just wondering if there are obstacles beyond all the obvious ones, like having to rewrite the entire JS and DOM implementations. :)