Changelog Interviews ā€“ Episode #443

Exploring Deno Land šŸ¦•

with Ryan Dahl

All Episodes

This week weā€™re joined by Ryan Dahl, Node.js creator, and now the creator of Deno - a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what heā€™s doing differently this time around. We also talk about The Deno Company and whatā€™s in store for Deno Deploy.

Featuring

Sponsors

InfluxDB IoT app training ā€“ Space is limited and itā€™s free to join Hands on guidance to build an IoT app with InfluxDB. Youā€™ll build a fully functional sample application called IoT Center and built on InfluxDB. The app is based on Node.js and React, uses Kafka to write measurements, and requires no DB installation with InfluxDB Cloud. Learn more and register for free at influxdata.com/changelog

Retool ā€“ Retool is a low-code platform built specifically for developers that makes it fast and easy to build internal tools. Instead of building internal tools from scratch, the worldā€™s best teams, from startups to Fortune 500s, are using Retool to power their internal apps. Learn more and try it for free at retool.com/changelog

CloudZero ā€“ For software-driven companies focused on growing margins, CloudZero is the only cloud cost intelligence platform that puts engineering in control by connecting technical decisions to business results. Visit cloudzero.com/changelog to get started.

Fastly ā€“ Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com.

Notes & Links

šŸ“ Edit Notes

Transcript

šŸ“ Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. šŸŽ§

Well, weā€™re here with Ryan Dahl, creator of Node, creator of Deno. Ryan, weā€™re big fans of you, and weā€™re so happy that youā€™re here on the show.

Hello. Glad to be here.

I think this is a first.

Youā€™ve never been on the Changelog before, even back in the day.

Nope. Never been.

Weā€™ve only talked about Node, not about the creator of Node.

Yeah, weā€™ve talked about Node, we havenā€™t talked with the creator of Node. What a shame. Here we are to fix that.

Well, ten years later, ishā€¦ Welcome.

Thank you. I think this is only the second podcast ever Iā€™ve done.

Oh, wow.

Is that right? Well, thank you for giving us part two of that.

Thatā€™s right, weā€™re honored. So youā€™re not here to talk about Node, youā€™re here to talk about Deno. Youā€™ve rearranged the letters; youā€™ve been hard at work for a couple of years nowā€¦ And I would like to go back to your JSConf EU talk, which has become famous now, in 2018, the ten things that you regret about Node.jsā€¦ Which turned out not being ten, it seems like. I donā€™t know if youā€™ve named it that or theyā€™ve named it that on the YouTube fileā€¦ Because it was like seven, and then you introduced Denoā€¦ And I was going through it, trying to findā€“

They named it that, yeah. It was not tenā€¦ [laughter]

Yeah, thatā€™s just the way they named it on YouTube. I donā€™t even think your slides said that.

They were like ā€œOne, two, three, four, five, six, sevenā€¦ Thatā€™s close enough to ten. Weā€™ll just call it ten.ā€

Yeah. Round numbers and lists apparently work on the internet, soā€¦ [unintelligible 00:03:04.01]

Yeah. If you go to the title ā€“ if you look at that talk and see the title slide, it has a completely different title. Itā€™s not ā€œTen things I regret about Node.ā€

Well good, because you had seven of themā€¦ And it seems like that was a talk that was put together somewhat last-minute, maybe because Deno wasnā€™t quite as far along as you hoped it would be, or what was the back-story on that? Because even in the beginning you said ā€œThis wasnā€™t my talk, but now it is my talk.ā€ Was that the thing, is Deno wasnā€™t quite ready to give more of a fleshed out version of it?

Yeah, I was working on a different project, and I had applied to give this talk on this other project. It was something very similar to TensorFlow.js. So it was TensorFlow binding to Node, so that you could train machine learning models in Nodeā€¦ Plus something thatā€™s like Pythonā€™s Jupyter Notebook, or in JavaScript thereā€™s this Observable companyā€¦

[03:58] ā€¦like a website where you could insert a bit of code and plot functions, and stuff. TensorFlow.js and Observable actually came out just before that talk, andā€¦ A month before that we decided ā€œActually, these projects are kind of dead-end. We should do something else.ā€ And JSConf insisted that I continued to give a talk on something else, so I put together this Deno demo.

Nice. So thereā€™s a bunch of stuff about Nodeā€¦ Anytime you make design decisions, in retrospect, itā€™s easy to look back, and itā€™s hard not to find flaws in things that we createā€¦ But we donā€™t always get a second shot at it, and Deno seems to be, to a certain degree, a second shot, or at least another round of something different, but similarā€¦ And Iā€™m just curious, of the seven or so things there that you listed - which, if you donā€™t remember, they are not sticking with promises, the security system (which I think you definitely are addressing with Deno), the build system, packaged JSON, Node modulesā€¦ Those are a few things, just high-level, that you mentioned, that were regrets. How many of those do you feel like youā€™ve alleviated with Deno? How many things did you fix?

I mean, all of those things, I think. Generally, Deno is an effort to move the server-side JavaScript platform forward in kind of radical steps. Node has a lot of users, of course, and they try very hard to maintain backwards-compatibility, which is laudable and great for all of the users of itā€¦ But that means that itā€™s very slow in taking on new changes. And I think the major change in JavaScript over the last couple of years - maybe two major changes are async/await syntax and the ES modules syntax; these are pretty radical changes to the language. And JavaScript is like this evolving system over time. The JavaScript of today is nothing like the JavaScript of 15 years agoā€¦ And yeah, it just felt like Node was not keeping pace with web browsers in terms of bringing these new features.

So now youā€™re a few years into Denoā€¦ Weā€™ve hit 1.0 last year. Lots going on, lots formalizingā€¦ Iā€™m wondering now, since youā€™ve gotten into the weeds for a couple of years, and you look back - have you made any mistakes so far? You had seven or so of Node that you regrettedā€¦ Any regrets with Deno yet?

Yeah, definitely. I mean, itā€™s hard to make software and not make mistakes, of courseā€¦

Totally.

This is going to be very controversial, but the TypeScript aspect of Deno - Deno has TypeScript compiled into it - is super-nice, very friendly, very nice to be able to just get up and started easily. But browsers do not support TypeScript, and Denoā€™s overarching philosophy is bringing server-side JavaScript closer to browser JavaScript. And in this aspect of supporting TypeScript out of the box, we are kind of overstepping our goals. So weā€™re supporting this extension to JavaScript.

I donā€™t know about you all, but I feel like TypeScript is eventually what JavaScript is going to be. I feel like it is kind of the next generation of JavaScript. Iā€™m very eager, and I think many people are, to go in that direction. But itā€™s a big complication to our system to support TypeScript, and I think weakens our argument that Deno is web-compatible.

So weā€™re certainly not removing it now, because Deno depends on itā€¦

Right. Go back and start over, would youā€“ yeah.

But yeah, I think it would have been easier for us to get started had we not supported that out of the box initially.

That being said, it seems like it was also a big draw and a big differentiator at first.

Absolutely.

