When to use web workers • Hacker News Board

Re: When to use web workers

#71

Post by dassurma » Sat, Jun 15, 2019, 9:49 PM UTC

ajkjk wrote: post #59

dassurma wrote: post #38

Earlier quoted context omitted.

The problem is mostly in that all these functions are closures, and scope can’t easily be transferred. Domenic and I have been working on a proposal[1] called Blöcks to introduce transferable functions to JavaScript. In the meantime, I wrote Clooney[2] ontop of Comlink[3] that gives you almost that. [1]: https://github.com/domenic/proposal-blocks [2]: https://github.com/GoogleChromeLabs/clooney [3]: https://github.co…

Oo, I'm really interested that you're working on that, although I don't love the syntax (particularly `worker ` seems awkward). It seems like you should stick with function invocation syntax: `worker = (endpoint) => {| block |}` `worker(endpont) // does what you want` with the difference that the result isn't a closure. As a bonus this syntax would let you write 'pure functions' even if you weren't working with worke…

If you take a look at the issues on the repo, a lot of people agree with you. The syntax was not final at all, we need to convince TC39 first before we can start bikeshedding ^^

Re: When to use web workers

#72

Post by kbumsik » Sat, Jun 15, 2019, 9:49 PM UTC

zawerf wrote: post #47

kbumsik wrote: post #27

My experience with Web Workers was terrible. It's not because of the Web Workers itself but there is no proper standard way to use modules inside of the worker. Because it requires a separated .js file to instantiate, bundlers like webpack tend to introduce weird and non-standard way to work with [1]. It is usually fine when you use it your own project since you are going to stick with a bundler you choose anyway, bu…

I don't really publish libraries so I didn't run into your main gripe. Is there any other reason why you didn't like worker-loader? I experimented with it and found it pretty straightforward. For anyone who wants to try it, you can even get it working from a create-react-app project with the webpack inline loader syntax without ejecting: /* eslint import/no-webpack-loader-syntax: "warn" */ import Worker from 'worker-…

Because if you use it in a library you immediately create a hard dependency to Webpack. Libraries should be designed to work with any bundlers, or even without a bundler at best.

Besides, I personally don't feel good with Webpack's do-everything-with-import approach. It is straightforward of course, but is ES6 import statement supposed be used like this?

Re: When to use web workers

#73

Post by ficklepickle » Sat, Jun 15, 2019, 10:05 PM UTC

I really enjoyed the article! Thanks! You other posts look interesting and I have bookmarked your blog.

A tiny typo in the second-to-last section: specture -> spectrum

Thanks again!

Re: When to use web workers

#74

Post by gridlockd » Sat, Jun 15, 2019, 10:05 PM UTC

I think this is BS, practically all of the performance problems on the Web are related either to the DOM or CSS, which Web Workers can't fix.

If you have a phone from 2014, something's gonna jank. It doesn't mean you're excluded. It means you'll have to live with jank. You'll get over it.

Re: When to use web workers

#75

Post by rl3 » Sat, Jun 15, 2019, 10:06 PM UTC

bufferoverflow wrote: post #36

kbumsik wrote: post #27

My experience with Web Workers was terrible. It's not because of the Web Workers itself but there is no proper standard way to use modules inside of the worker. Because it requires a separated .js file to instantiate, bundlers like webpack tend to introduce weird and non-standard way to work with [1]. It is usually fine when you use it your own project since you are going to stick with a bundler you choose anyway, bu…

Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... });

>Can someone explain why the ES standard doesn't have something like this:
new Worker(function(params) { ... compute heavy stuff here ... });

In 2015 I worked on a framework that functioned like this as a personal project. It was even context-aware and spun itself up differently depending on the environment it was in; workers and shared workers loaded the same .js file that the UI thread did. As such, it chose speed over memory use seeing that the code was effectively pre-loaded everywhere.

It was never completed, and the reasons for that were:

1. SharedArrayBuffer hadn't landed yet. Transfer cost of computable data between workers was high, and transferables had shortcomings of their own.

2. Closures were disallowed, and AST transformations were one possible solution. It seemed like a very bad idea to go down that road.

3. Back then the differences in API behavior between even Chrome and Firefox were terrible to deal with. The APIs were heavily neglected across the board.

These days, I don't see the need. If you need the performance, WASM is a better choice anyways and depending on what you're doing it can use SharedArrayBuffer much more efficiently via way of something like pthreads.

Re: When to use web workers

#76

Post by sergiomattei » Sat, Jun 15, 2019, 10:11 PM UTC

chrismorgan wrote: post #9

I’ve been experimenting with all kinds of things and ideas for making a Rust-powered web frontend system that is designed to be completely functional with server-side rendering, with scripting on the frontend being deliberately optional, bringing things back closer to the old-style non-isomorphic server-side rendering, doing things like wrapping all the buttons in forms so that they will, in the absence of local scri…

This sounds very interesting. Keep us posted.

Re: When to use web workers

#77

Post by laughinghan » Sat, Jun 15, 2019, 10:35 PM UTC

stefan_ wrote: post #43

simonw wrote: post #2

Web Workers were added to Firefox ten years ago this month, so they're definitely not new technology. I think this is a great call to action to actually start taking advantage of them.

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.

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

There is also some niche use as a component of sandboxing: 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.

Re: When to use web workers

#78

Post by dbetteridge » Sat, Jun 15, 2019, 10:45 PM UTC

dassurma wrote: post #38

bufferoverflow wrote: post #36

Earlier quoted context omitted.

Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... });

The problem is mostly in that all these functions are closures, and scope can’t easily be transferred. Domenic and I have been working on a proposal[1] called Blöcks to introduce transferable functions to JavaScript. In the meantime, I wrote Clooney[2] ontop of Comlink[3] that gives you almost that. [1]: https://github.com/domenic/proposal-blocks [2]: https://github.com/GoogleChromeLabs/clooney [3]: https://github.co…

Web workers would make a good http203 episode, uses/pitfalls etc

Re: When to use web workers

#79

Post by zerker2000 » Sat, Jun 15, 2019, 10:51 PM UTC

chrismorgan wrote: post #9

I’ve been experimenting with all kinds of things and ideas for making a Rust-powered web frontend system that is designed to be completely functional with server-side rendering, with scripting on the frontend being deliberately optional, bringing things back closer to the old-style non-isomorphic server-side rendering, doing things like wrapping all the buttons in forms so that they will, in the absence of local scri…

> there will doubtless need to be some alternative channel for events that need to preventDefault, most notably clicking on links that should route instead, and form submit; I’m not sure how that will work.

Naively I would expect that to be part of the rendered DOM(""), or otherwise in a declarative datastructure available to the UI thread. Are there many events that need conditional preventDefault, such that the JS handling code would grow nontrivial?

Re: When to use web workers

#80

Post by troxwalt » Sat, Jun 15, 2019, 11:07 PM UTC

Not related to the article, but the design and css styling of the blog is really interesting. Makes use of CSS variables as well as a couple properties that I've never seen before. (--mask, font-variation-settings)