Since its creation in 2009, Node.js has risen to become one of the most popular web technologies. It wasn’t the first to allow JavaScript processing on the server side—that was Netscape’s Rhino way back in 1997—its purity of focus in executing JavaScript outside of the browser made it incredibly popular.
You can see why: using the same language on the front-end and back-end simplifies things. You can code both front-end and server-side code without knowing multiple languages, and then reuse code in both. Plus, it has garbage collection, so there’s no messing with memory management or any of the underlying machinery. Create your business logic code and let her rip. That scripting simplicity is one of the reasons that Python was and remains so popular.
Plus it popularized event-driven programming (but didn’t really make it easy) at a time when that wasn’t really prevalent. Node.js only does work when it’s called on. It gets a request, fires a callback, and so long as nothing else needs to run, it sleeps. A huge leap for supporting a large number of concurrent users asynchronously. No wonder so many large web applications use it.
But that was 11 years ago, and in computing terms, that is ancient. While the Node.js ecosystem has grown to produce a vast number of libraries—there are over a million on npm alone—it’s based on a technology that itself has gone through 11 years of incredible growth. There’s been hack-arounds, but they’re still imperfect.
Node.js creator, Ryan Dahl, left the Node.js project in 2012 and started working with it again around six years later. In using it again, he found a number of design flaws that bothered him. In a JSConf EU presentation from 2018, he said, “Bugs are never so obvious as when you’re the one responsible for them.” So he decided to create a new implementation of his original idea: Deno. With Deno v1 releasing last week, that new version is available to everyone.
Why would you need a new standalone JavaScript runtime when Node.js performs perfectly fine? Well, read on, and we’ll cover the major changes, as well as what they mean for developers.
What is the difference between Deno and Node?
Like Node, Deno primarily operates on a command-line interface, which makes calling it from other programs easier. It’s built in Rust to be fast and includes a plugin API. Deno is designed to be a series of Rust crates, with deno_core as the primary, barebones runtime. Another crate provides bindings to the JavaScript V8 C++ API. So if another version of JavaScript supplants V8, all Deno needs to do is provide a new crate.
For many, the killer feature included in Deno will be the native support for TypeScript. TypeScript has had a huge impact on the JavaScript landscape, but it has to be transpiled into JavaScript in order to take advantage of its stronger typing and other features. But with Deno, TypeScript is now a first-class language. You can spare yourself the pain of debugging type errors without worrying about a complex build chain.
TypeScript has shot up in popularity recently, in a large part because of the easier maintainability and debugging that comes from a statically typed language, but also because of its adoption by popular front-end frameworks like Angular and React. By taking out the build step, Deno takes away yet another reason not to switch to TypeScript.
For a technology built for events, Node.js didn’t do a great job with them. It came out before the concepts of Promises or the async/await patterns, so had to come up with its own version. Early on in 2009, Node.js actually had a version of the promises abstraction, but it was removed in 2010. Instead, it went with the EventEmitter pattern. Unless you explicitly called pause(), any opened TCP sockets threw events at you non-stop, potentially drowning a stalled application.
Deno reverses this. Instead of explicitly stopping the flow from sockets, you have to explicitly read from them. They still operate asynchronously, just not constantly. Combine that with Futures, a Promises-like abstraction built into Rust, and you can manage incoming events much easier.
But no piece of web tech is an island these days, and Deno—like Node.js—will support a vast ecosystem of modules and dependencies. Node.js did this with npm, but though it had a central repository with npm, it was unable to prevent bad actors. Recently, some once useful packages updated and slipped in malicious code, exposing the difficulties in automatic updates.
Deno has been getting some criticism in how they manage dependencies. Instead of routing them through a package manager, Deno specifies each dependency module as a simple URL. You no longer have the protection of a central manager, but there’s no guarantee that this repository provides any more protection than a direct link to that code.
Like any modern browser, Deno executes all code in a sandbox; it can’t access the hard drive, network connections, or I/O peripherals without explicit permissions. Any code has to be executed with a flag that enables non-sandbox activities. And permissions are granular—you can grant access to a single hard drive or network location.
Dahl makes it clear that this isn’t a continuation of Node; it’s a whole new project. As such, it doesn’t currently mesh with the existing Node.js ecosystem. Most packages won’t work and the tooling is incompatible. That may keep people away for now, but as Paul Ford said on our podcast, “I am not bleeding edge anymore, but if you told me that a year from now I'm downloading to Deno instead of Node and using its package management approaches instead of npm anymore, I wouldn't be surprised.”
Whether this is a game changer for web applications or a useful update that doesn’t get its footing is to be seen. But on first glance, it could make the more recent advances to JavaScript (like TypeScript) standard procedure in server-side code.