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

Snappy UIs with WebAssembly and Web Workers

mofi.loud.red

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Snappy UIs with WebAssembly and Web Workers

#61

Post by fenomas »

strogonoff wrote: post #60
fenomas wrote: post #21

Web Workers are a really great feature for performance. The way they want the worker code to live in a separate file makes them slightly annoying if you're using a bundler, but each bundler has a loader or similar feature for this, so all is mostly well. But the thing I haven't found a solution for is, the case where you want to use web workers inside a library that other people will be importing into their own proje…

Design in layers. Layer 0: Strategically separate core logic while assuming as little about the environment as possible. Function Y generates something, function X handles the result somehow. Maybe there’s a postMessage somewhere between, or maybe not—you don’t care. Maybe Y is slow, but that doesn’t mean it must assume it runs in a worker. Maybe X serializes output in some way, but it doesn’t need to assume that DOM…

Hi, I appreciate the advice in general, but in my case it's not an architectural matter. Basically, I just have one internal, encapsulated function that ought to run in a worker, and I'd like to implement that without doing anything hairy - and without imposing requirements on the end-user to make their own worker. It seems like this isn't possible, but if you know of a way I'd love to hear it!

Re: Snappy UIs with WebAssembly and Web Workers

#62

Post by strogonoff »

fenomas wrote: post #61
strogonoff wrote: post #60

Earlier quoted context omitted.

Design in layers. Layer 0: Strategically separate core logic while assuming as little about the environment as possible. Function Y generates something, function X handles the result somehow. Maybe there’s a postMessage somewhere between, or maybe not—you don’t care. Maybe Y is slow, but that doesn’t mean it must assume it runs in a worker. Maybe X serializes output in some way, but it doesn’t need to assume that DOM…

Hi, I appreciate the advice in general, but in my case it's not an architectural matter. Basically, I just have one internal, encapsulated function that ought to run in a worker, and I'd like to implement that without doing anything hairy - and without imposing requirements on the end-user to make their own worker. It seems like this isn't possible, but if you know of a way I'd love to hear it!

You can create workers at runtime. Take the fact that it is not straightforward, and hence you need to be asking this question, as a hint that it’s almost certainly the wrong thing to do for your library—unless it is specifically about something like worker management, in which case you would not be asking this question. Don’t mess with the environment, users (and future you) will thank you for it.

Re: Snappy UIs with WebAssembly and Web Workers

#63

Post by lioeters »

fenomas wrote: post #21

Web Workers are a really great feature for performance. The way they want the worker code to live in a separate file makes them slightly annoying if you're using a bundler, but each bundler has a loader or similar feature for this, so all is mostly well. But the thing I haven't found a solution for is, the case where you want to use web workers inside a library that other people will be importing into their own proje…

> pre-building the worker JS and storing that text in your library, piping it into a file blob at runtime

I just did that today, to be able to bundle the worker script with the client that controls it in a single file. It's convenient but feels hacky, and I wonder about its impact on page performance.

There's a similar trick for bundling a base64-encoded WASM binary with the host JS that controls it in a single file. That saves effort for the consumer of the script, so they don't need to bundle or copy the binary into their static assets folder, for the script to load.

I think the common (best?) practice is to let the consumer handle the static file (like worker script, WASM binary), and then for the client script to provide an option to set the URL path where the static file is served.

Re: Snappy UIs with WebAssembly and Web Workers

#64

Post by fenomas »

lioeters wrote: post #63
fenomas wrote: post #21

Web Workers are a really great feature for performance. The way they want the worker code to live in a separate file makes them slightly annoying if you're using a bundler, but each bundler has a loader or similar feature for this, so all is mostly well. But the thing I haven't found a solution for is, the case where you want to use web workers inside a library that other people will be importing into their own proje…

> pre-building the worker JS and storing that text in your library, piping it into a file blob at runtime I just did that today, to be able to bundle the worker script with the client that controls it in a single file. It's convenient but feels hacky, and I wonder about its impact on page performance. There's a similar trick for bundling a base64-encoded WASM binary with the host JS that controls it in a single file.…

