Matt Arbesfeld:
Hi, everyone, and welcome to PodRocket. I'm Matt Arbesfeld, CEO and co-founder here of LogRocket. I'm excited to have a very special guest today, Ryan Dahl, who's the creator of Node.js and Deno, a titan in this industry.
Thanks for joining us today, Ryan. We're really happy to have you on.

Ryan Dahl:
Yeah, thanks. Thanks for having me on.

Matt Arbesfeld:
Today, we're going to be focusing on Deno, how it originated, where it's at now, where it's going in the future, but, before we get into that, we'd love to learn more about how you got into software engineering in the first place. I think you have a mathematics background, if I saw that correctly.

Ryan Dahl:
Yeah. I've been programming since I was six years old and just always had computers in the house, but, in college, I was more interested in math and pursued a bachelor's degree and then a PhD which, halfway through, I realized actually I don't want to be a math professor. I'm not smart enough to be a math professor. It's too difficult. I was like the computer nerd of my math graduate school. Yeah, I just have always been interested in software stuff, but, after dropping out of that PhD program, basically fell into programming pretty quickly, doing little contracts here and there.

Matt Arbesfeld:
Was Node a side project? What was the origins of Node in the first place?

Ryan Dahl:
I was doing some work for a company called EngineYard which was providing Ruby on Rails Hosting, and I was thinking a lot about how to make Ruby on Rails faster. There was a lot of people thinking about that. EngineYard was contracting me to implement a NGINX plugin. NGINX is kind of this Web server written in C and does a lot of asynchronous I/O. I was thinking about Web frameworks and async I/O, and then Chrome came out. This was 2009, and, with Chrome, came the V8 JavaScript engine. Async I/O and JavaScript and Web frameworks all just clicked together in my mind. Yeah. Basically, Node was a scriptable Web server, scriptable in JavaScript. Just working in the right place at the right time, those ideas mesh well together.

Matt Arbesfeld:
Was that the first async single-threaded Web framework at the time, or was there predecessors to that sort of mindset?

Ryan Dahl:
There were predecessors. Python has Twisted and Ruby had EventMachine. I was very much looking at those at the same time. The idea behind async I/O before, it's very common today. Almost any programming language you use, anything you use, you're going with async I/O and non-blocking I/O. At the time, the common paradigm, this was 13 years ago or so, was to open a thread for each connection. It was considered very difficult and low-level work to actually make use of non-blocking I/O and multiplex multiple connections into a thread. It was very advanced stuff. Twisted and EventMachine showed that this could be done in scripting languages, and those were certainly inspirations, but they were always add-on. They were not the common way of doing things.
I think the big problem with it was that, when you use async I/O, really, everything needs to be async I/O. You can't accept a connection from the Web server in a non-blocking way and talk to that socket in a non-blocking way, but then make a database connection with the blocking using blocking I/O. If you're in Python, the typical, whatever, MySQL client ends up being blocking, and you can't use it in Twisted. This just becomes really hard for the everyday user who's just trying to make a website and doesn't want to think about this stuff. Ultimately, they're exposed to all of this low-level stuff.
What was really nice in Node was that we could just start saying there is no blocking I/O. Every socket connection you make needs to be non-blocking and, if you're forced into that world, then every user does it. You don't need to know anything about it. It's all just non-blocking, and that is basically the case today if you are using, say, Go or you are using Rust or Node or Deno or any other language these days. You're typically driving I/O with non-blocking.

Matt Arbesfeld:
That makes. I remember, in the early days of Node, you'd have these huge waterfalls of async calls, now much cleaner with the async/await syntax.

