Originally posted in my personal blog
A new contender is threatening Node.js monopoly as a JavaScript runtime, and its name is (drumrolls) Deno.
This article will give you a basic understanding of what Deno is, the value this technology adds, and where it lacks at the moment. Also, I'll share some thoughts about adopting it.
In a nutshell, what is Deno?
Deno is a new (version 1.0 just came out) JavaScript runtime, created by the Node.js creator and designed to overcome several design flaws from Node.js and add improvements on top of that. A runtime is a "box" where code can run, and it's a vital part of a system because it imposes certain restrictions around applications built inside of it and dictates a tremendous amount of the development experience and tradeoffs involved in creating the system.
Before checking Deno's benefits, we need to understand which problems it aims to address.
Problems with Node.js
On this great talk, Ryan Dahl, the creator of Node.js, talks about some of the regrets in the development of Node.js
Amongst them, I'd like to highlight the following:
- Security: There was a missed opportunity while designing Node to add certain guarantees around security. For example, your linter should not get access to your network or entire file system.
- Making npm the defacto standard: This creates a centralized and privately controlled entity that has great power over the whole ecosystem and things like this happen.
- node_modules: You know the meme, nothing is deeper than the node modules folder. It complicates the module resolution algorithm and is very inconsistent with how browsers work.
After reading this, you might be wondering: "Why not just fix these issues in Node?". Deno's blog answers this question: "Due to the large number of users that Node has, it is difficult and slow to evolve the system."
Another great benefit of using Deno is the complexity around developing JavaScript applications with Node. There is just massive tooling involved, which creates confusion amongst new developers and headaches to more experienced ones for having to keep up with new versions of each package.
Benefits of using Deno
Some of Deno's most important benefits compared to Node are:
- Secure by default: Just like mobile applications, you need to grant explicit permission to access file, network, or environment. Because of this, you don't have to be scared anymore about one corrupted package stealing your personal information.
- Simplicity: Deno ships as a single executable, which provides everything you need to develop your application. No need for a package.json file or setting up external config files.
- Support for TypeScript out of the box: Given Typescript popularity and adoption, this can significantly improve the developer experience and help developers catch bugs early.
- Built-in utilities such as a bundler and code formatter: In other words, there is no need for external dependencies such as Prettier or Webpack for common tasks.
- Standard library: This has been a long-requested feature for JavaScript, and Deno offers one. It provides utilities for testing, date-formatting, and more.
- Browser compatible API: Global variables and events such as fetch, load, unload, and window are available in Deno just like you would expect in a browser, thus reducing the friction of moving from one platform to another.
All these benefits translate to mainly two things. First, you significantly improve developer experience, thus leading to potentially shorter development cycles, and second, you reduce the risk of downtime and data loss due to vulnerabilities from unsecured scripts.
How does a script built for Deno look like
To exemplify Deno's benefits, here's a sample index.ts file that you can run out of the box with Deno.
// Importing a dependency directly from a URL 🤯
import { parseDateTime } from "https://deno.land/std/datetime/mod.ts"
// Using browser compatible apis such as fetch
const res = await fetch('https://icanhazdadjoke.com', {
headers: { 'Accept': 'application/json' }
})
const data = await res.json()
const enc = new TextEncoder();
// Using the Deno global namespace for os utilities
await Deno.writeFile("joke-of-the-day.txt", enc.encode(data.joke))
console.log("We're done here 🦕")
How to run the script
deno run --allow-read --allow-write index.ts
Deno's limitations
Despite all the significant merits, Deno has some shortcomings that prevent it from being on the same level as Node today. Here they are:
- Migration cost: Most organizations using Node, are tightly coupled to npm's ecosystem. For example, teams have thousands of tests written with Jest, their configuration for prettier, their custom Webpack config, Node global variables, and much more. Adopting Deno for these types of applications would probably be more costly than to keep using Node and npm. Also, if you use Deno for new projects, there would be extra effort maintaining utilities that work for this runtime and a lot of effort would be wasted
- Incompatibility with some NPM packages: One study referenced in this talk from 2019 suggests that the reason JavaScript is the most popular language today is because of the large number of packages available in the npm registry. Unfortunately, some very popular Node packages are not compatible with Deno.
- The standard module is not stable: According to the docs, "Deno's standard modules (https://deno.land/std/) are not yet stable": This means that you could end up finding some unexpected behavior with one of your use cases or even bugs.
- Lack of experienced developers using it: This means that even if companies decide to use Deno, finding experts would be challenging.
Conclusion, should you adopt it now?
In my opinion, if you're talking about using Deno for production apps, then you should NOT (for now). The technology is still in its early stages, which means the ecosystem isn't mature enough to support the thousands of use cases companies have for Node and also the common problems that will arise with Deno that don't have an answer in the JavaScript community. Finally, working with unstable APIs is a dangerous game. You can end up needing to create a pull request to Deno itself to support a critical application.
On the other hand, if you're talking about side projects, then definitely give it a go. The technology does provide great benefits as it is and should allow you to bootstrap a new project in no time. Also, the community is thriving, so the more you use it, the more you can contribute to its growth.
Just take in mind all the limitations I mentioned and enjoy building JavaScript apps with no node_modules folder. 🎉
Top comments (1)
Hi, I want to ask regarding
"Making npm the defacto standard: This creates a centralized and privately controlled entity that has great power over the whole ecosystem and things like this happen"
If we do not have centralized "library" distribution system, would not this be cause of:
Thank you