3 ms·

It seems like the root of this entire problem is that Javascript is single-threaded, but current browsers want to be multithreaded (and specifically to do rende

It seems like the root of this entire problem is that Javascript is single-threaded, but current browsers want to be multithreaded (and specifically to do rendering and scrolling in a separate thread). 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.

iainmerrick 9y ago
To clarify a bit: the passive event listener idea is a good start because it means the scrolling thread doesn't have to block on the main JS thread. 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.
- mnarayan01 9y ago
  Consider the need to block on e.g. the DOM.
  - iainmerrick 9y ago
    Multiple threads have to synchronize their DOM reads and writes, sure, but that doesn't mean all access needs to be single-threaded. 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. :)
deleted 9y ago
[deleted]
lallysingh 9y ago
Webworkers lets JS be multi-threaded.
- iainmerrick 9y ago
  Web workers are isolated. They can only do computations and return results asynchronously to the main thread. You can't use a web worker as a DOM event handler.
robocat 9y ago
The issue is that the browser is waiting for a return value from a called event function. The browser changes its behaviour depending upon the return value. Singlethreading versus multithreading is irrelevant.
- iainmerrick 9y ago
  It's not irrelevant, it's right at the heart of the problem! 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.

iainmerrick 9y ago

To clarify a bit: the passive event listener idea is a good start because it means the scrolling thread doesn't have to block on the main JS thread. 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.

mnarayan01 9y ago
Consider the need to block on e.g. the DOM.
- iainmerrick 9y ago
  Multiple threads have to synchronize their DOM reads and writes, sure, but that doesn't mean all access needs to be single-threaded. 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. :)

deleted 9y ago

[deleted]

lallysingh 9y ago

Webworkers lets JS be multi-threaded.

iainmerrick 9y ago
Web workers are isolated. They can only do computations and return results asynchronously to the main thread. You can't use a web worker as a DOM event handler.

robocat 9y ago

The issue is that the browser is waiting for a return value from a called event function. The browser changes its behaviour depending upon the return value. Singlethreading versus multithreading is irrelevant.

iainmerrick 9y ago
It's not irrelevant, it's right at the heart of the problem! 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.