Ryan Dahl:
Right. This was all done with callbacks, right? This was before people really realized that there was this syntactic transformation that could be done to write non-blocking, essentially write callbacks like they were blocking, so the cognitive overhead was pretty high. It's like, okay, well, after every single async call, I need to have a callback, and that's going to increase the invention level. I had not realized at the time that this sort of syntactic transformation with async/await could be done, but I knew that, ultimately, the benefits outweighed the consequences.
Actually, I think the real awesome thing was that client-side JavaScript programmers were already used to using callbacks because, if you have some UI element that has a button or you're making an XHR call or just a typical JavaScript use cases where JavaScript is ultimately single threaded and is callback driven. That sort of non-blocking network I/O actually was not a huge leap for a lot of programmers unlike it would be in Python or Ruby where people are just like, "I have to do what? Yeah. No, I'm not going to do that. I'll just use a thread per connection. It's not that expensive."

Matt Arbesfeld:
Cool. Then moving, I guess it was four years ago now, you started Deno. Maybe could we talk about the inspiration, what led you to build a new runtime for JavaScript?

Ryan Dahl:
Node has been surprisingly popular. It's not really a stretch to say that it's being used by almost every website in some form or another. Maybe it's not actually serving the HTTP traffic, in many cases it is, but it's certainly involved with the front-end tooling that, if you're writing your website in React or Angular or any front-end framework, you are almost certainly touching Node. In 2012, it was very clear that Node was the deal, but it was not clear to me that all websites would be using Node, that it would be having millions and millions of developers.
JavaScript as infrastructure, as a language, is deep inside the Web browser. The Web is just being used more and more, right? It is essentially the medium of human information at this point, and JavaScript is deeply tied into that. Over the last 12 years, JavaScript has just been going forward and forward and forward. It is not becoming a legacy system at all. Every day, it is more and more deeply embedded, and there's a lot of work going into improving JavaScript. Async/await is one of the improvements, but there's all sorts of work going on, and there are many dozens of people working full time on improving JavaScript. The syntax of the language is changing. We're moving from common JS modules to ES modules. There's extensions to JavaScript which, ultimately, are going to become part of the standard like TypeScript. There are new APIs being available.
Node was invented in a very primitive time relative to where we are right now. We had to invent a bunch of things. We had to invent a module system accessing the file system, opening sockets, making outbound HTTP requests. We did not have Fetch back then. Node, as a result has a very antiquated feel, and it is just not really keeping up. Node is under the Linux Foundation and managed by a nonprofit, and they are not super incentivized. One reason is just to modernize this very important piece of software that all these people are using.
I guess the other thought is that Node is, without getting into the specifics, I have a whole talk about this, 10 things I regret about Node, but I guess the other part of it is that Node is this big monolithic C++ project. We are starting to see that, server side, that JavaScript is useful outside of the browser, but that it's useful in different ways. Of course, you want to open up your terminal and you want to do some Node-like scripting, a replacement for Python or a replacement for a Bash, but there's also the Electron use case where people are using this to build desktop apps, and then there's also the serverless use case.
A lot of people are running Node in AWS Lambda. There's things like CloudFlare Workers. It's clear that JavaScript has more. It doesn't necessarily need to be tied to a Unix system and have file system access and expose Unix primitives like Node Pans. Deno is trying to explore this. It's written in Rust, but, more importantly, it's broken up into a lot of different components that can be combined into the opensource project that you see online as Deno, but can also be recombined into other bits of software, so a bit more modular in that respect.

Matt Arbesfeld:
If I'm, say, spinning up a new Web server or a new microservice and I want to use JavaScript to build it, would you say the main reasons to use Deno over Node is that I can use a more modern syntax, the security is better? If you had to say the top two reasons why, why do I choose Deno over Node?

Ryan Dahl:
Sure. Yeah. Developer experience should be fantastic. You don't need to think about tooling. You don't need to think about how you format your code or link your code or how to get TypeScript working with your code. All of this stuff just works, how it integrates with your editor, so developer experience is definitely number one. It should feel very simple and very nice. Security is a big aspect that we're trying to solve. JavaScript is a secure sandbox. Deno takes this quite seriously. By default, you really don't have access to the system. You have to give granular permissions and opt-in to, say, allowing file system access or allowing network access and, yeah, also improving performance of Node. There is still performance areas to be improved, and we are doing the best we can to improve that.

Matt Arbesfeld:
That makes sense. Then, in developer experience, right now, if I start a Node project, I can add a testing framework, I could add TypeScript or more modern, what are the biggest challenges you see in developer experience for Node? Is it that you have to pick and choose those different things or that they may not work together?

Ryan Dahl:
Yeah. There's just this plethora of tooling, and you have to be really familiar with the landscape in order to get started. The landscape is actually a moving target. Your testing framework might get out of sync with your linting framework. Do you use TSLint or do you use ESLint? What testing library do you use? How do you do your TypeScript integration? How do you bundle your code? All of these things is just... Most people don't care. They just want to get started on their microservice and not think about these things. Unfortunately, the situation with Node, just because it's trying to be so minimal or just is agnostic to these problems, it ends up creating quite a big headache for people who are trying to get started.

Matt Arbesfeld:
How do you think about the boundaries of that ecosystem? For some background, I was an engineer at Meteor that basically built, I'm sure you're familiar, but for the listeners, had a back-end, a front-end framework. They had a data layer, a persistence layer across it, a testing infrastructure. It's great on day one, but then, a year later, each component piece is not up-to-date, and developers want to start using and plugging and playing their own components into that ecosystem. I guess the question is how do you think about what is the responsibility of Deno versus what should be plugged in and part of an ecosystem?

Ryan Dahl:
Deno is really the runtime layer, and so it's operating at a lower level than Meteor. Meteor is built on top of Node, and so, inherently, you start... and I guess you have this problem with any Web framework that you're using as well. I mean maybe they have made a choice about testing, what testing framework to use, but maybe this meshes in not very nice ways with the other systems that you're using.
Deno and Node are very relatively low level. This is where the scripting language turns into native code. Because of that, we can be pretty opinionated here, and I think it's actually important for us to be opinionated. I see Deno in a similar fashion to what... very much inspired by how Go sees things. We're trying to solve the basic programming utility problems that you might run into. Testing, formatting, linting, these sort of things should be basically taken care of for you.

Matt Arbesfeld:
The thought is that those sort of things don't need to evolve as rapidly as something-

Ryan Dahl:
They don't need to involve. No.

Matt Arbesfeld:
Got it.

Ryan Dahl:
The one-testing framework is as good as another. It's essentially different naming conventions on top of this. You just need something basic and simple, and what everybody benefits from is just a choice rather than multiple ones.

Matt Arbesfeld:
Then back in August, we had Luca Casonato, I think a member of your team, created the Fresh, come on. How do you see that fitting in, and is that part of the core mission, or is it something... Yeah, how does Fresh and those extensions fit into the Deno mission?

Ryan Dahl:
Fresh is a Web framework that is built on top of Deno and a very modern one at that and, yeah, it does all sorts of nice things, but I think, as it relates to Deno, it just shows how nice it can be if you build 100% on top of Deno and buy into this ecosystem. When you get started with Fresh, it's like literally one minute. All of the install, all of the getting-started, it is just very, very quick. I think people who tried that out are just like, "Oh, wow, I had no idea that it could be like this. You mean I don't need to download 500 megabytes of dependencies to get started here?"

Matt Arbesfeld:
That makes a lot of sense. Maybe going back to Meteor, there was always this super magical day-one experience of you installing it and you have an app working, but then, when you start to have more and more complexity, there are things that come up that other frameworks solve and then found that there was just a lot of surface area to take on for a team to be building so many different layers of the stack. Does that concern you at all? Is it like you're biting off more than you can chew? How do you think about the trade-off between the core Deno versus things like Fresh and I think Deno Deploy and other services you're running?

Ryan Dahl:
I think we benefit. The axiom in my mind is that JavaScript is future-proof and that the world is going to continue to build on JavaScript. What we try to do is stick as close to the browser standards as we can and try to be in the flow of where JavaScript is going and avoid building infrastructure and stuff that is going to ultimately get supplanted by something in the browser or, say, invent syntax that is going to ultimately not future-proof for where browser JavaScript is going. Yeah, I mean Fresh is a framework on top of it, and we support it. We're going to build it. It's nice to use, but I think our core competencies as a project is really at the runtime layer. I mean, we are V8 experts, and we focus mostly on Web servers and the runtime itself.