[07:54] Let me just say that I was around when you announced Node, back in ā€˜09 or whenever it was; I remember it was right around the iPhone timeā€¦ And I remember the reaction to Node. Probably not as well as you do, because you were on the project, and I was just an innocent by-standerā€¦ And maybe you remember it differently, but to me it was like immediate ā€“ it was a hit. Everybody was excited. We had Mikeal Rogers on the show a little bit back and he was just reminiscing a little bit how nothing existed for Node. When Node came out and you announced it, there was no ecosystem, there was nothing, and then everyone just piled in. People saw fertile groundā€¦ And youā€™re looking at me a little weird, like maybe thatā€™s not how you remember it, butā€¦ It seemed like people came in droves to fill out that ecosystem. It just was immediately a hit. And I think it filled a real need. First of all, let me stop and say - did you have that same feeling, or am I seeing it through rose-colored glasses?

I think thatā€™s a fair characterization of what happened, yeah.

Yeah. Adam, you were aroundā€¦

Node was huge immediately ā€“ like, maybe not immediately, but people were very excited about Node, right?

Yeah. Well, I think there was a lot of things even like with Walmart Labs, and Black Fridayā€¦ This wasnā€™t back in the 2009 days particularly, but there was a lot of inertia around high-traffic websites, and scalability, and itā€™s enterprise-ready, so a lot of different enterprise teams were happy to move on to something more modernā€¦ Despite these seven flaws, as youā€™ve described in your talk. Because I think every step forward is a good step forward, even if itā€™s got some flaws, which - software has flaws every single time.

Yeah. So I guess my point is it filled a huge void, and it got a huge rush of enthusiasm and adoption because of thatā€¦ And then Deno comes out, and it doesnā€™t come out into that same moment in time. It comes out later, when you have a mature Node ecosystem, you have millions of packages on npm. You have people doing this full-time careers, and consultantsā€¦ I mean, there is a thriving Node ecosystem already. And so into that milieu, or that culture, Deno has to set itself apart, right? And TypeScript was one of the ways that it kind of did that to start. What were the other big ideas that Deno has that sets it apart from everything else?

The first important aspect is that itā€™s written in Rust instead of C++. Node is a very large C++ project, and Iā€™m not sure how you guys feel about this, but Iā€™m very convinced that I will never start another C++ project. Rust really solves the C++ problem, as it were. Thereā€™s many great things about Rust, but the thing that is most important to me is the ability to have a single build system; this cargo system of linking together different Rust crates. In C++ thereā€™s no one defined way of how to take different C++ libraries and smash them together. Chrome has this GN project, Node uses this Gyp project, thereā€™s CMakeā€¦ Thereā€™s a lot of different tooling for compiling together dependencies in C++. And this ends up being a huge, huge complexity in terms of bringing in external third-party code into a big project.

In Node days, we built a web server and youā€™d have to parse HTTP, and itā€™s such a difficult problem that we ended up writing our own HTTP parser for this. Itā€™s so difficult to bring in external code that you end up often having to just write the stuff over again, because itā€™s so difficult to link. And this is very different in Rust. If I need a YAML parser, if I need an HTTP server, any sort of third-party stuff, I would do what people are used to doing in JavaScript, or Ruby, or Python - you can just kind of include dependencies and have this all compile together really nicely. And thatā€™s an important aspect for a platform like Deno or Node, because we provide all of these APIs to do various things. You wanna open a WebSocket, you wanna have an HTTP/2 web server - all these various systems that it talks to need implementationsā€¦ And itā€™s very nice that weā€™re able to just link in third-party implementations of all these various systems pretty easily. So from a maintainerā€™s perspective, rewriting it in Rust is a really killer feature that kind of allows us to iterate much quicker.

[12:31] Yeah, maybe kind of a feature that end users donā€™t appreciate as well as the authors or maintainers, but they will appreciate over time as you are allowed to continue at a certain pace that the C++ ecosystem didnā€™t allow with Node. Or maybe at a certain point Deno will also get so many lines of code and so much stuff in it that ā€“ I mean, it will slow down. Any project thatā€™s mature moves slower than when itā€™s young. But maybe itā€™ll keep a pace that keeps your users happy.

Sure. Just talking about other aspects of Deno, internally, that are important, is the binding interface; kind of the boundary between JavaScript and the native language, in this case Rust, in Nodeā€™s case in C++. Node was fairly ad-hoc at adding bindings; we just kind of added them all over the place. There was no set system for calling from JavaScript into C++ and vice-versaā€¦ And in Deno thereā€™s a system for this. We call them ops. This kind of organizes the various bindings that you have to the system facilities really nicelyā€¦ And in particular, organizes all of the async calls that you might make. So ops in our system are either a synchronous function, like a function you call in to Rust and it returns a value immediately, or itā€™s an async function which returns a promise that eventually resolves to a value.

One of the really nice aspects in Deno is that everything is organized as promises. Itā€™s kind of promises all the way. Thereā€™s not kind of random callbacks that happen throughout the system.

This was actually a pretty big design mistake. I forget if I did discuss this, or how much I discussed this in the talk, but WebSockets are on my mind right now, because weā€™re doing a lot with WebSockets. WebSockets have this on-message callback, right?

Right.

And one of the problems with this is that you canā€™t really stop the system from giving you new messages. You can just get flooded with these callbacks. Thereā€™s no way to throttle this incoming stuff. So because of the inability to stop these new messages coming in through this WebSocket, you can get into really bad situations where youā€™re always handling the newest WebSocket message because youā€™re getting flooded from this one socket, say. And this is not specific to WebSockets; this happens in different parts of the system.

Thatā€™s quite badā€¦ This actually causes pretty ā€“ this manifests itself in bad tail latency situations, where usually the system is fine, except under pressure, when suddenly one part of the system is getting flooded with these callbacks, so you start getting really bad latencies.

WebSockets in particular - thereā€™s a new STDOUT called WebSocketStream, which addresses this, allowing you to create some back-pressure, that is to not accept the newest message if youā€™re not ready to handle it. And in general, this async/await paradigm, syntax, and the usage of promises everywhere generally kind of solves this problemā€¦ Because as long as youā€™re always giving these promises and youā€™re awaiting them, youā€™re kind of stopped at a certain line. Youā€™re not kind of unboundedly accepting new callbacks from the system.

Anyway, thatā€™s all to say that Deno is promises all the way down, and so kind of from the fundamental layer weā€™ve tried to deal with this back-pressure problem.

[16:02] Another big differentiator is the package management story, right?

Thatā€™s right.

Tell us about how Deno sees the world of packages.

Yeah, I would bring this back to ā€“ in general, Deno is trying to use web APIs. We try not to introduce invented APIs, like I had to do in 2009 when I started Node; there were just a lot of APIs that were ā€“ you know, there was no module system, so we invented this require syntax to link to JavaScript files together.

ES modules, ECMAScript modules is a standard now. This is part of the new JavaScript standard, which defines import and export. Iā€™m sure you guys are familiar with itā€¦ And this works in web browsers these days. These imports and exports and ways to link different files together. And the way that this works on the web is you can actually do import a URL; not just a relative URL, but an absolute URL that exists on a different server. So you can actually pull in code ā€“ you know, if you think of like an HTML page and script tags, you can script source, have a link to https://jquery.org/jquery-v1.2.js

Thatā€™s how we used to do it back in the day. Weā€™d just have our script sources, and youā€™d just have your list of sources. Everything was so simple.

Which is quite nice, right? Itā€™s really nice to have an HTML file and just drop in a link to the jQuery CDN and suddenly have that available without having to do a whole installation procedure, right?

Anyway, Deno is built around the idea that we think this is sufficient, actually, to link remote code together. I mean, the problem is really ā€“ Iā€™ve got code that Iā€™m developing locally, and I really want to include some third-party library. How do I do that? In the Node system you would download that third-party code into a Node modules folder, and this require system knows how to look into this Node modules folder. So when you do require express, it looks in the local directory Node modules, and then looks for the Express folder, and it has some special knowledge about looking up package.json, and looking up index.jsā€¦ It has this algorithm of how to find what module youā€™re referring to there. And weā€™ve basically done away with all of that. Weā€™ve just said ā€œIf youā€™ve got code that youā€™re working on locally, then you store that in your local folder, and thatā€™s yours to deal with.ā€ And if you wanna link to some third-party code, you can of course download it into a vendor folder if you wanted to, and ./relative-include/relative import thatā€¦ But you can also just import the remote URL via HTTP.

Our module system is really the web browserā€™s module system, which is exactly HTTP. So unlike npm, which has a specific protocol for distributing packages, you have to ask the npm server what the latest package is, get the link to the tarball, download the tarballā€¦ We donā€™t define a protocol like that. We just have HTTP, and you can download JavaScript or TypeScript over HTTP.

What are the advantages of that then? If pulling a module for npm, for example, the stability of being able to make those ā€“ npm install, for example, and being able to sit there and wait, like some people might, what are the advantages of that system over this older one? Obviously, itā€™s modern in terms of the way the web browser is working, but whatā€™s the specific dev experience advantages there?

[20:02] I think it has the effect of feeling immediate, andā€¦ Thereā€™s nothing to install ahead of time, because the Deno system itself actually takes care of downloading that. So I would say the other DX effect is that you can have scripts that are single files. In Node, you generally at minimum need to have a package.json and your JavaScript file. Your package.json needs to define where youā€™re linking, and your JavaScript file has some source code in it. In Deno you can say where youā€™re linking on line one, and the rest of the script can be your code. So you can actually define a complete program, both where to get your third-party code, and your own code, all in one file, run it without creating a directory, andā€¦ I guess what Iā€™m trying to say is thereā€™s less boilerplate to deal with.

Itā€™s minimal.

Yeah, itā€™s simple.

Itā€™s very minimal.

You can have file tabbing fatigue, or swapping from different filesā€¦ I love that a lot ā€“ in a whole different land, with Tailwind, for example, you can do a lot in the same file or in the same HTML file; youā€™re not jumping back from CSS to HTML. So similar to how that world might work, youā€™re not jumping back and forth. You can stay in the same file, have the sort of immediate/instant gratification of just moving forward, and not have to jump back and forth between different ways to define what your application is needing to inherit from, or to import etc.

When you have a large application, if you have hundreds of files, having one extra package.json file is not a big deal. Itā€™s no big deal to have a ā€“ you know, if you have hundreds of modules and you have one extra one, itā€™s not a big deal. So I think in the tail end of larger projects, it probably doesnā€™t feel that different. But when you get down to the very small scripts, the one-off scripts, Deno scales down to a much smaller installation, I would say. Much less boilerplate.

When you do npm init, itā€™s gonna ask you for (I donā€™t know) the license of your project, the name of your projectā€¦ All of that stuff is ā€“ letā€™s say youā€™re trying to write a script thatā€™s going to rename a bunch of files in a folder. Who cares? I donā€™t care what the license is. Why am I spending any time at all thinking about that problem? That is boilerplate.

Yeah. What about the potentially hidden advantage in it? Iā€™m assuming this - the internet essentially is your package manager. You can link to a raw file on GitHub, you can link to some random site, adamstacoviak.com, or changelog.com and just inherit from that. Is that how Deno works? You can just pull in from any URL? Or as youā€™d mentioned, even a relative from somewhere locally?

Yeah, thatā€™s right. You can pull in files from any server. And the nice side effect of this is that that Node ecosystem and essentially all other programming languages are dependent on a specific server to distribute third-party packages, whether thatā€™s crates.io, whether thatā€™s golang.org, or npmjs.com. If that server goes down, everything breaks. We are heavily dependent on that. But contrast that with ā€“ this is just not very webby; this is not how web browsers work. It would be a bad day if Google went down, but hopefully web browsers continue to operate. Your website isnā€™t necessarily dependent on any one specific server existingā€¦ And thatā€™s nice. Thatā€™s a distributed system. And because of this aspect that you can download code from any URL, Deno is not dependent on our website, deno.land, nor is it dependent on any other website. You can use unpackage.org for pulling in your third-party dependencies. Or you can use GitHub directly, which might be nice, since thatā€™s where the code is actually stored.

[23:56] Right. Then if GitHub goes down, weā€™re screwed again. But weā€™re already screwed, soā€¦ Great website, by the way. I love the dinosaur brand, I love the name. Deno.land is such a cool domain. I just wanted to give you props for that really quick.

What about versioning? I mean, if Iā€™m a library author, are there idioms around that? Do I just have a new file with like the version in my file name? How do we deal with things like ā€œLodash 3.7.1 is out. How do I go get it?ā€

Ultimately, a version is a string of characters, and so is a URLā€¦ So you can have a version in a URL to specify the version. Think back to the jQuery CDN example - you have perfect ability to link to any version of jQuery.

Good answer. What about existing npm ā€“ are all the existing npm packages then supported if I can find the exact URL of the source code? Will it just work? Or are they using some things that might not be ESM-compatible, and stuff like that.

Yeah, so if itā€™s not using ESM, then itā€™s going to be probably problematic. It may be problematic even if it is using ESM. Unfortunately, weā€™re kind of in a state right now in JavaScript where thereā€™s a lot of fragmentation between TypeScript, common JS, Deno, Nodeā€¦ I hate to contribute to that, but I also am (I feel like) fighting the good fight, trying to make things simpler. All npm packages are available on, for example, unpackage.org, or Skypackā€¦?

Skypack.

So you should be able to access those files through HTTP. And if theyā€™re ESM, then youā€™re close to it working. I think the problematic thing is if they use Node APIs. Node for example has requirefs. You can requirefs and open a file. Deno has alternative APIs for that. We do not have a top-level fs module. We have a compatibility layer for that. Thatā€™s in our standard library. By the way, Deno has a standard library. And you can find that at deno.land/std/node. Using that compatibility layer, you get pretty close, although thereā€™s definitely a lot of modules where itā€™s gonna require some workā€¦ But you can get pretty close to importing a lot of modules. Thereā€™s a long tail end of things that are incompatible though.

So Ryan, on your website, deno.land (awesome website) it says ā€œA secure runtime for JavaScript and TypeScriptā€, and of course, ā€œSecure by defaultā€ is the top-level bullet of Deno features. We havenā€™t talked about security yet. Do you wanna give us the skinny?

[27:52] Yeah, so obviously if youā€™re pulling in random packages over HTTP, you should be worried if youā€™re pulling in code, because maybe youā€™ve audited this code, but probably not. That code probably depends on some other code. And those can end up pulling in many dependencies.

Thatā€™s kind of like those installers where theyā€™re like ā€œCurl this URL, pipe it into Bashā€, and then a lot of people will show up in the comments like ā€œPlease donā€™t do that, because Bash is gonna execute arbitrary code thatā€™s in that URL.ā€ Anyways, I cut you off, but I just was reminded of that, where itā€™s like, ā€œYeah, but as long as itā€™s safeā€¦ Audit it and youā€™ll be happy. But if you donā€™t audit it, you probably shouldnā€™t be piping into Bash.ā€

Unfortunately, itā€™s really hard to audit all of your code these days. I mean, we depend on society-level infrastructure, right? Thereā€™s no possible way ā€“ if you plan to be a productive developer, to go out and actually read through all of the dependencies and the transitive dependencies of your dependencies.

By the way, youā€™re talking about curling Bash scripts - when you npm install something, arbitrary code from the internet is running on your computer, without any security sandboxing. And beware, when you are npm installing something, you are completely and utterly open to having your computer taken over. It takes one bad actor in the ecosystem to make that happen.

And weā€™ve seen that.

We have seen that, yes. This is mitigated in web browsers. Web browsers do not allow you to access your local file system. They do not allow you to do a lot of stuff, right? Web browsers are a secure sandbox. And this is a really nice property of V8 and the JavaScript language, is that it does not necessarily have access to the system.

We, Deno and Node, give access to the system so that you can do things like writing a little script to rename a bunch of files. The purpose of a server-side JavaScript system is to interact with the system. But in Node, we did this without any constraints. We just opened all sorts of holes, so you can access the file system, you can access the network, you can do all sorts of stuff. Thereā€™s no gating on those privileges. In Deno weā€™re much more aware of opening holes into the systemā€¦ And I mentioned earlier these ops and how Deno has a very centralized system for calling from JavaScript into Rust. By having this centralized system, we also have centralized gating for security.

So by default, when you run a Deno program, whether thatā€™s a local program on your computer or a remote program via an HTTP URL, itā€™s given no access to the system. All it can do is compute; it cannot access your file system, it cannot open outbound connectionsā€¦ It canā€™t do anything mischievous. It can calculate some numbers, it can print to STDOUT, but thatā€™s about it (which sometimes is all you want) to allow programs to ā€“ in web browsers they have this system for opting in to more privileges. For example websites can access your webcam. But not just any website can access your webcam; it needs to elevate its privileges. So you get this little pop-up that says ā€œDo you wanna allow website x to access your webcam?ā€ Deno is very similar. When you try to access the file system, itā€™s going to fail if you donā€™t have the privileges. And you can give it those privileges.

And you give it those privileges via command line flags, right?

Via command line flags. You can do allow all if you want a Node modeā€¦ [laughter] Thereā€™s no privileges, thereā€™s no gating. We have allow write, to write to the filesystem. We have allow run, to run subprocesses. We have allow read to read the filesystem. We have allow plugin to load Rust plugins, which we canā€™t assure are not going to do something nasty. We have allow net for making outbound network connections, and allow env for environmental variables, which may often contain secrets.

Is that something you can put in the file itself, or does it have to be a flag to the runtime?

[32:13] It has to be a flag. We are considering having a configuration file. We are really conservative about adopting new file formats. I was just talking about how we try to keep things as boilerplate-free as possible. So we donā€™t want to force people to write a configuration file. We donā€™t want the overhead of configuring your system before you ever get started.

So for now they are command line flagsā€¦ And theyā€™re pretty obvious and annoying, and thatā€™s kind of purposeful, because these are security things. They should be obvious and annoying. You should be very clear that you are allowing this system to run arbitrary sub-processes. Yeah, so via command line flags is how you enable them.

How often are those flags being used by general applications you see being built?

All the time.

All the time. I mean, it depends on what youā€™re doing. Letā€™s say youā€™re writing a program like ESLint - this ESLint-like program doesnā€™t need to make outbound network connections. It doesnā€™t need to write to the disk. All it needs to do is read from the disk. So you would only enable the allow read in that case.

Yeah, so I was telling you during the break that I was writing this little script with Deno the other day, and basically it went out to the Slack API, got some data from there about members of our community, and then looped over ā€“ I was trying to pick a random winner for a giveaway, from a certain channel from one of our Slack channelsā€¦ And then it picked a random three or something, just printed them out. A very simple use case. And I had to use allow net, obviously, because Iā€™m hitting the Slack API; and then I also had to use allow env, because ā€“ I could have just hardcoded the token into the script, but I just used it as an environment variable. And I can say from a person whoā€™s just trying to get stuff done, it is kind of annoying. Youā€™re just like ā€œArrghhā€¦ā€ You know? I didnā€™t know about -all. I would have just used that. But now I know. Iā€™ll just use that all the time, babyā€¦

Node mode.

Yeah, Node mode, please.

I mean, if youā€™re the one whoā€™s writing itā€¦

Totally.

ā€¦then youā€™re pretty sure that itā€™s going to be okay.

Yeah, exactly.

The problem comes when youā€™re running somebody elseā€™s code.

Yeah, like I said, this was an inconvenience, but itā€™s like a very explicitly, well-considered inconvenience thatā€™s like ā€œYes, weā€™re doing this because the trade-off is completely worth it.ā€

This is a shift left kind of moment, where youā€™re taking typically maybe security concerns that you might rather just say ā€œdeno runā€ or whatever the command is to run a Deno application. But youā€™re kind of shifting left, saying ā€œThese are security concerns that Deno resolves and has control overā€ and putting them more front and center. Rather than ā€“ as you said, in a configuration file, which is less minimal, requires potentially a different file format, other concernsā€¦ Like, this is a shift left kind of moment. Would you say that?

Sure. I havenā€™t heard the term shift left before.

Shift left is whenever you take the security concerns, which if you take a product lifecycle, left to right, left being dev, iteration, right going to productionā€¦

I see.

A shift left is you sometimes think about security further to the right, once it shipped, potentially. Shift left is a term used by security minds to take that security concern and shift it more left into dev land.

Yeah, I should mention that there is a new feature ā€“prompt. Deno run ā€“prompt. So if you donā€™t wanna allow all ā€“ the current behavior is if you hit one of these ops thatā€™s trying to access the file system and you donā€™t have the correct allow flags, you get an exception, the process drops out, errors out. Thereā€™s a new feature that has an interactive prompt that will be like ā€œHey, Iā€™m trying to read this environmental variable. Do you want to allow this, yes or no?ā€ So you can kind of yes or no through the exact accesses that the system is doing. And we think that weā€™re going to enable this by default actually, and not require this ā€“prompt flag. So this is kind of going more in the direction of ā€“ as always, in the direction of web browsers. We like this programming model where you opt into additional privileges.

[36:24] I like that. It sounds like a good compromise. Kind of shifting a little bit further right, but youā€™re following the web browserā€™s lead, where itā€™s like ā€œAre you sure you want to give this person access to your webcam?ā€ And if you say yes, then itā€™s on you.

So security front and center. Weā€™ve talked about packages and how that all stuff works, importing other peopleā€™s code, weā€™ve talked about TypeScriptā€¦ What are some other aspects of Deno that are cool and exciting? Thereā€™s some tooling things, thereā€™s a formatter, thereā€™s some of these kind of developer experience things that help you stay productive, right?

Yeah, so thereā€™s a bunch of sub-commands in Deno, deno run being the most obvious one to run a script. But weā€™re kind of taking this Go approach where weā€™re just going to build in all the tooling for you, so that you donā€™t need to bring in all this other third-party tooling.

For example, we have a code formatter built into the system, so you can deno format your code. We have a linter built into the system. You can deno lint. We have a test runner - deno test - to run tests. We actually have all sorts of stuff in there. We have test coverage, we have a documentation generator, and we have a dependency analyzer - deno info - which will show you your dependency tree.

Generally, Deno knows all about your source code, it knows all about your dependencies and what itā€™s doingā€¦ And why not? Weā€™re distributing this executable; all of this stuff is written in Rust, and so it compiles down really tightlyā€¦

