Deno v1.0.0 released to solve Node.js design flaws
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.
Tags: deno, javascript, node.js, rust, stackoverflow, typescript
18 Comments
> “It wasn’t the first to allow JavaScript processing on the server side—that was Netscape’s Rhino way back in 1997”
Actually, server side JavaScript has been a thing since the very beginning of JavaScript, even before it was called JavaScript! Back when it was still called LiveScript, it was part of the Netscape LiveWire web framework, and released roughly around the same time as Navigator 2.0. In fact, the reason it was renamed from its codename Mocha to LiveScript was so that it would match the name of Netscape’s web framework.
Server side was in its DNA and even in its name from the very beginning!
It is really funny when you think about it: the management at Netscape was actually skeptical about whether it makes sense to develop a second scripting language for the browser since they had just signed the deal with Sun to ship Java in the browser. It is easy to forget that Java was designed as a scripting language for Interactive TV and when Interactive TV never became a thing, Sun pushed it into the client-side web space. Nobody saw Java as a server side language.
In the mind of Netscape’s executives, Java was the client side scripting language, and LiveScript was for the server.
Whoa! Thanks for the history lesson. Fascinating how wrong some of the early tech expectations were, even though those technologies still live on.
I wonder why deno why just upgrade nodejs, why two different concepts and I wonder if all this means the death of Node.js
You can not update nodejs. This is a new project with different aims. Updating nodejs will break all packages. NodeJs will not die, It will continue to live side by side. If deno becomes very famous, it might get all the users of server-side javascript.
JavaScript got its name from motorcycle brand called Java, which the inventor drove with. This LiveScript came later to hide the real invetor, like most of the time when big corps hide small inviduals to steal their work.
I used to write classic ASP sites back in the late 90s, using both server- and client-side javascript. Because VBScript s*cked (and still does). Since the client- and server-side code could potentially be in the same file, the only difficulty was keeping it in your head which bit of code ran where.
| “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.”
Node’s central manager, NPM, is run by a private company, and they’ve had a rash of malware infections of late – so the grass is always greener in this case, arguably .
Also, if you watch Mr. Dahl’s Deno talks linked to in the article, you’ll see that the caching mechanism for code-import URLs has been well thought-out by the Deno architects. URL imports function more like canonical resource names, as opposed to dynamic linking (in fact, I believe Deno’s imports are statically processed and cached separately from the program’s execution, to specifically facilitate this sort of use).
Interesting article! A few additions that I think are worth mentioning:
(1) The NodeJS API also supports new language patterns (async iterables, promises, modules), however it has a large problem with backwards compability, that leads to very hacky workarounds (.mjs files, additional promisified APIs like `fs.promise`, …). Starting from scratch allows Deno to get rid of all of that.
(2) I think the most popular npm packages are actually the ones that fill gaps in the standard library (e.g. Express for running web servers, as the NodeJS http module is not that easy to use). Therefore as Deno has a better standard library, the ecosystem doesn’t have to be as large as the one of NodeJS. Therefore starting from scratch is not that bad for adoption.
(3) The great advantage of Deno’s module system is that you have zero configuration. To set up a basic webserver, all you have to do is to copy an example from the docs, and run it. No need to install dependencies, fix conflicts, set up a build step, and so on and so forth. Also it opens up new possibilities for distributing code, e.g. repositories that respond with different modules for development / production, A / B testing, or that have secrets baked in.
In general I think Deno is a great step forward for the JS ecosystem, and I’m really looking forward to use Deno in production somewhen …
Please let’s make sure the discussion isn’t about “Node.js vs Deno”. Deno is at a point where people can contribute and explore so let’s focus on the “building things” and “exploring” parts.
> 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.
Suppose, an application requires a network connection and the permission is granted, how do we know that the application will make ‘honest’ use of this granted permission and, therefore, the resource?
The permissions are pretty granular. You can open up network access to specific URLs or IP addresses only.
Crazy, learned something new today, thank you. LiveScript exists but it’s just the same name. It’s very interesting how little we know about history of our own domain, somehow things change so fast that people are not even aware how things got where they are.
I like a lot of the motivations behind Deno but I honestly don’t see it gaining wide adoption, for a few reasons:
1. You mentioned package management, but it bears repeating. Deno has *no* package management. It’s not meant to have any. This is a huge leap backward. Wider stdlib or not, the JS ecosystem has coalesced around the Semver philosophy, and trading that out for static URL imports is not a pragmatic change by any means.
2. API incompatibility – *all* non-web javascript is written for Node. There’s a decade of package development sitting atop the firm foundation of Node.js. It’s going to be very challenging for Deno to reach critical mass when starting from square one.
“You don’t need Express anymore,” you say. Well, I don’t see what’s wrong with using packages depending on what you need — I don’t want an advanced routing system baked into my standard library when I’m just trying to write a script. Do one thing, and do it well.
3. The above points wouldn’t be an issue if Deno offered something crucial that Node fundamentally couldn’t offer. However, I’d argue that it does not. It’s been able to implement features that would take Node a long time, but API changes for Node take time for good reason; they’re preserving the aforementioned decade of development. That’s not to say that Node CAN’T implement this kind of thing, just that it takes longer. Mature software is a good thing.
There isn’t anything stopping Node from introducing opt-in command-line security permissions or a wider stdlib. In fact, most of the Node stdlib already HAS promisified alternative methods.
I have never encountered problems with backpressure in Node servers. Do we need to rewrite from the ground up to solve that problem?
TL;DR: I don’t see Deno as anything more substantial than hype.
And Microsoft is going sky rocket!
Ok, TypeScript is open source, but the merchandising is good for them.
youarecorrect
Hmm…De-no. I’ll pass. The main design flaw of Node.js is…Javascript on the server. There’s always someone who forgets how to write small, resource efficient software. Deno simply continues the main design flaw of Node.js by shoving Javascript in another place where it doesn’t belong. That reminds me of someone not too long ago attempting to decode a 1GB JSON array from a local file in a web browser they had generated and then asked me why it was “taking forever to load.” In some ways, I miss the 1980’s when people were forced by the architecture to not be lazy (I don’t miss the painfully slow 4MHz hardware – just the mentality of efficiency).
Did you know that PHP is an amazing *command-line* scripting language? And it is still being developed today? And you can make async servers in PHP? And has a much smaller resource footprint than Node? If you didn’t know any of those things, then you’ve been out of the loop for the last decade.
And C is still kicking. When you need *real* performance, nothing beats good ol’ C (and assembler). Sure you can find some areas here or there where other languages have a slight edge, but C is an inch away from the metal while any scripting language, no matter how good it is, is a mile away from the metal. Clock cycles still matter.
Another framework.. !!! Duh.. another year and people would be releasing something else.. with increasing demand of JavaScript I think it’s
“Too many Chef spoil the broth”
Many thanks for shining a spotlight on Deno, Ryan.
I’d planned to learn Node.js in 2018, but after making headway only through some of the basics, other projects and technologies diverted my attention.
More recently, I’ve caught up with a few side-projects and I’m ready to resume learning (and eventually mastering) Node.js, once again.
But now that it’s stable, I’m increasing persuaded that I should focus on Deno instead.
Promises? ES Modules? Typescript?
These three considerations, not least, suggest that it’s Deno rather than Node.js which will evolve to become the beyond-the-browser JS runtime of the 2020s.