Add WebWorker Support

[dansiviter]

Add ability to load WebWorkers (and SharedWorkers?) via the react-scripts. My use-case is for using latency (and debug) sensitive protocols over WebSocket which may get dumped by the server if no activity occurs.

There has been a lot of discussion regarding this on #1277 but no definitive answer and now closed. Also, I'm a server-side dev so JavaScript PR is not my forte, and neither is ejecting the scripts as that looks scary.

[gaearon]

I’m not opposed if we see a clear proposal from someone about how they should work.

[viankakrisna]

I haven't written WebWorkers before, but I think this library is interesting to get support of web workers in CRA right now: https://github.com/developit/workerize

it also has it's own webpack loader https://github.com/developit/workerize-loader (not required to use workerize)

which in turn inspired by https://github.com/webpack-contrib/worker-loader

I think adding the last one with test like .worker.jswould be a good option if we want to support it out of the box without tying it with any library (except webpack?)

[iansu]

workerize seems like a more straight forward solution. It looks like it handles the communication between the parent thread and the worker, which is nice. You just have to export a method from the worker as opposed to using postMessage/onmessage to communicate between the two.

I like the idea of using a different extension (.worker.js) to signify a worker and having it registered automatically. That seems to fit nicely with create-react-app.

[iansu]

I'm curious about WebWorkers in general so I wouldn't mind giving this a try.

[wregis]

In the past I had to eject and configure "worker-loader". I used it to process some routines on datasets and still allow users to interact with the main UI.

[doxxx]

I use Web Workers to implement a solver using genetic algorithms for a SPA. The solver can run for up to a minute or two, so it needs to be in a "background thread" -- i.e. Web Worker -- to not freeze the browser page while it's running.

I should note that my app is currently implemented in Angular and plain old ES5-ish Javascript. I would like to migrate to React and Typescript but this has been a stumbling block so far.

[jlarmstrongiv]

Is there anything that needs to be done before this pull request can be merged into the next branch (2.0 release)? I might have missed it, but I could not find Web Workers on the 2.0 Projects roadmap. I would love to be able to try it out in one of the alpha releases 🙂

[iansu]

I think there's still some debate about using worker-loader vs. workerize-loader. worker-loader is more low-level and powerful but workerize-loader is incredibly easy to use and probably covers the majority of use-cases.

[doxxx]

I couldn't get workerize-loader to work with Typescript, but I may have simply failed at the appropriate incantations.

[Narvey]

@iansu I'm not sure about workerize-loader covering the majority of use-cases. Unless I'm understanding incorrectly, it doesn't allow sending messages in the middle of a loop (this is extremely important for making realistic progress bars).

[npotts]

I realize there is a desire to make a 'simpler' API for web workers, but honestly, the basic subset is more than sufficient. I have a data intensive app, and want to use web workers to do the data fetches, parsing, and pass massaged data back to the main thread often.

A 'run once - read once' methodology may work for some applications, but nothing that I am involved with.

[doxxx]

Ah, yeah, workerize will not work (heh) for me. I need to keep a web worker running and exchange messages back and forth. Progress bars is one of the uses as @Narvey mentioned.

[gpolyn]

Granted a distinction between "physical" threads and "software" threads, such that creating many web workers may result in more software threads than available physical threads, a developer may wish to mind the user's hardware utilization and create fewer or no more than the available number of physical threads, e.g., https://github.com/josdejong/workerpool/blob/master/lib/Pool.js.

So, here are two React pooling attempts:

• worker-loader: https://github.com/gpolyn/react-and-worker-loader
• workerize-loader: https://github.com/gpolyn/react-and-workerize-loader

[sinedied]

Would love to also see some support for newly introduced AudioWorklet, which are basically web worker for audio processing 😃

[jasmith79]

Another use case:

Desktop Chrome (~75% global market share) throttles setInterval in unfocused tabs. If you want to ensure that something is running the easiest way is to run it in a Worker.

[doxxx]

@jasmith79 To be honest, that sounds like a hack to get around a legitimate browser restriction. What's the actual use case?

[jasmith79]

@doxxx I wrote an app for work that has to be able to do background update, so I poll the backend for changes every so often on an interval timer. Got reports that it was wonky in Chrome (worked fine in FF/Safari) and discovered that (this was before serviceworker). Runs fine in a webworker. Now I'm porting the front end to react and discovered this problem.

[gampleman]

I'm wondering if we could write something like workerize, but with the following changes:

• exporting a function from a worker module that is not async will cause a build time error (as opposed to workerize "silently" turning it async for you)
• Supports async generator functions. That is if a function is an async generator than it can communicate intermediate results or progress to the main thread. The main thread can even pass information in via the next method.

I think these changes would achieve the following goals:

1. For simple use cases we keep the simplicity and elegance of workerize.
2. I think this should be nearly as expressive as the low-level api of web workers, but nicer to work with.
3. The module would work exactly the same if the worker loader would disappear, except it would run on the same thread (but async). This would make it relatively low commitment and also easy to test, since the test framework doesn't need to worry about worker support (which can be slightly tricky in node).

How does that sound?

[iansu]

That does sound useful but it also sounds like it's outside the scope of Create React App. Have you considered proposing these changes to Workerize?

[gampleman]

I was more thinking of building this as a separate library. But I'm quite interested if that proposed design would fit the needs that people have for webworkers and if something like that would fit into cra?

[doxxx]

All I really want is just for the existing WebWorker APIs to work and to be able to load a js/ts file as a web worker. Anything beyond that lies outside the scope of CRA as far as I’m concerned. That forms the basis on which everything else can be built.

[breznik]

I know most of the conversation is around implementing support for Web Workers, but Web Worker usage is the gateway to then needing to use SharedWorkers, so it would be really amazing if there was a way to handle the ad-hoc solutions needed today if you want to utilize Web Workers, SharedWorkers, or AudioWorklets - or in my case, the combination of all three. Conventions for special treatment such as *.worker.js, *.sharedworker.js, *.worklet.js (or *.awn.js?) would work wonders for those of us using CRA for more advanced cases.

[stramel]

https://github.com/GoogleChromeLabs/worker-plugin