State of the Web: Deno
In Ryan Dahl’s talk Ten things I regret about Node, he talked about many problems with Node. These issues include Node’s failure to embrace web standards, security, Node’s way of compiling native modules (GYP), and NPM. Then, he revealed Deno. Deno was a new project that fixed many problems Ryan Dahl had earlier mentioned, along with extra advantages like built-in TypeScript support. Ryan Dahl initially built Deno in Go but later switched to Rust.
Since Ryan Dahl first announced Deno, it has made significant progress. 1.0 was released in August 2020, and companies like Slack, Netlify, and GitHub have adopted Deno. In addition, The Deno Company has also released its own edge serverless function platform, Deno Deploy.
V8 is a sandboxed language that makes it impossible for code to do something outside of its boundaries. However, Node.js allows access to things like networking and the filesystem inside the sandbox, which removes the security benefits of V8. Even for trusted programs, this can be hurtful because insecure code or malicious dependencies could deal significant damage and steal information.
Deno solves with a system of permissions. These permissions make you define precisely what the program can do outside of the sandbox, like filesystem access and environment variables. For example, if you wanted to allow for reading files within the local
assets directory, you would run Deno with a command like:
deno run --allow-read=./assets
Because of these capabilities, you can ensure that your code does not reach outside of its boundaries, increasing security.
Because the Node.js and web platforms evolved in parallel and many web APIs came after Node.js versions of them, they have many differences. There are many examples of this, like the module system and HTTP requests.
<script> tags and using them from the global window scope. Since HTML and the window were unavailable on the server, Node.js needed a module format. Node.js decided to adopt a form of CommonJS, which was a popular, simple, synchronous module format. However, CommonJS was not native to browsers (you would have to use a library like Browserify), and there were differences between implementations of CommonJS.
Years later, in 2016, a new module specification called ECMAScript Modules (ESM) was finalized in ES6. This module specification would work without any libraries in browsers. Additionally, it would solve many problems with CommonJS, like asynchronous module loading and tree shaking. However, it took a while for Node.js to add ESM support, and even after that, ESM adoption in Node.js was not very high, with the majority of NPM packages still only include CommonJS versions. Additionally, Node.js does not have an entirely standards-compliant ESM implementation and differs in things like including
.js file extensions.
In contrast, Deno only works with entirely standards-compliant ESM. Using one module format makes using Deno a lot simpler for both users and library authors. Speaking from experience, using just ESM is much simpler than including both ESM and CommonJS. Deno also is more straightforward in that it sticks to the standards, so you know that your module code works correctly in browsers.
Sending HTTP requests is another area of incompatibility which Deno solves. Node.js allows for HTTP requests through the
https standard library functions. However, the modern way of running HTTP requests on the web is through the
fetch() API, which is standardized and simpler than
http. The most recent versions of Node supports
fetch(). However, Node’s
fetch() support is limited to very recent versions, so many people have had to turn to using packages like node-fetch for the simplicity of
fetch() or cross-fetch for full cross-platform compatibility. This is problematic because it is another dependency needed, and it is not immediately available without importing. However, all versions of Deno support the
fetch() API by default, which solves these problems.
Currently, this is the biggest problem with Deno and is a big reason why most Node.js developers are not migrating to Deno (this is a nasty problem because if Node.js developers don’t migrate, the ecosystem grows more slowly). There are 6350 modules on deno.land/x, compared to 2 million on NPM. However, many people use other package hosting services (see “Decentralised Module Hosting” above), and most modern web packages should work on Deno. Many Node.js packages should work on Deno, as Deno does include polyfills for Node.js APIs and the ability to load npm modules using the
npm: specifier. However, the polyfills are not perfect, and some Node.js packages might not work.
Deno is very actively developed, with monthly releases and new features in each release. Deno is even backed by a official company, which can be both good or bad depending on how you look at it. There are more than 600 contributors to Deno, which is growing. Basically, Deno is a very actively maintained project
Deno can be deployed pretty widely, although not as widely as Node.js.
Deno has ok support for various container services. Deno.land provides an official Docker image for services that support Docker. However, while most popular container services support Deno, the support is often unofficial and not always maintained. Here is a list of tools and resources for running Deno on container services:
Serverless is where the Deno company comes in. Their primary commercial offering is Deno Deploy, a serverless edge function runner for Deno scripts. It is conceptually similar to Cloudflare Workers in that it uses V8 Isolates for ultra-fast startup times. The advantage of Deno Deploy is that it includes the Deno API and all of the other features that make Deno so helpful. However, there are still other options that might be better. Here is a list of tools and resources to run Deno on various serverless function providers: