I don’t know the exact implications of this, since it’s only about two weeks old but it seems like potentially a big deal:
Node.js support in Cloudflare Workers
The first thing to note is that you may think the title is suggesting that Node.js is supported in Cloudflare Workers, but this is actually meant to give a summary of the current state of Node support today and where it will go in the future.
As David noted, this has not been very clear in the past, so I applaud the team for trying to better communicate the technical limitations of the current implementation.
Support today
It seems like anything using Webpack should in theory be usable. I rarely can get Webpack to work in the first place, so this doesn’t exactly scream killer DX to me.
For over 20k packages, Workers supports this magic already: any Node.js package that uses webpack or another polyfill bundler runs within our environment today.
But it should be at least a starting point, in theory, since Redwood was heavily built with Webpack, you would think there should be a lot of overlap. However, as some may know, Peter recently saw the light of esbuild and we shouldn’t be thinking of Redwood through the lens of Webpack for much longer.
We don’t need to speculate though, because the team put together a handy dandy Works on Workers website. But unless I’m missing something I don’t see 20k packages at that link, I see 32, so looks like it’s a bit of a work in progress still.
Use Gatsby on Cloudflare Workers - in theory
Once you select a package, you can use webpack to bundle it all up with the wrangler CLI and deploy onto Workers. They provide the following example of bundling dependencies in action with Gatsby.
Unfortunately supporting a static site generator is a much different use case from Redwood, so best case scenario is we could probably leverage this work with the web
side but will still hit the same roadblocks with Prisma.
Okay, but seriously though, when is Node support coming to Workers?
We want to go even further and support the most important modules, even if they do rely on native code. Our approach will be to reimplement supported modules and polyfill package functionality directly into the Workers runtime. This doesn’t mean we’re shifting our runtime to run on Node.js. In fact, here are two important security and design reasons why we are not:
- Node.js was not designed to be a sandbox, which was made apparent by their vm module that says “do not use it to run untrusted code.”
- For proper sandboxing, Node.js would’ve forced us to build a container-based runtime that both doesn’t scale and isn’t as performant as Isolates. Without containers, we were able to design a system that has 0ms cold starts.
However, there are other ways we can be Node.js compatible without necessarily supporting the entire runtime. What’s up first? We’ll support Stripe.js SDK and Twilio Client JS SDK. We’ll also build support for the net module, so you can run popular database libraries.
But we want to hear from you! We created a leadership board for you to vote on which popular libraries/APIs matter the most.
So the answer is a very diplomatic never. Time for Denowood?