Matt Arbesfeld:
That makes sense. If you're building things in, I guess, a way that will be aligned to the standards of the Web, then hopefully they don't need to keep evolving and a lot of churn in those parts of the product. Congrats, I saw you raise, I think, a $21-million Series A this year. I'm just curious how you think about the business side of Deno? I guess it seems like a different approach than Node, so I'm curious first to hear why this approach and then what are your plans for the business, and how do you see the business side evolving over the upcoming years?

Ryan Dahl:
One of the learnings of Node is that this doesn't need to be a nonprofit, and there are a lot of commercial use cases for this technology. Actually, I think it benefits the software if there is revenue for the software. I don't think that this JavaScript runtime is so distant, is so low level or distant from the business use cases that it can't generate revenue itself.
I mentioned earlier that Deno is built out of different Rust crates that can be recombined in other ways. Our business model is serverless JavaScript, and so we take some of the opensource software and combine it with a bunch of proprietary work that we're doing to build a serverless JavaScript system, an isolate cloud, we like to call it, called Deno Deploy. This is JavaScript at the edge. It's running in 34 data centers around the world. You get very fast latency to these functions, and it has the very nice property. I guess one way of describing it is that this is an alternative container in some ways. Instead, of building your project on top of Docker and using Linux syscalls as the fundamental abstraction on which all servers are built, rather, you get a browser like JavaScript Console and you can respond to events.
Essentially, the fundamental abstraction is a JavaScript function that takes a request and returns a response. That's an async function. All sorts of complexity can happen in between. You can call out to databases. You can make outbound HTTP requests. You can do all sorts of complexity, and I would claim that it is. That complexity is sufficiently generalizable to solve all sorts of use cases. Instead of this kind of Linux syscall abstraction, you basically have this JavaScript function abstraction, and that is actually a much higher level abstraction. In some ways, you can compare Docker as the fundamental Linux abstraction to an isolate cloud where, just a little bit of JavaScript, the browser dev tools console essentially is the fundamental abstraction.
This is a little bit fuzzy right now. It's not standardized, although we're working towards this with companies like CloudFlare and Vercel in a group called WinterCG. You can see that at wintercg.org. I think we're narrowing in on this and, over the course of the next year or so, I think this actually will be standardized. What we see is actually users don't care. They don't care about System D. They don't care about var directories. They don't care about /usrbin. They don't care about PATH. All of these Unix-isms aren't really addressing the business logic at hand that they're trying to solve when building their services. What they really want to do is just code something and remove as much complexity as possible.
JavaScript actually provides a very nice way of doing this, so I guess one way you can think of it is, like Chrome, you've got a bunch of tabs open. You've got a tab open to your bank. You've got a tab open to Google Docs. You've got a tab open to some nefarious website, and they're all running JavaScript. They're all running all these different programs and they're all untrusted, yet they can't see each other. Moreover, these tabs start up really fast. Think about how fast Figma starts up versus how long it took you to install Adobe Illustrator. It's just like the old software view versus what the Web software. When you open up Figma, you are literally installing that program, that editor, that vector graphics editor on your computer, and you're running it in an untrusted manner.
This is super similar to how serverless hosts work where we need to be... We're essentially doing this, not graphical, of course, but we're essentially a Web server that is spinning up these little isolates to a little untrusted isolate to respond requests from different domains. We think this is actually where Web server development is going for maybe not for a hundred percent of use cases, obviously, google.com is never going to be written in JavaScript, there are complex systems out there, but like an 80% use case. You just need to spin up a little server to respond to some request, to do some auth, to talk to a database and manage together some other APIs. We can handle those very, very cheaply. I mean, essentially, you hand us a couple of kilobytes of JavaScript, and we put that into a database table and we can host that. Essentially, we host that server indefinitely for free as long as it's not getting any traffic, and we can scale up the number of isolates serving that request as necessary to serve that.
We're working very hard on this. It's not super apparent. If you're following us, you'll just see all this stuff about the opensource project, but Deno Deploy is a very serious project. It is from scratch. It is not like a rebranded other system. In fact, you will find some services out there. For example, Netlify Edge Functions are actually Deno Deploy under the hood, or Supabase Edge Functions are actually Deno Deploy under the hood. This is turning out to be the, at least for the time being, is the white label infrastructure behind a lot of what you think of as Edge Functions.

