With “The Browser Wars” over, a new fight has been waging for how your Javascript runs. Although alternatives to Node.js have around for a few years, there has always been a sticking point that’s kept me reaching for pnpm init. That is until now. Now, it’s Deno time.
Minimum Stable Project
For me, Deno’s value comes from providing a built-in set of tooling that works seamlessly and consistently with Typescript, monorepos, and CI/CD. While the Node setup below works great once it’s setup, there are a lot of places for things to go wrong across environments. Deno’s baseline tooling is now competitive for most projects, and it’s compatible with the Node ecosystem should you need specific features in specific places. This tight integration removes much of the need for complex coordination tooling like NX and Projen, as most everything is managed within deno.json.
Compatible where it counts
Much of the complexity and mixed interoperability in the JS ecosystem stems from the sheer variety of runtime targets: Browsers, Servers, Edge Functions, Wasm*, to name a few. Each brings unique technical constraints and API expectations, with standards being partially implemented or not existing formally. This makes compatibility difficult for new runtimes.
Deno has pragmatically chosen to provide three sets of APIs, covering the majority of module dependencies for modern packages: Web APIs, Node APIs, and Deno APIs. With this coverage, combined with first class Wasm execution, I would not be worried about limited dependency support.
What about the others?
Other overlapping runtimes are maturing as well: including Bun, cloud runtimes like Cloudflare and Vercel, and Wasm based runtimes. While these are each interesting in their own right, they focus on different problems than Nodejs and Deno, and in most cases the appropriate runtime will depend on the system being implemented.
A note on Wasm
I include Wasm in my discussion of runtimes above, and I think it’s important to talk about why. Wasm is not a javascript runtime. It is a compilation target (think byte code), that’s also a subset of javascript; allowing non-js code, compiled into Wasm, to execute in a JS runtime.
Why would a JS/TS developer care? If you’ve ever installed an NPM module and seen python/c++ compilation, .node files, or platform specific binaries, your application at some point is invoking non-js code. Wasm - and the ecosystem around it - provides an alternative to these approaches which drastically simplifies distribution. For an entertaining take on how far this model goes, I recommend (semi-satirical) 2014 talk “The Birth and Death of Javascript“.