So our formatter that you run is not Prettier. Itā€™s something called Deprint, and itā€™s written in Rust, and itā€™s like 100 times faster. And our linter is not ESLint, itā€™s deno lint, and deno lint is written in Rust and is very fast.

We have deno lsp, which allows VS Code to talk to Deno, and get tab completion, really nice editor interactionā€¦ So Deno can basically tell your editor documentation, all sorts of interesting interactions that Deno can help provide VS Code.

Thatā€™s all really cool stuff. How much of that stuff is informed or inspired by other languages? Are you a language aficionado? Do you watch what the Go folks are doing, what the Elixir folks are doing, what the Haskell folksā€¦? Are you watching these different ecosystems and saying ā€œOh, thereā€™s a good idea.ā€ Because I think go fmt kind of made this formatter a popular thing to do at the language level, not like a third-party levelā€¦ And it seems like youā€™re pulling in lots of good ideas.

Absolutely. This was heavily inspired by Go. Not just in these various toolings, but all throughout the system. Itā€™s important to continually improve and take good ideas where you can get them.

So the standard library is pretty fleshed out as well. Iā€™m just wondering, where are the holes? Because Deno still ā€“ itā€™s at 1.0, but itā€™s newer; itā€™s not as mature. Is the ecosystem still waiting for large holes to be filled? I know you recently shipped HTTP/2, web server back-endsā€¦ So things that you expect to be there are kind of there, but at a certain point do you get to where youā€™re looking for a package and itā€™s only in Node, itā€™s not in Deno? Is that still the situation?

Yes, that is still the situation. You know, things take timeā€¦ I expect this will be worked out over time. I remember back in 2010 people would be like ā€œHow do I connect to MySQL with Node?ā€ and I would turn red-facedā€¦

[laughs] You write a driver.

ā€¦and apologise that I did not have a MySQL library yetā€¦ And theyā€™re like ā€œBut how is that going to happen?ā€ and I said ā€œI donā€™t know how thatā€™s going to happen. I just hope that that is solved at some point.ā€ And itā€™s embarrassing to even think that that was a concern, because that was totally not a concern. All those problems got worked out essentially without my interaction.

[40:20] You know, Deno and Node are very similar systems. Theyā€™re both built on V8, theyā€™re both JavaScriptā€¦ Theyā€™re pretty similar. The differences are relatively superficial. I mentioned this Deno.land/standardlibrary, the Node compatibility layerā€¦ This is a work in progress. If you go check it out, thereā€™s something ā€“ I think weā€™re maybe at 40% compatibility now. So weā€™re still filling these things out, and I think over time it will be less and less of a problem to take existing code and run it in Deno.

But thereā€™s still a lot of work to doā€¦ You mentioned this HTTP/2 web server - up until recently, Deno was using a web server written in TypeScript that was a loose port of Goā€™s web server. Itā€™s built on top of TCP sockets and TLS sockets. It was a nice HTTP 1.1 server, but had some problems in that it didnā€™t support HTTP/2. And because we just made this port ourselves and are not particularly interested in writing web servers, weā€™re kind of dead-ended with that codebase. We were forced to then write an HTTP/2 web serverā€¦ HTTP/2 being a much more complicated protocol than HTTP 1.1.

What weā€™d really like to do - Iā€™ve mentioned this earlier, about linking in native code libraries using Rustā€¦ Rust obviously has a web server already implemented. In fact, Deno already has that web server in its binary somewhere, deep inside of it. What we really wanna do is just allow people to call from JavaScript into this hyper web server in Rust and start up a nice, fast HTTP/2 web server. This work is still unstable. ITā€™s shipped in Deno 1.9, so people can use it if they use the ā€“unstable flagā€¦ But yeah, now weā€™re working on this native web server, which - I think serving websites is quite important to server-side JavaScript tasksā€¦ And itā€™s quite fast. It has very good latency, very good throughput. We have some preliminary analysis on its performance on the 1.9 release notes. We hope to stabilize this in the next couple of months, and people will have a very fast web server available right out of the box.

Ryan, back in March 29th you announced the Deno company, and obviously, youā€™ve got a great new start to what you began with Node. A lot of new beginnings here, a lot of wrongs made rightā€¦ And to put behind that a company. So why are you on this path? I suppose more than ten years - Node 2009, now itā€™s ā€˜21ā€¦ Whatā€™s the path? Whatā€™s Deno company, what are you doing?

Programming languages are important. The world is built on software, and of the programming languages, dynamic programming languages are, I would say, what most people are interacting with day-to-day. But most business needs are best expressed in Ruby on Rails, or Node/JavaScript, or Python, because to be honest, most problems are not compute-bound, they are engineering-bound. All of our time spent as programmers is what weā€™re trying to optimize forā€¦ And scripting languages, dynamic programming languages are the best way to get going fast.

I work on this problem because I think itā€™s very empowering to be able to take a system like Node or Deno or Perl or Ruby and just start programming really fast. I got started with Perl myself, and I donā€™t know if you guys feel this way, but thereā€™s that feeling of power when you first really grok the language and you get over the ā€“ you have to climb some mountains before you feel powerful in Perlā€¦ But once you get there, suddenly the world is your oyster and you can just solve all sorts of problems very quickly.

Yeah, I just donā€™t think thereā€™s enough effort being ā€“ obviously, Iā€™m talking a lot about Rust, Goā€¦ These programming languages are very important, but theyā€™re targeted at different use cases. I love Rust. I would never start a new C++ project, as I said, but Iā€™m not going to use that to rename a bunch of files on my folder. Iā€™m just going to smash my keyboard for a while and write some JavaScript.

Of the dynamic programming languages, JavaScript is the biggest; V8 is the fastest VM in JavaScript. Itā€™s the fastest dynamic language VM, periodā€¦ And JavaScript has this industrial standardization process with it. Itā€™s tied to the web, so if you believe that the web is going to be here in a couple of years, JavaScript will certainly be here in a couple of years. It is as tied to the web as HTML is, so itā€™s certainly not going anywhere.

So if youā€™re going to choose one of these languages to invest in and build on, I think itā€™s pretty clear that JavaScript is the language ultimately that weā€™re going to be using.

I think once you play around with this stuff a bit, and you learn Python, and you learn Ruby, and you learn JavaScript and Perl, you get the feeling that theyā€™re pretty much the same thing. Thereā€™s different syntax here, thereā€™s different ways to do different things, but the are very similar systems, essentially with different function names, different syntaxā€¦ And yeah, I think those surface-level features are fairly unimportant. I think JavaScript is really the one that we should be using to push forward the needs of the world to create fast software, or create software quickly, I should say.

[48:22] Yeah. Bet on JavaScript, basically.

Bet on JavaScript.

One of the things you say in your manual too, and you kind of alluded to this a little bit, was in the philosophy section of the introduction you say ā€œAmong other things, Deno is a great replacement for utility scripts that may have been historically written in Bash or Python.ā€ I didnā€™t really consider this, but thatā€™s pretty interesting too, because most often Iā€™ll reach for things like Bash to do different things in a file system ā€“ not too often Python, because Iā€™m not a Pythonista, but Iā€™ve definitely used Bash before, and Iā€™ve used things in Ruby like Make, and other things like that.

Rakeā€¦

Rake. Isnā€™t Make and Rake fairly the same? Isnā€™t Rake built on Make?

Well, Rake is based off of Make, but Make is not Ruby.

You just misspoke; Rake was what you meant.

My bad. Rake/Make then. Thank you for correcting me.

You know, being able to do that kind of thing, where youā€™re betting on JavaScript ā€“ not too often will you do those kinds of things, scripts like that with JavaScript. Like before, its lack of ability to have secure access to the runtime, or the system and the file system and whatnot.

Yeah, I mean - Bash is another dynamic language, one that starts a sub-process for every statement in your programā€¦ But generally, you would use Bash because itā€™s widely available on all of the different systems that youā€™re running on. Itā€™s very portable. Itā€™s not a great programming ā€“ I donā€™t think anybody loves Bash as a programming language.

Itā€™s pretty hard, yeah.

Yeah.

I regularly access documentation to confirm my syntax is correctā€¦ Or just cargo cult, because thatā€™s sometimes easier. Copy and paste. Thereā€™s lots of it out there too, so it makes it easy.

Yeah.

Thereā€™s probably a Subreddit somewhere where thereā€™s people who just love Bash, and itā€™s like their thingā€¦ But theyā€™re a rare bunch, for sure. Now, like you said, if you take all of the scripting languages together - I agree with you; Iā€™ve done Python, Perl, Ruby, JavaScriptā€¦ The more you learn, the more you start to realize they have their own idiosyncrasies, they have their own view of the worldā€¦ But theyā€™re all kind of in the same ilk. And I would tend to agree, even though Ruby is my first love, that JavaScript is the one to bet on, because itā€™s already ubiquitous. Itā€™s in the browser, itā€™s used pervasively server-side now thanks to Node, and it is definitely not going anywhere. So youā€™ve picked that as your place to build and to create, and you wanna do this into the future; this is an ambitious, big project, so youā€™ve started a company around itā€¦ Which is different than what you did with Node. That was a long time ago, but why donā€™t you tell a little bit of what went down the first time when you create Node, what happened with you ā€“ I know you had a full-time job etc. Things were different with your life. Thereā€™s a company now, this is different than Nodeā€¦ Can you just compare and contrast the two situations for us?

Yeah, I was much younger, obviously, when I started Node. Shortly after starting it I took a job at Joyent, where they said ā€œCome work for us. You can continue working on this projectā€, which seemed like a great deal. I moved from Germany to San Francisco, and continued building Nodeā€¦ And kind of throughout 2009, 2010, first part of 2012.

When it became more and more clear that Node was really a thing, Joyent sat down and made a business deal with me, and I ended up selling Node to Joyent, whatever that means when itā€™s an MIT-licensed open source projectā€¦ But I gave them control of the project and gave them the website and whatnot. That worked out very well for myself personally. Iā€™m not sure how well it worked out for Joyent, actuallyā€¦ For myself it was great. Iā€™ve seen some comments online that kind of paint a different picture of the situation, that I was exploited by Joyent, or somethingā€¦

[52:14] You didnā€™t feel that at all?

Not at all the case.

Well, thatā€™s good. So after you left Joyent, what did you do next? I know you were doing research and development at some point, but did you have a job after that, or did you take some time off?

I took some time off, I worked on some other projects that were unsuccessfulā€¦ I worked for a while at Google, doing machine learning stuffā€¦ It was 2018 that my collaborator in Node, Bert Belder, who founded the company StrongLoop, was ā€“ so Bertā€™s journey is also interesting. He was an early contributor to Node, and did one of the most important refactors in Node early on. Early on, Node only worked on Mac and Linux, and we wanted to port it to Windows. Node is doing all this asynchronous IO, so it uses epoll and kqueue, these non-blocking socketsā€¦ These are fairly intricate, not well understood operating system APIs that differ from operating system to operating systemā€¦ And in particular on Windows itā€™s completely different. Their non-blocking IO system is called IO Completion Ports, and we wanted to do a very proper port to Windows.

We wanted to use IO Completion Ports, so that Node would work as a native, proper program on Windows. This was a massive undertaking, and Bert led this effort. We collaborated with Microsoft on it. It took probably a year, but at the end of the day, Node works on Windows. In fact, Node is very well supported on Windows, and itā€™s very fast. I donā€™t think people run servers on Windows too much, so maybe it doesnā€™t matter how fast it is on windowsā€¦ That was a very successful, massive undertaking.

As I said, Bert went on to fund this company StrongLoop that did Nody sort of things, built some products on top of Node. They sold that to IBM I think in 2015 or so. Around 2018 I left Google, and Bert was wanting to leave StrongLoop (or IBM), and we teamed up and started working on projects. I already mentioned this TensorFlow in Node project that we were originally working onā€¦ But we just had the idea to kind of poke around for a while and see what we could do.

So after you conceived the idea of Deno and maybe you had a prototype, or you had maybe even announced the project - was the Deno company right there in your guysā€™ minds, kind of like ā€œOkay, hereā€™s a path forward from thenā€, or is that a newer conception that you came up with later?

So early on in Node ā€“ as I mentioned, I was young and naive about how software is developedā€¦ I was very much of the idea that ā€œOh, you just throw some code out there on the internet, you collaborate with peopleā€¦ This is how software gets built.ā€ But Node grew bigger and bigger and bigger, and thereā€™s more and more people involved, and it becomes clear at some point that organization really matters, it matters very much to have full-time professional engineers working on it, and people can contribute code on a one-off basis. But if you really want to get things done, like port Node to Windows and use IO Completion Ports, you need full-time engineers; these people need to get paid, and they need to be able to focus on a problem for a long period of time.

[55:55] So you realize that at a certain scale, software becomes a lot more about managing budget and trying to manage an organization and kind of the meta problems around getting funding for people. So itā€™s always been clear to me that if weā€™re going to go down this route and build this programming system that is going to be very much like Node, that if itā€™s going to ever scale, it needs to have some funding model. Thereā€™s no way that this can work where people are just going to randomly work on stuff on kind of a one-off basis for free. There needs to be some way of paying people to work on the problem.

And Node is not a piece of software that is unused, that is not attached to revenue streams. Thereā€™s all sorts of companies using this. If I could have one cent for every Node installation - oh, how great it would be. This is open source software, of course, and itā€™s very liberally open sourceā€¦ And I believe in that, and I think thatā€™s important for a programming system like thisā€¦ But yeah, we see that these systems have commercial applications to them, and these can provide connections to reality for the software itself that is making sure that weā€™re actually solving a useful problemā€¦ But also provide funding to develop the software.

I guess weā€™ve known very early that ā€“ we did not know if this project would go forward or fail, but we always knew that if itā€™s going to grow, that it would need to turn into a company, eventually.

At what point did the company become the company then? I know you had the announcement in Marchā€¦ Late March you mentioned a sizeable round of seed capitalā€¦ You can name names if you want to, but at what point ā€“ was that when the company begain, and the team of full-time expert engineers working to improve Deno happened? Was it a chicken and egg ā€“ which came first?

No, Bert and I first of all worked on this ourselves for a year. So that was kind of our first investment, and I think we hired our first engineer in 2019 or soā€¦ And yeah, weā€™ve grown from there. I think weā€™re eight people now.

So if thereā€™s a video game called ā€œBuild an open source businessā€, and if the first step is ā€œPick your licenseā€, you guys chose MIT. That would be like setting that video game on hard mode, wouldnā€™t it? Itā€™s like, ā€œWell, I want the biggest challenge. Iā€™m gonna let my software as free as you could possibly let it free.ā€ Thereā€™s a lot of startups, a lot of businesses switching over to things like SSPL, AGPLā€¦ Any concern about AWS competing with you, or the big dogs coming in and eating your lunch?

Everybodyā€™s trying to figure out open source companies and how to do this properlyā€¦ And one model of doing this is the open core model, where your open source software would be free, but then youā€™d kind of have an enterprise edition that you add on some extra nice features, and you would charge for that.

You can also get into some licensing trickery, where maybe you make your software AGPL-licensed, and kind of allow people to run this locally, or kind of in non-commercial applications for freeā€¦ But once you get into the commercial realm of things, you are then asked to pay a fee.

I think for Deno - this is a programming system that weā€™re asking people to program against. Weā€™re asking a lot of our users, weā€™re asking them to invest a lot in the systemā€¦ And I personally would be very, very uncomfortable with programming using the base layer of my ā€“ you know, Deno sits below all of your other software; I would feel very uncomfortable if there was some weird payment hook at that layer of the system. It would prevent me from ever even trying out the software, in factā€¦ And I think thatā€™s the case with Deno. If we tried to make Deno itself commercial, and people are looking at Python, and Node, and Ruby as alternatives, I think many would choose the solutions to this problem that do not have a payment hook in it.

[01:00:11.01] We are pursuing a different funding/revenue model. As I said, we think this software is pretty useful, and we think itā€™s useful in different commercial applications. I havenā€™t mentioned it yet, but Deno - you download it as this one executable, but itā€™s actually a collection of software, and weā€™ve been pretty careful in breaking this up into different bits that we can recombine in different waysā€¦ So we have a product that weā€™ve been working on for the last six months or so that is a different runtime. It is called Deno Deploy, and it has a very similar API to Deno, a very web browsery API. Itā€™s a JavaScript runtime, but it doesnā€™t run on your computer, it runs in the cloud. You can think of it as a dynamic CDN if you want toā€¦ So we have processes running in 22 locations around the world, and we have an Anycast IP, and you can provision a domain name on our system. When you go to access your domain name, it resolves to this Anycast IP, and that gets routed to the nearest data center. So if youā€™re in Tokyo, it gets served locally in Tokyo.

And rather than a CDN which responds with static content, this invokes a JavaScript hook. It is a serverless system, so think AWS Lambda, or Cloudflare workersā€¦ So itā€™s a system for responding to requests dynamically. The best way to describe it is itā€™s a web server, a multi-tenant web server with V8 built into it. It is completely a separate system, and this thing AWS cannot ā€“ this is not open source; this is proprietary code.

Right. But itā€™s still Deno in terms of the API, soā€¦ Iā€™m using Deno to develop, I can use it locally, I can deploy it on my VPS fine, but if I want to run it in this capacity where my users are in Tokyo, so my Deno process is running in Tokyo, then Deno deploy is just like, you know, a push away or a sign up away. Itā€™s a pretty cool idea.

Thatā€™s right. Of course, you can take Deno - the executable that you download, thatā€™s free - and you can wrap that up in a Docker and you can send that out to AWS Lambda and kind of have a very similar experienceā€¦ But that is not what we are doing internally. We are not running Deno in some Docker containers. We actually are kind of using the V8 isolateā€¦ We were talking about how this is a secure sandbox before. So instead of having multiple Linux VMs running for all of the different tenants on this web server, we actually have all of these little V8 isolates running. And these, as we mentioned, are secure sandboxes, so we donā€™t have to worry too much about hackers being able to see other peopleā€™s requests and whatnotā€¦ And the nice thing about these is theyā€™re super lightweight.

This is essentially like opening a tab in a web browser. So think of a web server with a bunch of tabs in it, and each of the tabs is for a different tenant on the system. We can respond to requests very fast. We have cold start times in less than ten milliseconds. Iā€™m not sure the exact number. And we do all sorts of nice optimizations.

Obviously, it only runs JavaScript. This is not a Linux VM, so you cannot run your Python process in this. But because weā€™ve built explicitly on top of V8, we can make all sorts of very nice optimizations, like Cloudflare has done, to speed the response time.

I think even so someone has to be really motivated to do an Amazon deploy with a Deno repackaged. Iā€™m not sure if thatā€™s part of their business model to serve customersā€¦ But I could be wrong.

You never know what theyā€™re gonna do next.

[01:04:08.04] I mean, you just never know. You just never knowā€¦ The liberal license, the permissive license MIT, open source, single binaryā€¦ A collection - sure, maybe they would do that, but I donā€™t think thatā€™s their model. So I think your goal though is to provide Deno as it is to ā€“ I guess to maybe solve some of the problems you didnā€™t do well enough with Node, and sort of live on those dreams you had with Deno, but then still have this commercially-applicable ability on top of Deno. And you mentioned in your announcement for the company, ā€œWeā€™ve been hinting at commercial applications.ā€ So correct me if Iā€™m wrong, Deploy is just one application, so ā€œā€¦applications of this infrastructure for yearsā€ - what are some other ideas that you have that you can share? Is there anything you tease, or mention, or early-announce?

Right. Weā€™re working on this deploy product, and thatā€™s the only thing weā€™re going to be working on for the foreseeable future. But other applications would be, say, Electronā€¦ We think we could do a much better kind of GUI application framework than Electron has, given that we have Rust, and then Deno is kind of broken up into these building blocksā€¦ Generally, thereā€™s all sorts of systems that kind of want little one-off JavaScript little bits to be scriptableā€¦ And we think that ā€“ there may be all sorts of hidden use cases where people might want to have a Deno API. And by the way, I should be explicit - Deno is trying not to have an API. Deno is trying to be the web browser API. Deno is trying to not have a specific Deno API, but just - if you want to encode a string into a uint array you use a text encoder. We donā€™t have a special Deno API for that.

But yeah, I think thereā€™s databases that may want to do, say, MapReduce with JavaScript. Potentially, thereā€™s some commercial application thereā€¦ But yeah, I think for the moment weā€™re focused on this Deno Deploy. The idea is that if youā€™re writing a website, you write some JavaScript, you might run this locally, with Deno on your computer; maybe spin up a local server to serve that frontend JavaScript. That kind of server-side code to assist you in writing this frontend stuff, or maybe any backend code that you write is also very web browsery. It uses the same WebSocket APIs, for exampleā€¦

So thereā€™s basically three different deployments - the web browser, frontend JavaScript, your local computer where youā€™re going to be writing some server-side JavaScript, and then maybe you wanna deploy that server and run it globally, so then you send out that code to Deno Deploy. And by the way, you can take that executable and you can deploy it yourself. So youā€™re in no ways locked into using our Deno Deploy systemā€¦ But weā€™re going to have the best way for you to deploy your Deno scripts.

Whatā€™s the state of Deno Deploy currently? Is it in beta? I know people can use itā€¦

Itā€™s in beta.

What is the state of ā€“ it has a commercial product; itā€™s not collecting funds currently. People arenā€™t paying for it currently. Itā€™s sort of available to useā€¦ How do you plan to convert that into commercial? Whatā€™s the current state?

Yeah, itā€™s in open beta right now. I would consider it a technology demo at this point. Weā€™re working on cool features that will be announced soon. Yeah, we will have a general availability announcement. We donā€™t have a deadline for that yet, but we hope that it will be later this year. Weā€™re thinking in the six months timeline or so. But yeah, itā€™s usable. People should try it out. It hooks up with your ā€“

Production-ready then? Production-stable?

I would not, no, consider it that.

[laughs] He said usable, he didnā€™t say production steadyā€¦

Okayā€¦

You can use it.

[unintelligible 01:07:46.20]

Yeah. We have no SLA. Itā€™s something that ā€“ you know, if youā€™re interested, you should try it outā€¦ But I would not use it for production problems at this point.

[01:07:58.25] So if thereā€™s a future then for Deno, that place of competition might be with Deploy. Because if you claim here now that you intend for Deno Deploy to be the best way to run a Deno application, then that might be the way. If Deno wins like Node has wonā€¦ And we havenā€™t asked you if you planned for ā€“ I assume so, but if you planned for Deno to take over what Node is, to replace Node particularlyā€¦ But if it becomes as big as Node has become, and as usable and Node has become, then thatā€™s the place to compete with you, would be on the deploy.

I guessā€¦ Iā€™m not sure what youā€™re asking, actually.

Well, to deploy, similar maybe for ā€“ you know, thereā€™s some examples from WordPress, for example. Thereā€™s particular hosts that are amazing at hosting WordPress. If Deno wins and becomes very popular, to gain market share, to have a commercially viable application, or a company, or a SaaS product, you might want to compete with you all to host Deno applications.

Yeah, I mean, I would encourage anybody who wants to ā€“

Compete. To compete.

ā€¦also be running a Deno service, yeah.

Ultimately, thatā€™s good for the ecosystem anywaysā€¦

ā€¦and Deno the company. Probably a pretty good competitor when it comes to running Deno in these different contexts, right? So I would assume youā€™re welcoming competition.

Yeah. And by the way, weā€™re investing a lot in this Rust/JavaScript infrastructureā€¦ So when you go out and see products that are serverless products that execute JavaScript and donā€™t look like extremely Nodyā€¦ So a lot of this stuff is actually Node, but kind of newer server-side JavaScript APIs - yeah, look carefully. It may actually be Deno or one of its lower layers of crates. We expect that and we encourage that. This helps the ecosystem.

Taking it back to Deno Deploy for a second, just thinking through it as an end userā€¦ And it seems like a lot of these serverless solutions donā€™t have the database story; when it comes to my backend, if Iā€™m going to run all my code, my dynamic website at the edge, but my database isnā€™t collocated with those edge nodes. Itā€™s in New York City, running on a Postgres server or whatever - it kind of defeats a lot of the advantages of having that locality of that runtimeā€¦ Because most backends arenā€™t just doing mere math. Thereā€™s some data stored in some place, and theyā€™re gonna go hit the database, and theyā€™re gonna figure it out, and theyā€™re gonna put stuff in and take stuff outā€¦ Is there anything with Deno Deploy that collocates a database, or makes it so that my Deno backend has all the things it needs right there with it?

Not yet. You certainly see Cloudflare going in this direction with Durable Objects. Right now, Deno Deploy is this ā€“ I would consider it kind of the minimum viable product, which is that it responds to requests.

There you go.

So you can send back a responseā€¦ You can make outbound requests. Letā€™s say you have a Firebase database hosted by Google somewhereā€¦ You can make outbound requests to that data store for any persistent needs. Weā€™ve basically pushed the persistence problem out of our problem space at the moment. And you know, there are problems ā€“ sometimes you just want a little redirect server, and thereā€™s no need to have persistence in some applications. Obviously, many applications need persistence, and this is one of several features that weā€™re looking at in the coming months.

Cool. So what happened with Node the last time around? Iā€™ve referred to it earlier with the Mikeal Rogers reference, was that there was a lot of opportunity in the early days, and a lot of people jumped in and became influential, impactful JavaScript people because they helped out with the early days of Node. And this is potentially a new opportunity with this new round with Deno, where itā€™s early daysā€¦ You have a core team, you have people doing stuff, thereā€™s a standard libraryā€¦ Thereā€™s a lot more stuff that Deno has, I think, than that Node had when it first began.

[01:12:13.11] But the question is, if Iā€™m a developer, Iā€™m an open source person and Iā€™m thinking ā€œYou know what - Iā€™m gonna take a bet on Deno as an ecosystem, and I would love to be impactful, I would love to help out in ways that are bigā€, whatā€™s the best way, whatā€™s the easiest stuff, low-hanging fruit, the real fertile ground for getting involved and being impactful with your code in the Deno ecosystem?

I think the standard library is ā€“ we havenā€™t talked about this that much, but in Node there is no standard library. There is a lot of utilities built into Node itself. But part of the Node dependency problem is that when you just want a small little utility, when you wanna Leftpad your string, or whatever, you have to end up pulling in a third-party dependency. And in Deno, what weā€™re doing is collecting all of the main useful things, and itā€™s a bit ambiguous which things should be considered part of the standard library and which things shouldnā€™t beā€¦ But in general, if a lot of people need those utilities, we put them in there. Thatā€™s a very nice way to contribute.

We have a style guide, we have testsā€¦ Itā€™s something that affects the entire community, soā€¦ People contribute modules to the standard library. And obviously, people should ask first before randomly contributing things. It would be unfortunate if you did a bunch of work and then weā€™d have to reject it, for some reason.

Right. Where do you ask?

This is a way to be very useful in the Deno community.

Where do those questions go? Is it issues on repos, is it mailing lists?

Yeah, thereā€™s a deno_std repo on GitHubā€¦ Just open an issue and discuss it. Generally, weā€™re very open to adding new libraries in the STD.

Is the STD in Rust also, or is that in TypeScript, or in JavaScript?

Thatā€™s in TypeScript, yeah. These utilities built on top of Deno. Obviously, if people know Rust and want to get into the internal system of Deno, thereā€™s a whole world there to explore. But thatā€™s a bit deeper.

We have a Discord, itā€™s very active, and thereā€™s a lot of channels where people are discussing new ideas, so I would encourage anybody to jump on there and hit me up with any ideas.

Are there any particular applications that are currently leveraging Deno that you wanna call out, or that youā€™ve been impressed by?

No, actuallyā€¦

[laughs] Still early days?

Still early days. I mean, people are playing around with stuffā€¦ And generally, this is a very similar system to Node. So if you make a chat server, I wouldnā€™t call that out as particularly interesting necessarily. I think the interesting bits are around the tooling and how we can make these workflows much faster for people, and simpler. But the actual applications built on top are very similar in the end.

Letā€™s say Iā€™m sitting on an existing Node app which is medium-sized, and itā€™s running the business, but itā€™s not like 50 million lines of code. What would a port take, or what would it look like? Relatively straightforward, or are there serious dragons there?

If itā€™s already using ES modules in TypeScript, it should be relatively straightforward. If itā€™s common JS and kind of old-school style Node stuff, if would be a bigger undertaking.

Thanks for sharing so much, man. This has been very enlightening.

I really enjoyed it, and I appreciate you coming on.

Yeah.

I appreciate you making time in your schedule to finally do the podcast with us after so many years. I guess weā€™ve never really invited you either, butā€¦ Sorry.

[laughs] No wonder you never came on.

Youā€™ve been hard to get a hold of for the last 11 yearsā€¦ But Iā€™m glad you made time to show up here at the Changelog, we appreciate thatā€¦ So thank you, Ryan.

Yeah, thanks for having me.

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. šŸ’š

Player art
  0:00 / 0:00