Development / Open Source

How Node.js Is Addressing the Challenge of Ryan Dahl’s Deno

2 Nov 2020 6:00am, by

Node.js, the open source JavaScript runtime, released its 15th version last week. Now in its 11th year, Node.js is as popular as ever, but in 2020 an upstart competitor has emerged. Deno, an open source JavaScript runtime released in May, was created by none other than Ryan Dahl — the original author of Node.js. Even worse than having a competitor who knows your product inside out, Deno was created specifically to fix what Dahl perceived as the key weaknesses of Node.js — including security issues, use of a centralized repository system (npm), and “heavy-handed tooling.”

To find out how the current generation of Node.js maintainers are dealing with the new challenger — and by extension, what they’re doing to address Dahl’s criticisms — I interviewed Bethany Griggs, a Senior Software Engineer at Red Hat and a Node.js Technical Steering Committee Member. Griggs has been involved with the Node.js project since 2016, primarily with the Node.js Release Working Group.

Richard MacManus
Richard is senior editor at The New Stack and writes a weekly column about what's next on the cloud native internet. Previously he founded ReadWriteWeb in 2003 and built it into one of the world’s most influential technology news and analysis sites.

Node.js enables developers to execute JavaScript code outside a web browser. Its original purpose was to create dynamic web pages on a server, before sending to the browser; meaning the JavaScript code got executed server-side, rather than on the client. More generally, Node.js has become the default for backend web programming (while the likes of React and Angular are used for the frontend). The idea being that developers can use the same language, JavaScript, for both backend and frontend.

Node.js is also highly scalable and has an event-driven programming model, both of which have made it a good fit for cloud native applications.

“Node.js continues to be one of the leading runtimes for building cloud native microservices and backend applications,” Griggs told me. She added that “it’s also popular for IoT [Internet of Things] projects — one of my favorite examples is NASA using Node.js to monitor space suit data.”

Spacesuits aside, Node.js is no longer seen as the hot new thing of JavaScript development (Next.js, a frontend React framework, has perhaps taken that mantle). And compared to the cutting edge nature of Deno — for example, Deno was written in the trendy new programming language, Rust — the Node.js project follows a relatively conservative development path nowadays. So it’s no surprise that version 15 of Node.js is an incremental upgrade.

Griggs cited “throwing by default on unhandled rejections” as being the most significant update in v15. This means developers can now get “early feedback that they’re omitting the handling of an error in their application.” A valuable technical update, no doubt, but not likely to generate enthusiastic discussion on tech Twitter.

Responding to Ryan Dahl’s Criticisms

What I was more curious about, was whether the Node.js project team has undertaken any new developments, or fixes, to address some of the concerns Ryan Dahl has raised over the last couple of years?

A couple of years ago, Dahl did a presentation about his regrets after creating Node.js. A major one was that he didn’t make the runtime as secure as he could have — something he addressed when creating Deno, which is promoted as being “secure by default.” Deno’s approach to security is to put safety rails around data access; as described in its manual, “Deno requires explicit permissions for file, network, and environment access.”

Ryan Dahl at JSConf EU 2018.

Diplomatically, Griggs told me that Node.js will “take inspiration from” Deno on this and other issues. However, she said that the Node.js project “has had a history of discussions around security enforcement and limiting access to APIs from before Deno was announced.” She pointed to a couple of “experimental features” for security (example 1, example 2).

Also, Griggs isn’t convinced that Deno’s safety-first approach to access is right for Node.js. “For practical applications,” she said, “you’d quickly have to fall back to granting access to many APIs, so the net value versus complexity would be low.”

Although there is interest among the Node.js project team in experimenting with stronger security features, according to Griggs “there has not been a compelling case to adopt all of the same tradeoffs as Deno.”

As for Dahl’s criticism of npm as a closed ecosystem for modules, Griggs sees no reason for Node.js to change that.

“With respect to how modules are managed, the module ecosystem has been a big part of the success of Node.js. While there are ongoing discussions around the integration of clients — the registries which serve modules — the main focus has been on adding support for ES6 [the 6th edition of the JavaScript specification] modules, rather than changing how they are managed.”

Rather than using npm, Deno has opted to use modules referenced as URLs or file paths.

Server-Side JavaScript Still Going Strong

With the current popularity of JavaScript frameworks like Next.js and Gatsby, together with the rise of Jamstack and its static site generation approach, I asked Griggs if that has impacted the use cases for server-side JavaScript?

“There may be a reduction in the use of things like templating engines for server-side rendering,” she said, “but Node.js is still used heavily to build the microservices that back the static pages that may be deployed using approaches like Jamstack. Node.js also continues to be heavily used in the tools that make up the development pipelines for client-side JavaScript.”

The Futures of Node.js and Deno

So what’s next for Node.js? In the announcement post about version 15, Griggs wrote that after celebrating the tenth anniversary of Node.js last year, “the project has kicked off the Next 10 Years of Node.js effort. ”

I asked Griggs what kinds of initiatives the project members are looking to implement over the next decade?

“So far we’ve defined our priorities as developer experience, stability, operational qualities, Node.js maintainer experience, and up-to-date technology and APIs,” she replied.

These are currently outlined in a GitHub document entitled Values and Priorities. Security is mentioned once, as a sub-category of “Operational Qualities,” and states simply: “Addressing security vulnerabilities in a responsible manner.”

It doesn’t seem like a high-bar goal for the next decade, especially compared to Deno’s more ambitious goal of trying to avoid vulnerabilities in the first place.

But since Node.js is a stable and relatively long-running project, and caters to some very large enterprise software vendors (like Grigg’s employer, Red Hat), you can’t blame the maintainers for being conservative. Although it does leave an opening for others to think bigger and bolder about the future of server-side JavaScript — which is exactly what Dahl and his Deno project are doing.

Red Hat is a sponsor of The New Stack.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.