3 ms·

People have been taking plenty advantage, they are an indispensable tool to turn all of these CPU bugs or DRAM attacks into working browser exploits. Also those

People have been taking plenty advantage, they are an indispensable tool to turn all of these CPU bugs or DRAM attacks into working browser exploits. Also those bitcoin miners of course. Maybe if no one else is taking advantage it is time to simply throw them out.

Matheus28 7y ago
“I don’t use it, therefore no one else uses it” As an example, emscripten uses WebWorkers and SharedArrayBuffers to implement multithreading (unfortunately or not, Chrome is the only browser that supports SharedArrayBuffer, others have disabled it).
- stefan_ 7y ago
  I suggest you look up why they disabled it. And that is still not an application of WebWorkers! It would be much more helpful to the cause if you could point to some actually used app out there principally relying on WebWorkers. Until then, it's been a lot of pain, zero gain.
  - Jack000 7y ago
    a bit niche, but here's one of my projects - svgnest.com in addition to the render blocking issue brought up by this article, there are a lot of applications for cpu-bound web apps (eg. anything requiring machine learning or computer vision), but in my experience web workers are not very reliable for this purpose.
    - infinite8s 7y ago
      I use webworkers to run an in-memory streaming pivoting engine (compiled from C++ to wasm) to build real-time Tableau-like dashboards that run fully in the browser (which runs fairly well for 10M row datasets or less). Network IO and the compute is handled in the webworker, which allows the main UI thread to remain responsive.
- jacobush 7y ago
  This whole thread was quite overwhelming. I was starting to feel, can we just have a normal CPU machine and some C in it? That is horrible too, but in a way I can understand. And sure enough, emscripten gets mentioned. :-D
- tree123 7y ago
  are you updating diep.io? it is showing lastModified 17th June 2019
laughinghan 7y ago
They're pretty important for this free online graphing calculator (widely used by high school students and teachers and even starting to be used on some standardized tests): http://desmos.com/c http://desmos.com/c There is also some niche use as a component of sandboxing: https://gist.github.com/pfrazee/8949363 https://gist.github.com/pfrazee/8949363 Your point is well-made though. Very few kinds of webapps are CPU-bound, graphing calculators being notable as an exception (and even then, Desmos made do with the main thread before Web Workers were usable). And while lots of webapps could use plugins, browsers could provide an API for sandboxing code that runs in the main thread, or with a GIL. The reality is, though, the cat is out of the bag. WHATWG is committed to making the Web into a fully-featured platform for WORA apps with all the same capabilities as a desktop app, and multithreading is one of those capabilities. Even if the next Spectre/Meltdown dooms Web Workers in their current incarnation, browsers will run workers in Docker containers if they have to.

Matheus28 7y ago

“I don’t use it, therefore no one else uses it” As an example, emscripten uses WebWorkers and SharedArrayBuffers to implement multithreading (unfortunately or not, Chrome is the only browser that supports SharedArrayBuffer, others have disabled it).

stefan_ 7y ago
I suggest you look up why they disabled it. And that is still not an application of WebWorkers! It would be much more helpful to the cause if you could point to some actually used app out there principally relying on WebWorkers. Until then, it's been a lot of pain, zero gain.
- Jack000 7y ago
  a bit niche, but here's one of my projects - svgnest.com in addition to the render blocking issue brought up by this article, there are a lot of applications for cpu-bound web apps (eg. anything requiring machine learning or computer vision), but in my experience web workers are not very reliable for this purpose.
  - infinite8s 7y ago
    I use webworkers to run an in-memory streaming pivoting engine (compiled from C++ to wasm) to build real-time Tableau-like dashboards that run fully in the browser (which runs fairly well for 10M row datasets or less). Network IO and the compute is handled in the webworker, which allows the main UI thread to remain responsive.
jacobush 7y ago
This whole thread was quite overwhelming. I was starting to feel, can we just have a normal CPU machine and some C in it? That is horrible too, but in a way I can understand. And sure enough, emscripten gets mentioned. :-D
tree123 7y ago
are you updating diep.io? it is showing lastModified 17th June 2019

laughinghan 7y ago

They're pretty important for this free online graphing calculator (widely used by high school students and teachers and even starting to be used on some standardized tests): http://desmos.com/c http://desmos.com/c There is also some niche use as a component of sandboxing: https://gist.github.com/pfrazee/8949363 https://gist.github.com/pfrazee/8949363 Your point is well-made though. Very few kinds of webapps are CPU-bound, graphing calculators being notable as an exception (and even then, Desmos made do with the main thread before Web Workers were usable). And while lots of webapps could use plugins, browsers could provide an API for sandboxing code that runs in the main thread, or with a GIL. The reality is, though, the cat is out of the bag. WHATWG is committed to making the Web into a fully-featured platform for WORA apps with all the same capabilities as a desktop app, and multithreading is one of those capabilities. Even if the next Spectre/Meltdown dooms Web Workers in their current incarnation, browsers will run workers in Docker containers if they have to.