Ryan Dahl, creator of Node.js and Deno, tells us about his journey into software development and the creation of Node.js. He explains why he started Deno, a new JavaScript runtime. Ryan also introduces JSR, an alternative to NPM, and emphasizes the importance of security in the JavaScript ecosystem. Plus: Thoughts on the future of JavaScript, including the role of TypeScript and bridging the gap between server-side and browser JavaScript.
Node.js® is an open-source JavaScript runtime environment.
Deno is an open-source JavaScript, TypeScript, and WebAssembly runtime. Explore the quick start or check out Deno by example, a collection of annotated examples of how to use Deno.
JSR is an open-source package registry for JavaScript and TypeScript.
Keep up to date with Ryan on GitHub or his blog.
Shoutout to Stack Overflow user Squadrons, who earned a Great Question badge by asking for a Pure javascript method to wrap content in a div.
Chapters:
00:00: Introduction and Background
01:08: Creating Node.js
05:00: JavaScript on the Server Side
07:23: Impact of Node.js
09:18: Edge Function System
12:13: Protecting Against Malicious Use
16:02: JSR: Alternative to NPM
31:01: JSR and its Stage
34:20: Future of JavaScript
36:19: Closing and Shoutouts
[intro music plays]
Ben Popper If you’re building AI apps with popular models like YOLOv8 and PaDiM, you’ll want to visit intel.com/edgeai for open source code snippets and helpful guides. Speed up development time and make sure your apps deploy seamlessly where you need it most. Go to intel.com/edgeai.
B Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by the illustrious Editor of our blog and newsletter, Ryan Donovan. Ryan–
Ryan Donovan Yes, sir.
B Popper You brought us a great guest today. You want to set us up? Who are we going to be chatting with today?
R Donovan Sure. We're going to be talking today with Ryan Dahl, who is the creator of both Node and Deno. He started the whole JavaScript on the back end movement, and we'll be talking about all the ways that his Deno product has progressed, the ecosystem he's building out, taking over the world and all that.
B Popper Sweet. Ryan, welcome to the Stack Overflow Podcast.
Ryan Dahl Hey! Nice to be here.
B Popper So we won't spend too much time on history, but just for folks who are listening, can you tell them a little bit about how you got into the world of software and development and what led you to creating Node.js in the first place?
R Dahl I started in math. I was in a PhD program for learning algebraic topology when I realized that all this abstract math stuff was not very relatable to what humans were actually doing and dropped out. And over the course of a couple of years, I kind of found my way into web development and then into server development. And in 2009, I was really kind of thinking about how to write fast web servers when Chrome came out, and with that, the V8 JavaScript engine, and I kind of connected the dots that actually non-blocking servers and V8 would potentially be a pretty killer programming platform and created Node.js, and that was a pretty successful project.
R Donovan It definitely seems so. I know that Node has been around for what– 10-15 years now, and then you started Deno as sort of another JavaScript server-side engine. Why start something new?
R Dahl When Node was doing well and having lots of contributors around 2012, I left the project. I felt like it was on good footing and went and worked on other stuff for a number of years. And it wasn't until 2019 or so that myself and a collaborator from the early Node days, Bert Belder, got together and started working on Node projects again. We were in particular trying to take TensorFlow and bind that to Node to do data science-y statistic-y sort of things and found we were both pretty disappointed with the state of affairs in 2019. We were just like, “Node should be much better than this. So many years have passed and it seems to be roughly in the same state that we left it in in 2012.” And that started a small little demo project to create a new JavaScript runtime, and that actually started getting quite a lot of attention. We started getting lots of contributors. The idea of it was kind of TypeScript first. In 2019, it was pretty apparent that TypeScript was kind of the natural successor for larger JavaScript projects, and using Rust instead of C++ for the actual implementation. And we worked on that for a while before realizing that actually there's tens of thousands of users of this project already and there's potentially an opportunity to build a business around this as well. So we founded the Deno company and are continuing to build the open source projects. Of course MIT licensed like Node, very, very free, but are also building commercial projects using that technology in other settings.
R Donovan I think when V8 first came out, most people thought of JavaScript as just client-side. Why do you think it took off so well on the server-side?
R Dahl So it turns out that programming user interfaces, programming websites, is very, very similar to how you program web servers. So when you're programming a website, you might have a button, and then you have an onClick handler, you get a little callback that you program some logic when that thing is triggered, that's actually pretty similar to how you program a non-blocking HTTP server. So instead of having a button that gets pressed and then get a callback when some UI interaction happens, when you get a new request to the server, when you get a new connection, when a new byte of data gets sent to you, you trigger a callback. And JavaScript is just really minimal in the sense that it did not have any pre-existing IO libraries. There was no way to write to standard out. There was no way to open sockets. There was no way to do any other IO things, and in fact, there was actually only a single thread. So for kind of technical reasons, adding a server onto JavaScript worked really well and people who were programming front end websites were able to take those same skills and with just a small amount of additional knowledge were able to program pretty nice web servers that could do long polling or other kinds of real time interactions. And I think there's just a large base of JavaScript users out there, naturally, it being the language of the web, and so there was a lot of people who were able to take their skills and add on Node to that and suddenly become full stack developers.
B Popper So do you have a sense of the magnitude of how many people are touching these tools? Is that something you can measure through open source contributions or other kinds of research? You mentioned when you left the project that you felt it was well sourced with great contributors and you could move on to something else with a friend, but how do you look at sort of the impact in the ecosystem of what you've done these days?
R Dahl For Node, it's kind of hard to understate it. Essentially all websites use Node in some form. I would say a good majority of HTTP requests that are made in the world are touching Node in some form. Maybe you're not using Node for the back end infrastructure, maybe you're using Go, but your front end framework is certainly using Node to bundle your JavaScript together. So it is involved with essentially all websites. I would say most professional engineers have touched Node. We don't know the exact numbers, but tens of millions of developers, I would say. It is very popular. Deno is much, much smaller than that, much more nascent, but we estimate it in the hundreds of thousands of developers that are using it.
B Popper Cool.
R Donovan That's going to be cool to think about, and a little overwhelming. So it does seem like, realizing that, it's almost like web development is events all the way down. Moving some of those events to the server side makes sense. And I know when I first reached out to you all it was because of the distributed edge network stuff, edge function stuff that Netlify was doing. You all have built a sort of edge function system for Deno. Why build that and not let individuals handle that on their own?
R Dahl It's deceptively complicated. So essentially our infrastructure is called Deno subhosting. Deno Deploy is kind of one instance of this, and it is the technology that is powering Netlify edge functions. It is deceptively complicated to deal with kind of a multi-tenant system. You're running untrusted code from many thousands of people all at once and you're trying to spin that up as quickly as possible and kind of service requests as quickly as possible. And there's definitely been a number of attempts to build this sort of infrastructure, but if you kind of go down this route a little bit, you realize pretty quickly that it's harder than it seems. There's pretty serious security concerns. There's pretty serious performance issues that you need to worry about. You really need to worry about how fast can you respond to a request when you know nothing about it. A new request comes in from a random person, you might not have that code cached on the local server. You’ve got to go fetch that code, you’ve got to load it up into a V8 isolate, you’ve got to respond to it. Making all of that stuff work as efficiently as possible is relatively difficult, but that is the main bet of our commercial work at Deno– to build, let's call it a cloud runtime, a multi-tenant JavaScript runtime that spans data center regions, spans clouds even, and is kind of set up to handle many, many users at once.
R Donovan You talked about adding kind of file IO and web sockets and other kinds of IO things to JavaScript. In that multi-tenant massive worldwide architecture, how do you protect from those additions being used maliciously?
R Dahl We're pretty careful about what sort of things we expose to users. It depends on what system you're talking about. In the Netlify edge functions, there is no file system at all. In Deno Deploy and Deno Subhosting, there's kind of a file system, but it's read only. We do support WebSockets. WebSockets are just kind of upgraded HTTP requests and so there's no real problem with handling those other than the fact that this is a serverless environment and isolate VMs can can be garbage collected essentially at any moment, so you don't really have any guarantees that you're going to have a persistent web socket connection. But being able to expose WebSockets is totally fine for us as is kind of long-polled HTTP requests, that is HTTP requests that don't respond Immediately. And part of what we're trying to do with Deno Deploy is find the new abstraction layer at which you can do servers. So I think one pretty obvious abstraction layer is Docker containers. Every server is a container, and this is kind of the Linux abstraction layer. You write a Linux program, maybe in Go, maybe in Node, you put it in a Docker container, but you're effectively programming against Linux syscalls and most likely in an x86 architecture. That is, in my opinion, a very useful abstraction layer and obviously there's all sorts of infrastructure built on top of that. But I think there's a higher abstraction layer that's starting to emerge where you as an application developer, you as a back end programmer that's just implementing some app, you don't really care about Linux. You don't care about Linux syscalls, you don't care about systemd, there's just all sorts of stuff that is present at kind of the Docker container, the Linux container abstraction level that is effectively unnecessary details for most developers. And what we're trying to do is kind of raise the bar here to something that is not necessarily as general purpose. You're not going to use this thing to build a database, or you're not going to use this for all sorts of things, but this kind of JavaScript abstraction layer where it's not necessarily running on Linux. There isn't necessarily a file system, it's kind of a higher abstraction layer where you can do fewer things but you can do them more easily. I guess I think of it as kind of a post-Unix future. Is there kind of an emerging abstraction layer that is not Unix that potentially we can program against in the future but much more rapidly? I think the jury's still out. These are emerging products right now, and Netlify edge functions, Deno Deploy, Deno Subhosting, Cloudflare Workers is definitely part of this ilk, are all kind of trying to figure this out. And it seems like a good idea, but it's still very much under development.
R Donovan It seems the way of all development is that you either go up an abstraction just making CRUD apps or whatever, or you go down to the bare metal, and I think differentiating those more and more is probably pretty helpful for developers.
B Popper So Ryan, you mentioned you also have another project that you're working on– JSR, which is an alternative to NPM. You want to tell us a little about that?
R Dahl So Deno in general is attempting to level up JavaScript. So I don't know how much you all are kind of living in the JavaScript ecosystem, but like I said, when we started Deno, we really found ourselves in a world that hasn't changed over many, many years, and part of what we're trying to do with Deno is really kind of level up the system. So not to get too technical here, but for example, the whole CommonJS versus ESM module system problem is really annoying for many, many developers. Maybe if you're just building a website you're not really exposed to this, but there's all sorts of complexity in the fact that JavaScript effectively has two different independent module systems that do not play well with each other, one called CommonJS, which largely Node invented in kind of the early 2010s, and ECMAScript modules, ESM, which is a standard defined by TC39 and now kind of embedded into all of the web browsers the real way of doing modules. And Node has been very slow at adopting ESM. There's also the conversion from JavaScript to TypeScript going on and a number of other initiatives. JavaScript is unlike other languages. It is, in some sense, the most important programming language because it is inherent in the web. It is kind of like a protocol in some ways. You can think of it on similar footing to HTTP or CSS or HTML. It is definitely not going away tomorrow. There's all sorts of human infrastructure built on top of this stuff, and because of that, JavaScript needs to evolve. JavaScript is not like, let's say, Ruby, which may very well just disappear. There's obviously a bunch of stuff built on top of Rails, but it's not inherent to civilization in the same way that JavaScript is. So 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. NPM itself has been very successful, has millions of published modules on it and a great resource for any developer, but it has effectively stopped evolving many, many years. In the last five years there has been essentially zero feature development in NPM. I think the newest feature they added was three years ago when they added the files tab to the package website so you could browse the files that are in packages before you see them. It's just very, very slow and this is just insufficient for the world's default programming language. So what we are working on is a project called JSR, it's at JSR.io. It stands for JavaScript registry, and it is a modern place to publish your JavaScript or TypeScript code and it is much better. It is much, much better in many, many ways. Despite this being me contrasting this with NPM, there are real network effects around the NPM ecosystem and we are not trying to replace NPM wholesale. JSR is meant to be an extension of NPM, so JSR packages can depend on NPM modules. 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.
R Donovan That's interesting because my sense is that NPM sort of evolved organically and was a little bit of an ad hoc process, but a lot of times when I hear about some sort of breach or issue, it's that somebody took over an NPM module and they injected some code into it and suddenly everybody who has that package is exposed.
R Dahl There are a number of very concerning security problems with 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 all sorts of supply chain security problems beyond hackers literally getting into the registry. You can accept a pull request from some random person and it may inadvertently inject some code into your package. JSR has security features, modern security thoughts around this. You can never 100% say that some code uploaded by a random person on the Internet is going to be safe, but we can give more visibility into this and we do this in particular with a system called Sigstore. So the way this works is often you build your package on GitHub through GitHub actions, and what we can do is get an OpenID Connect token from GitHub from your action so that we know that this GitHub user ran these commands to produce this package and we can get a cryptographic signature of that package. And on the JSR side, we can publish that signature to the Sigstore blockchain that keeps a persistent log of all of these packages. And so while we can't say for certain that this package is security free, what we can do is say, “Ben published this package at this date. These are the commands he ran. As long as you trust GitHub, we can at least say that.” Maybe GitHub got hacked, maybe Ben gave his password to somebody. We can't say everything about it but we can at least say that it happens. So anyway, we can do these kinds of cryptographic attestations as they're called of where packages got built and publish them in the package pages and just kind of expose these details to users. And what you would hope is that if in the future there is a problem that is discovered with some package, that you can go back and look at the record or lack of the record maybe as a signal that you shouldn't use the package. But you can go look back at the record and at least go back through the steps and say, “Okay, well, Ben published it at this date. I guess we should sue him.” I don't know, it just gives you a record of where this code is coming from and that is important for trust. It's building up a web of trust.
R Donovan It seems like the sort of chain of commits that GitHub publishes naturally, right?
R Dahl Yes.
R Donovan To make sure that you know exactly who's touched it and when.
R Dahl And in some ways, it's an extension of signed commits.
B Popper Ryan, I'm trying to recall, I feel like we had somebody on the podcast not too long ago who was trying to expand on the Sigstore model. Maybe it had something to do with blockchain?
R Donovan I think we had somebody who was related to Sigstore.
R Dahl Beyond the Sigstore stuff, Deno has security features itself. So V8 is a secure sandbox and we do not allow people necessarily to touch the file system or make network connections. Kind of by default you are in a JavaScript sandbox without the ability to reach out of it. And so unlike in NPM and in Node where if you NPM install a module, because of post install hooks, you are literally running untrusted code, unaudited code from the internet. It is super dangerous to NPM install something and the only way that you are not getting hacked at every moment is just through random trust of random people on the internet. It's a very bad situation. In Deno, we gate all of these accesses. You cannot open a random connection to a random web server just willy-nilly. You need to give the permissions to make outbound connections, in the same way that not every website can open up your camera and start taking photos. You have to give permissions to allow the website to do that. These are, in my mind, very obvious next steps for server-side JavaScript. It needs to act more like web browsers are. And security is a main concern, because what we're really talking about is untrusted code from the internet. You need to think carefully about that.
B Popper I've got it here now. It was Craig McLuckie, who's the co-founder of Kubernetes. He started a new company called Stacklok. And again, I think a lot of their reason to exist was their frustration, similar to you, Ryan, with all of the security issues on NPM and the fact that people tend to just trust it because it's the easiest solution, but really, it's creating a lot of harmful weaponized packages and supply chain issues, et cetera, et cetera.
R Dahl I don't know the exact details of Stacklok, but in Kubernetes, the hope is that you can kind of take these package attestations really far. So we can verify that Ben ran these commands to create this package. Those are published alongside your package in JSR. 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 and Kubernetes is starting to have tooling around this, and my guess is that that's what Stacklok is working on– 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. All the code traces back somewhere. And that would be very nice, especially if you're a big enterprise and you have very serious security concerns, you kind of want, just from a compliance angle, to be able to say, “Hey, we know who wrote the code that we are running right now.”
B Popper It's coming back to me now. There's a cryptographic signing and a transparent ledger and an open set of logs and that sort of thing.
R Dahl 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.
R Donovan I think the open source movement has been wonderful in a lot of ways, but it's also made people very aware of their code supply chain and dependency issues, just because every website is built by a village now.
R Dahl Yeah, it's a double-edged sword. On one hand, you can go pick up utilities for free that do very powerful things, but on the other hand, where did that come from? You have no possibility of auditing all of the code that's in your stack anymore. It's just too big. So you kind of really need these systems like Sigstore.
R Donovan So JSR, what sort of stage is it and how do people hook into it when it's ready?
R Dahl So it just launched like two weeks ago, so I would say it's very early in its efforts. JSR is really important. I think there's a lot of confusion because there's a lot of package managers in the NPM ecosystem, but this is not a package manager, this is a registry. So you can still use Yarn, you can still use NPM, you can still use PNPM. You can use your existing package manager but connect it to this new registry. And so if you have, say a Remix website, you can pull down JSR packages and integrate that into your website, despite the fact that you use Yarn and existing package managers. So there's no need to kind of flip all of your infrastructure around. It's kind of only benefits. These packages that you get from JSR all have proper DTS files, TypeScript declaration files, so you'll get proper inline documentation in your editor and IntelliSense and all of those great things. JSR kind of ensures that the packages that get published there are modern and doing best practices. I guess I should also mention that JSR, unlike NPM, is completely open source. The back end, the front end, the whole thing is open sourced and MIT licensed. And I mentioned that we have the Deno company that is, of course, a for profit business. JSR is not part of our commercial operations. 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. So we have no problem paying for this in the short term, but if JSR doesn't crash and burn and persists, which I think it has a good chance of doing, I think it's pretty good 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.
B Popper Cool.
R Donovan I'm sure there's plenty of foundations out there. I can think of a couple, two or three, that would do well to pick it up. So Ryan, what do you think is the future for the JavaScript ecosystem? Do you think it'll be more on the back end, more frameworks? Do you think JavaScript itself will start changing more?
R Dahl First of all, I think there is definitely a future for JavaScript because it's so deeply embedded into web browsers. It's definitely not going away anytime soon. And 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. Your bank depends on JavaScript. It is not going away anytime soon. And I think the future of JavaScript is browsers. Browsers will always dictate the future of JavaScript and so any server-side code must narrow the gap to browser JavaScript, and hence our efforts to push forward ECMAScript modules versus 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. Beyond that, I think TypeScript is very, very useful. It has clear utility. It is so successful because it's been so restrained in what it has developed. It's really just a superset of JavaScript with types added onto it. And I think this 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 kind of find its way into the standards and really become part of what JavaScript is.
[music plays]
B Popper All right, everybody. It is that time of the show. We want to shout out someone who came on Stack Overflow, shared a little knowledge, maybe a little curiosity. A Great Question Badge was awarded to Squadrons nine hours ago for asking a great question that's got a score of 100 or more. “I want to wrap all the nodes within my slides container div with JavaScript. I know I can do it in jQuery, but I want to know how to do it with pure JS.” Well, if you want to do that as well, we’ve got an answer for you, and we've helped 161,000 people, so appreciate the question, Squadrons. I am Ben Popper. I am the Director of Content here at Stack Overflow. Find me on X @BenPopper. Hit us up with questions or suggestions for the show: podcast@stackoverflow.com. And if you enjoy the program, leave us a rating and a review.
R Donovan I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to reach out to me, I'm on X @RThorDonovan.
R Dahl I am Ryan Dahl. I am working on Deno. You can find it at deno.com, and you can find JSR that I mentioned here at jsr.io. I don't have a Twitter, but you can find my blog at tinyclouds.org.
B Popper Sweet. All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]