New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Web Workers #43583
Comments
Is it something you'd be ready to implement this yourself? /cc @nodejs/workers |
Similar to https://www.npmjs.com/package/web-worker? |
The linked module appears to mostly be adding things node workers already support (web events, data uris). Looking at MDN the only thing that really jumps out to me is |
Also the web version only supports URLs (strings) in the constructor, while the Node.js one supports paths and |
IIRC, when @addaleax implemented worker_threads, she modeled the API on Web Workers but it was not possible to support the entire API, so it diverged in places. I'm not sure if the specifics are documented anywhere or if anything has changed. @sindresorhus Any chance you have specific API pain points you'd highlight? If we can't do everything but we can do some things, it would be good to know what is (at least in your view) the high-priority stuff. |
That’s arguably a sign against inclusion in Node.js core, unless you have a reason to believe that development as part of Node.js would improve this situation (isn’t obvious to me why that would be).
The goal was to implement an API that matches Node.js’s abilities and requirements. You can probably support all or almost all of the Web API if you try hard enough, and the Node.js API is certainly inspired by the Web API on the parent thread side. On the child thread side, you are just running code in a completely different environment to begin with. |
Definitely have to agree with this... It could also be a sign that I'd certainly be open to PRs that move the current tl;dr ... PRs welcome ;-) |
No |
I'm curious why it was not possible to support the entire API? And what parts? |
The maintainer released something they needed and got busy. I don't think that's evidence for whether or not it would prosper as a part of Node.js. The repo does have a lot of pull requests, which suggests people would be willing to help improve it. |
Why add Deno supports Web Workers.
Moving |
No, I meant that it could explain why the userland module wasn't advanced further, not offering any kind of reason why we wouldn't continue to make improvements in core. I'm all for that, just need someone to volunteer to do the work |
I don't think anyone is against improving this, we're more trying to figure out what specifically you are looking for in the worker api. Like what prompted you to open this issue? That information can help us triage and understand what scope of work is needed. |
Somewhat interestingly The Whether |
My use-case: I try to make my packages work in both Node.js and browser whenever possible. Sometimes I would like to offload CPU heavy work to a worker (important to keep servers and apps responsive). However, because it's such a pain to deal with the differences of I love Node.js, but the constant differences in essential APIs is a daily pain-point. Mostly This is basically my Node.js wishlist and Node.js is getting closer every year: https://deno.land/manual/runtime/web_platform_apis#web-platform-apis |
I'm certain Node.js will have a spec compliant Web Worker API at some point (whether it's now or in 10 years). Same as I was certain Node.js would get |
I think Node now has a WebCrypto implementation. Personally I just load those APIs via this trivial module and have code that works both in the browser and in Node trivially. I'd love to do the same, or better, for WebWorker and other Web APIs. FWIW I think generally if an API is supported both by the browser and by Deno the question should be flipped: why shouldn't Node also implement it? |
Maybe start with a simple question: What does the global scope inside a Web Worker spawned by Node.js look like? Does it match WorkerGlobalScope? Does it match a regular Node.js global scope? |
I used for node and browsers this package: https://www.npmjs.com/package/threads Works pretty cool 👌🏻 |
I think it should match If you need to access any Node.js-specific stuff, you can just use |
To make it easier to implement this, I would personally be fine with it only supporting module-type workers: |
This package would benefit from Node.js supporting Web Workers as it would not need separate code paths for Node.js and browsers. |
Speaking from my own experience, the fact that Although I will say, even if Node did provide a web-compatible |
@bnoordhuis @cjihrig As folks who have worked for Deno Land Inc. and therefore are presumably familiar with challenges and benefits of supporting Web Workers in a JavaScript runtime, do you have any recommendations, cautions, enthusiastic endorsements, etc.? |
I wasn't around when Web Workers were implemented in Deno, nor have I maintained them at all, so I don't have anything to add in that regard. |
|
If the Web Worker specification is hard to adapt to non-browser JS, then maybe a simpler subset of the Web Worker API could be designed and proposed to browsers as a simpler building block? (Skipping the There is also other work going on when it comes to workers, like @surma's JS Module Blocks proposal, which I raised this issue in to discuss ways it which it could maybe be usable in non-browser contexts: tc39/proposal-js-module-blocks#61 Having a common way of running such Module Blocks would of course be helpful then. |
Which is why I suggested that Node.js core modules could be importable (but not globals).
I don't see any reasons to support that. You can just do the following (as the Deno docs also point out): new Worker(new URL("./worker.js", import.meta.url).href, { type: "module" });
Ideally, these things should be fixed regardless as it will benefit any kind of Node.js-browser shared code, not just Web Workers usage. |
We're talking about different things. My comment is on how to handle imports inside the script. Think |
Browsers do not support bare imports specifiers unless you use import maps. So the answer is the same as importing in a non-Web Worker context; Either bundling or Node.js supporting import maps. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Bun also plans to support Web Workers: oven-sh/bun#159 |
What is the problem this feature will solve?
Creating cross-platform (Node.js + browsers) code has never been more important, but there are still some sharp edges.
fetch
support was recently added, but there's another important and popular API; Web Workers. Node.js does haveworker_threads
, but the API differs in many ways and it's really difficult to properly bridge them. There are attempts at bridging these APIs in user-land, but the most popular one is incomplete and not actively maintained.What is the feature you are proposing to solve the problem?
I propose adding support for Web Workers in Node.js. The Web Workers API is essential to keep apps and servers responsive by moving CPU heavy work off the main thread. I strongly feel it should be part of Node.js.
What alternatives have you considered?
Continue using one of the available polyfills, but that means larger dependency trees, more bugs, and more workaround code.
The text was updated successfully, but these errors were encountered: