Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When to use web workers

dassur.ma

Post reply on HN
Print view View original

91–100 of 110 posts

Re: When to use web workers

#91

Post by kbumsik »

rl3 wrote: post #75
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 ... });

> 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…

> 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.

I think you misunderstand the concept of WASM. WASM does not have its own thread, it blocks the main thread and runs in the same context as JS. WASM still must spawn a Web Worker to emulate multithreading in a browser.

Re: When to use web workers

#92

Post by franciscop »

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 ... });

Since you seem not to like Clooney, what about uwork? I wrote it a while ago:

https://github.com/franciscop/uwork

    const findPi = uwork((iterations = 10000) => {
      let inside = 0;
      for (var i = 0; i

Re: When to use web workers

#93

Post by chrismorgan »

zerker2000 wrote: post #79
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…

I thought about it a bit longer after I wrote it and decided that what you need is some sort of pure function that takes the event target DOM element only, and decides whether the default should be prevented. For example, in FastMail we use a function to intercept links that will essentially check whether the href is routable (fiddlier than you might guess, unfortunately) and not target=_blank; that could be reduced to such a pure function, though various routes would now need to be specified in two places. Either that, or just always pipe generated elements through some function in the worker that annotates them—I like your idea, thanks for the thoughts!

Either way, I can’t think of anything where you need fully conditional preventDefault. Definitely something closer to declarative than imperative is good for these sorts of things.

Re: When to use web workers

#94

Post by chii »

eddiezane wrote: post #42
msoad wrote: post #31

As a UI developer i want to move scrolling and style updates out of main thread. Every WebWorker tutorial is taking about how a “computationally heavy task” can go out of main thread. But rarely anyone does computation in the client. I would say Animation Worklets are the workers that will make an impact on delivering multithreaded UIs in web. https://www.chromestatus.com/feature/5762982487261184

If you haven't seen this before it might interest you. Nolan worked on offloading most of the work to threads to achieve 60 fps on mobile. http://www.pocketjavascript.com/blog/2015/11/23/introducing-...

That's pretty cool!

Re: When to use web workers

#95

Post by chrismorgan »

gridlockd wrote: post #74

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.

Many websites have too much of everything, but UI-thread JS is definitely the most common largest performance problem that prevents you from using pages. It’s the biggest thing where an architectural re-think has the biggest effect—though certainly just cutting down on all things will improve performance too.

Re: When to use web workers

#97

Post by rl3 »

kbumsik wrote: post #91
rl3 wrote: post #75

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 ... }); 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…

> 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. I think you misunderstand the concept of WASM. WASM does not have its own thread, it blocks the main thread and runs in the same context as JS. WASM still must spawn a Web Worker to emulate multithreading in a browser.

I do understand, was just mobile and in a hurry so I failed to fully qualify the statement.

What I was saying is if you're in the WASM toolchain/ecosystem, something like pthreads would already be implemented by Emscripten[0]. In other words, spinning up web workers is handled for you seamlessly. It's all dealt with at a very low level of abstraction. You're literally using the SharedArrayBuffer as memory.

Contrast that to JS, and you have to serialize/deserialize types before they can even be stored in SharedArrayBuffer. It's costly and far from seamless.

As an aside, it's unfortunate SharedArrayBuffer was hit so hard by Spectre. The poor standard is cursed or something.

[0] https://emscripten.org/docs/porting/pthreads.html

Re: When to use web workers

#98

Post by dassurma »

rl3 wrote: post #97
kbumsik wrote: post #91

Earlier quoted context omitted.

> 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. I think you misunderstand the concept of WASM. WASM does not have its own thread, it blocks the main thread and runs in the same context as JS. WASM still must spawn a Web Worker to emulate multithreading in a browser.

I do understand, was just mobile and in a hurry so I failed to fully qualify the statement. What I was saying is if you're in the WASM toolchain/ecosystem, something like pthreads would already be implemented by Emscripten[0]. In other words, spinning up web workers is handled for you seamlessly. It's all dealt with at a very low level of abstraction. You're literally using the SharedArrayBuffer as memory. Contrast t…

As you already hinted, SABs have been widely disabled. Chrome is currently the only browser who has SABs and therefore the only browser with support WebAssembly threads.

Workers, on the other hand, are available everywhere. And serialization seems to be far less costly than most people think. In the apps that I have written that make use of a off-main-thread architecture, structured clone has not been my bottle-neck.

Re: When to use web workers

#99

Post by samsonradu »

One good use case I had for WebWorkers was running heavy Regex on strings. Easy to decouple from the web app as I just had to pass the 2 strings to the Worker (text to scan and regex expression) and get back the result array. There is, however, a performance penalty there as the browser will ‘favor’ the main thread to for rendering and UX.

Re: When to use web workers

#100

Post by stephenr »

megous wrote: post #62
stephenr wrote: post #19

Earlier quoted context omitted.

Pro tip: if you ask a user to install a different browser, they're just as likely to use a different site instead.

Depends on the user. My GF for some reason uses FF, Edge and Chrome at the same time, most of the time (she's not in/into tech). So if someone asked her, she would just switched the windows.

That sounds like a fairly rare workflow. I've heard of people using different browsers for different things but I don't think it's common.
Post reply on HN