Ryan Dahl: From Node.js and Deno to the ‘Modern’ JSR Registry
Ryan Dahl keeps finding new approaches to familiar tech. More than once, he’s played a central role in the evolution of an existing ecosystem. Now he’s part of an effort to modernize the many modules of code that developers import into their projects every day. And it’s not just upgrading repositories and supply chains, but ultimately the way that secure development gets performed.
On a recent episode of Stack Overflow’s podcast that featured Dahl, StackOverflow editor Ryan Donovan began by acknowledging that Dahl “started the whole JavaScript-on-the-backend movement” — before following it up in 2018 with the Deno runtime for JavaScript, TypeScript, and WebAssembly. On the podcast, Dahl succinctly summarized much of the commercial effort at the Deno project today: “to build, let’s call it, a cloud runtime, a multitenant JavaScript runtime that spans data center regions — spans clouds, even — and is set up to handle many, many users at once.”
But Dahl also recorded the interview just two weeks after Deno had announced the launch of the new JavaScript Registry, which Dahl said will ensure that its published packages “are modern and doing best practices.”
Dahl used the podcast to explain the multiple ambitions behind the project, offering a vision for what a secure repository will look like in the future.
And along the way, he even offered a prediction about what lies ahead for JavaScript…
Why JSR?
Among other things, JSR packages include type declaration files. But Dahl said the new repository is attempting to address the fact that JavaScript has two different module systems that “do not play well with each other” — CommonJS and ECMAScript modules (or ESM). As Dahl sees it, ESM is “now kind of embedded into all of the web browsers, the real way of doing modules.” (“ECMAScript modules have arrived as a standard,” explains the FAQ for the repository.) So the JSR supports ES modules only.
But in addition, “There are more JavaScript runtimes than just Node.js and browsers. With the emergence of Deno, Bun, workerd, and other new JavaScript environments, a Node.js-centric package registry no longer makes sense for the entire JS ecosystem.” And with TypeScript emerging as a de facto standard, “A modern registry should be designed with TypeScript in mind.”
Yet beyond that, Dahl sees it all in a larger context. “Deno in general is attempting to level up JavaScript…” he said on the podcast. “It’s incumbent on us as developers to really move this ecosystem into the future. And Deno is trying to do this at the runtime layer, but what we perceive is, really, a problem at the registry layer where you share code.”
The JSR isn’t meant as a replacement of the current npm package registry, but as an extension, Dahl explained. “In some sense, you can think of it as a superset of npm, kind of in the same way that TypeScript itself is a superset of JavaScript.”
Did you know that JSR packages can be used from Node.js with no configuration?
⬇️⬇️⬇️ pic.twitter.com/4AtwLtmX4q
— JSR (@jsr_io) March 6, 2024
But Dahl has given a lot of thought to npm. “For a very long time, they did not even keep checksums of npm packages. And there have been instances where hackers have gotten into the registry and potentially changed tarballs that were published, and there is no way to know because there is no checksum of those tarballs.” There’s also supply chain issues — the problem of not just malicious pull requests, but malicious code coming from upstream…
JSR attempts to provide more visibility with a simple way to give packages cryptographic signatures. Packages built on GitHub (using GitHub Actions) can provide an OpenID Connect token to JSR that will ultimately publish the corresponding cryptographic signature on the Sigstore blockchain. “We can do these ‘cryptographic attestations’, as they’re called, of where packages got built — and publish them in the package pages and expose these details to users.” In short, it provides a record of where the code is coming from. “And that is important for trust, right?
“It’s building up a web of trust.”
Later Dahl calls it in some ways “an extension of signed commits…”
“Things that I invented in 2010 for Node.js are just not where browsers are going now. And I think there’s a real need to close the gap between browsers.”
—Ryan Dahl
It’s all part of a vision for a more secure future. “At the end of the day, you’re going to take a number of dependencies and build your microservice and then run that as a Docker container in some Kubernetes infrastructure. And it would be very nice… to be able to say all software running inside this Docker container has attestations that trace it all the way back to a verified user somewhere and that there is no code that is running here that we don’t know where it came from.
“We’re kind of building up the infrastructure for this. And what likely will happen is, in the future, every microservice will have clear attribution for all of your dependencies. And that’s very nice — then you have really mitigated the supply chain risk.”
Dahl also stresses that the new repository (unlike npm) “is completely open source. The back end, the front end — the whole thing is open sourced and MIT licensed.”
JSR is not part of the commercial operations of the Deno company. “JSR is for the JavaScript community. It is an attempt to level up JavaScript, and it’s designed to be able to run very cheaply on commodity cloud software… We would eventually like to have this thing be in a foundation and kind of operating independently. We’re trying to build an institution here for the future of JavaScript.”
Now in its “public beta” stage at jsr.io, the JSR is officially billed as a package registry “for modern JavaScript and TypeScript.”
Dahl emphasized on the podcast that it’s not a package manager. “You can use your existing package manager but connect it to this new registry…”
Looking Ahead
At one point Dahl acknowledged that TypeScript was “very, very useful. It has clear utility.” So much so that he predicts its JavaScript-superset-with-types concept “is likely to be codified in standards. Maybe not this year or next year or the year after, but I think over time TypeScript will find its way into the standards and really become part of what JavaScript is.”
When asked for predictions about the future of JavaScript, Dahl started by saying the language is “deeply embedded” in today’s web ecosystem, and “It’s definitely not going away anytime soon… Unlike many other technologies in the world, I feel confident saying that JavaScript will be here five years from now, if not 10, if not 20 years from now.”
He even put it in the most pragmatic possible terms. “Like, your bank depends on JavaScript. It is not going away anytime soon.”
But looking specifically toward what’s to come, Dahl said “The future of JavaScript is browsers. Browsers will always dictate the future of JavaScript.”
So while there’s obviously a large community writing server-side JavaScript, “any server-side code must narrow the gap to browser JavaScript.” It’s part of why they’re pushing ECMAScript modules over CommonJS modules.
“Things that I invented in 2010 for Node.js are just not where browsers are going now. And I think there’s a real need to close the gap between browsers.”
