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.
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
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.”