Matt Arbesfeld:
Yeah, that's really cool. I can go from write a couple lines of code on my computer to a function running in the cloud in seconds with this. I guess, a question, and you mentioned Docker before, and I think this relates to one of the listener questions about competition where, let's say, Deno becomes the widespread way that JavaScript developers, program servers, how do you prevent it from becoming commoditized across all cloud providers where AWS would have a Deno runtime or, someone asked about Fastly or Netlify, how do you capture the value that you've created in the business and not have it be just dispersed through the existing cloud providers, or is that not that important in your mind?

Ryan Dahl:
It's a concern. The Deno Deploy is not just the Deno opensource project running in AWS Lambda or something. There is a massive proprietary gap between that. It is very, very non-trivial. You cannot recreate this. Of course, you can take the opensource project and you can go deploy it wherever you want. You can run it in an EC2 container or in an EC2 instance. You can go run it at fly.io, but this serverless aspect of this, this is what we're building in a proprietary fashion as a company. For that reason, I mean, we are trying to build a business.

Matt Arbesfeld:
If you could tell us more about the Deno team, how large is it? How many people are working on the core opensource versus the commercial offerings?

Ryan Dahl:
We are 16 people and growing quickly. Unlike every other company out there, we are not laying off. We are hiring very, very quickly. Right now, we are coming out of an opensource project and founded during the pandemic, and so distributed around the world, mostly based in US and Europe. We are a very asynchronous team and just used to collaborating on GitHub. I'd say we're roughly half-half on the opensource project and Deno Deploy.

Matt Arbesfeld:
Yeah. Got it. That makes sense, and then do you have any non-engineers on the team or, right now, it's all software developers?

Ryan Dahl:
Yeah. We've got Andy who's doing marketing. We've got a business guy doing operations stuff, but, yeah, mostly engineering. Both myself and my co-founder, Bert, are engineers, and we're trying to build a great engineering organization and build great software and really focusing on what we're good at, which is Web servers and system software and how that intersects with browser technologies.

Matt Arbesfeld:
Awesome. Well, I'm, for one, really excited about the vision and mission that you've laid out. Yeah, I really appreciate you coming on today to talk more about Deno. Maybe for the audience, where can we learn more, can we get started with Deno Deploy? Anything you'd like to promote?

Ryan Dahl:
Yeah. Deno.land is the opensource project. Deno.com is the serverless product. Try it out. You should also check out fresh.deno.dev. That's the Web framework that we have. I do not doubt that you will be shocked. I guess I should also mention you can use NPM modules with Deno. This is very much possible these days. It's something that we did not undertake originally, but, after much outcry from the community, I realized that it is very important for us to be able to pull in NPM modules, and this support is working really well. You should be able to. Maybe not every NPM module, there's a unfortunate tale of legacy modules out there that might not be compatible very old JavaScript code, but the majority, let's say, 80 to 90%, should be easily importable directly into Deno with type checking and everything working out of the box. Yeah, I encourage people to try it out.

Matt Arbesfeld:
Now, we can use our important packages like Express and left-pad as well?

Ryan Dahl:
Yeah, you should be able to import Express and compare it to Node. You'll see that it works faster with Deno.

Matt Arbesfeld:
Awesome. Well, it's really exciting. Again, thanks so much for coming on and sharing more. I'm excited to keep following you guys as you develop the JavaScript ecosystem.

Ryan Dahl:
Thanks, Matt.

Matt Arbesfeld:
Thanks, Ryan.