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.
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.”
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.”
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.
Rather than using npm, Deno has opted to use modules referenced as URLs or file paths.
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.
Red Hat is a sponsor of The New Stack.
Feature image via Pixabay.