Yeah, it sounds like pre-building the worker JS, so it's a static asset when the client does their bundling, is the least-bad option. Thanks!

Re: Snappy UIs with WebAssembly and Web Workers

#65

Post by omarelb »

fenomas wrote: post #61
strogonoff wrote: post #60

Earlier quoted context omitted.

Design in layers. Layer 0: Strategically separate core logic while assuming as little about the environment as possible. Function Y generates something, function X handles the result somehow. Maybe there’s a postMessage somewhere between, or maybe not—you don’t care. Maybe Y is slow, but that doesn’t mean it must assume it runs in a worker. Maybe X serializes output in some way, but it doesn’t need to assume that DOM…

Hi, I appreciate the advice in general, but in my case it's not an architectural matter. Basically, I just have one internal, encapsulated function that ought to run in a worker, and I'd like to implement that without doing anything hairy - and without imposing requirements on the end-user to make their own worker. It seems like this isn't possible, but if you know of a way I'd love to hear it!

Hey, so we're doing something similar to the solution given above, but without compiling the worker at bundle time.

Basically what we're doing is putting the worker code in a string. When you need the worker, you can `import myWorker from ./worker`. At runtime you can create a `Blob` from the string, then create a URL for it using `window.URL.createObjectURL`.

It's certainly far from ideal. Since the code lives in a string, there are no compile time errors at all (though you could probably develop without the string form and put it in a string after). But it kinda works. Hope it's what you're looking for.

Re: Snappy UIs with WebAssembly and Web Workers

#66

Post by strogonoff »

omarelb wrote: post #65
fenomas wrote: post #61

Earlier quoted context omitted.

Hi, I appreciate the advice in general, but in my case it's not an architectural matter. Basically, I just have one internal, encapsulated function that ought to run in a worker, and I'd like to implement that without doing anything hairy - and without imposing requirements on the end-user to make their own worker. It seems like this isn't possible, but if you know of a way I'd love to hear it!

Hey, so we're doing something similar to the solution given above, but without compiling the worker at bundle time. Basically what we're doing is putting the worker code in a string. When you need the worker, you can `import myWorker from ./worker`. At runtime you can create a `Blob` from the string, then create a URL for it using `window.URL.createObjectURL`. It's certainly far from ideal. Since the code lives in a…

Yes, data URI & blobs is a way. You can author worker code as you would normally do (in TypeScript, for example) and bundle (with type checks) it into a string as part of your own build process. Ideally, though, you would want to keep the worker wrapper separate from core library so that users with complex projects can integrate it in their own build however they want…

Re: Snappy UIs with WebAssembly and Web Workers

#67

Post by [deleted] »

strogonoff wrote: post #62
fenomas wrote: post #61

Earlier quoted context omitted.

Hi, I appreciate the advice in general, but in my case it's not an architectural matter. Basically, I just have one internal, encapsulated function that ought to run in a worker, and I'd like to implement that without doing anything hairy - and without imposing requirements on the end-user to make their own worker. It seems like this isn't possible, but if you know of a way I'd love to hear it!

You can create workers at runtime. Take the fact that it is not straightforward, and hence you need to be asking this question, as a hint that it’s almost certainly the wrong thing to do for your library—unless it is specifically about something like worker management, in which case you would not be asking this question. Don’t mess with the environment, users (and future you) will thank you for it.

[deleted]

Re: Snappy UIs with WebAssembly and Web Workers

#68

Post by lioeters »

fenomas wrote: post #64
lioeters wrote: post #63

Earlier quoted context omitted.

> pre-building the worker JS and storing that text in your library, piping it into a file blob at runtime I just did that today, to be able to bundle the worker script with the client that controls it in a single file. It's convenient but feels hacky, and I wonder about its impact on page performance. There's a similar trick for bundling a base64-encoded WASM binary with the host JS that controls it in a single file.…

Yeah, it sounds like pre-building the worker JS, so it's a static asset when the client does their bundling, is the least-bad option. Thanks!

https://github.com/mitschabaude/esbuild-plugin-inline-worker
Post reply on HN