4 ms·

> There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple It might k

by skohan 6y ago

> There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple It might keep things simple, but I don't know if this is really a sensible design constraint going into the future. Parallelism is where performance is going to come from in the future, and having the web - the most common way most people consume software - be single-threaded seems like a massive waste of hardware. If I have a 16 core processor just so the add trackers in each of my chrome tabs can run in parallel, this is a world I don't want to live in.

girvo 6y ago
Genuine question, what would the ad trackers be able to do with runtime level parallelism in the JS runtime that they can’t achieve now? Do they do a lot more blocking calculation than I’d expect?
- vbsteven 6y ago
  Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked.
  - MaxBarraclough 6y ago
    > Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. I agree that it's a neat idea to use asynchrony to move specific heavyweight browser-native computations out of the JavaScript thread, but is JSON parsing really a significant performance issue? > JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. I'd rather parallelism not be a viable option for accelerating trackers. Users are known to hate unresponsive UIs. I'd rather that web trackers bring an unavoidable performance penalty. > Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked. You've just described the Web Workers API. I don't know whether today's tracker scripts use Web Workers. I imagine probably not though, I think the Web Workers API is only appropriate when you're doing substantial computation.
resonantjacket5 6y ago
There are going to be webworkers which will allow you to use more than one thread. (Though it is technically a browser implementation so it'd be up for the browser to implement/allow it)
hajile 6y ago
JS is not single threaded in the way you indicate. JS parsers, compilers, and even some garbage collectors are threaded. IO (arguably the most common case for threads) is threaded behind the scenes. Web Workers allow using multiple cores/processes for typical parallel programming. Message passing exists as do shared memory and even atomics (note: node, firefox, and chromium-based browsers all have it available after Spectre/meltdown mitigations were added, but it's still disabled in Safari). What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware and let the VM handle them seamlessly like in Erlang/BEAM.
- MaxBarraclough 6y ago
  > What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware What kind of website would benefit from this?
  - pjmlp 6y ago
    SPA and PWAs.
    - MaxBarraclough 6y ago
      Is the point here concurrency or parallelism? If it's concurrency, is it something that could be done in a library? As for parallelism, I don't think many SPAs and PWAs really need to be able to make full use of multicore for acceptable performance, do they? If you're writing heavyweight number-crunching code, that belongs either server-side or in a native application.
      - pjmlp 6y ago
        PWAs are the native applications of ChromeOS, WebOS, KaiOS, and by the looks of it, many mobile applications.
        MaxBarraclough 6y ago
MaxBarraclough 6y ago
> Parallelism is where performance is going to come from in the future Others have already pointed out I wasn't strictly correct when I put there's exactly one thread, on account of the Web Workers API. You can write parallel code for the web if you really need to, but it's somewhat walled off from the main JavaScript environment, so we still get to keep much of the benefit of the single-threaded model. For instance, all UI events are handled in the main thread, and that's not something you're empowered to break or override. That's a good thing. Really though, if your page can't get by on one core of a modern CPU, it probably shouldn't be based on web technologies at all. Ordinary websites have no business writing parallel code just to prepare the DOM. I'd rather the average site not have the option at all. The web will never be the ideal platform for writing parallelised number-crunching code like modern high-performance game-engines, neither should it aim to be so. > If I have a 16 core processor just so the add trackers in each of my chrome tabs can run in parallel, this is a world I don't want to live in. I don't follow. What can't you currently do with that enormous computational horsepower? The browser already has plenty of power. Spam and bloat aren't going to go away from the web any time soon, and anyway they're an argument against adding even more features into the browser. The downsides of the web as a platform wouldn't go away by improving JavaScript's ability to execute code in parallel. Web-based UIs would still seem clunky and half-baked compared to native apps, and they'd still use far more computational resources than native apps.

by skohan 6y ago

girvo 6y ago

Genuine question, what would the ad trackers be able to do with runtime level parallelism in the JS runtime that they can’t achieve now? Do they do a lot more blocking calculation than I’d expect?

vbsteven 6y ago
Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked.
- MaxBarraclough 6y ago
  > Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. I agree that it's a neat idea to use asynchrony to move specific heavyweight browser-native computations out of the JavaScript thread, but is JSON parsing really a significant performance issue? > JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. I'd rather parallelism not be a viable option for accelerating trackers. Users are known to hate unresponsive UIs. I'd rather that web trackers bring an unavoidable performance penalty. > Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked. You've just described the Web Workers API. I don't know whether today's tracker scripts use Web Workers. I imagine probably not though, I think the Web Workers API is only appropriate when you're doing substantial computation.

resonantjacket5 6y ago

There are going to be webworkers which will allow you to use more than one thread. (Though it is technically a browser implementation so it'd be up for the browser to implement/allow it)

hajile 6y ago

JS is not single threaded in the way you indicate. JS parsers, compilers, and even some garbage collectors are threaded. IO (arguably the most common case for threads) is threaded behind the scenes. Web Workers allow using multiple cores/processes for typical parallel programming. Message passing exists as do shared memory and even atomics (note: node, firefox, and chromium-based browsers all have it available after Spectre/meltdown mitigations were added, but it's still disabled in Safari). What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware and let the VM handle them seamlessly like in Erlang/BEAM.

MaxBarraclough 6y ago
> What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware What kind of website would benefit from this?
- pjmlp 6y ago
  SPA and PWAs.
  - MaxBarraclough 6y ago
    Is the point here concurrency or parallelism? If it's concurrency, is it something that could be done in a library? As for parallelism, I don't think many SPAs and PWAs really need to be able to make full use of multicore for acceptable performance, do they? If you're writing heavyweight number-crunching code, that belongs either server-side or in a native application.
    - pjmlp 6y ago
      PWAs are the native applications of ChromeOS, WebOS, KaiOS, and by the looks of it, many mobile applications.
      - MaxBarraclough 6y ago

MaxBarraclough 6y ago

> Parallelism is where performance is going to come from in the future Others have already pointed out I wasn't strictly correct when I put there's exactly one thread, on account of the Web Workers API. You can write parallel code for the web if you really need to, but it's somewhat walled off from the main JavaScript environment, so we still get to keep much of the benefit of the single-threaded model. For instance, all UI events are handled in the main thread, and that's not something you're empowered to break or override. That's a good thing. Really though, if your page can't get by on one core of a modern CPU, it probably shouldn't be based on web technologies at all. Ordinary websites have no business writing parallel code just to prepare the DOM. I'd rather the average site not have the option at all. The web will never be the ideal platform for writing parallelised number-crunching code like modern high-performance game-engines, neither should it aim to be so. > If I have a 16 core processor just so the add trackers in each of my chrome tabs can run in parallel, this is a world I don't want to live in. I don't follow. What can't you currently do with that enormous computational horsepower? The browser already has plenty of power. Spam and bloat aren't going to go away from the web any time soon, and anyway they're an argument against adding even more features into the browser. The downsides of the web as a platform wouldn't go away by improving JavaScript's ability to execute code in parallel. Web-based UIs would still seem clunky and half-baked compared to native apps, and they'd still use far more computational resources than native apps.