Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about websites. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you?

Chris Coyier: Oh, I'm doing absolutely fantastic. Big episode today, big guest, Ryan Dahl. Hey, Ryan. How are ya?

Ryan Dahl: Hey. Glad to be here.

Chris: Yeah. Thanks for coming on. Probably a whole lot of people on this world know you as the inventor of Node and now I have to say the word, and I'm not prepared to do it, but I'm pretty sure it's Deno. Eh?

Ryan: That's right. Yes.

Chris: Yah!

Dave: Yay! One shot. Nice.

Ryan: The big controversy about how to pronounce it. It is dee-no. Yeah.

Chris: I like it because now that there's Vite, too, which is also impossible to remember how to say, you use the higher-pitched version of both. Deno and Vite. You know? Now everybody knows and nobody will ever screw it up again.

Okay. Fantastic. Dave, where you do want to start this thing? We have so many things to talk to Ryan about.

00:01:20

Dave: I think what I'm mostly interested in is Deno and how it applies to me in the year 2023, I guess. Then I think if people haven't seen it, you had a really great talk about the five things you kind of were, I guess, upset. Five misgivings about node and how it all shook out and that you're trying to address in Deno.

Chris: Was it just five? I have the video here of one where you had ten.

Dave: Oh, ten? Was it ten?

Chris: That's kind of a famous talk.

Ryan: Funny story about that title. That's actually not the title of the talk. If you go watch the YouTube recording, the talk has a completely different title.

I think it was a good title. It's very clickbait-y, right? I wish I had that title. But, yeah, actually I think the title was "Things I Regret About Node." And if you count them, there's actually not ten of them, but whatever. The sentiment is the same.

Chris: Yeah, indeed. That's great. That, I feel like, is going to go down.

It's funny even how you intro the talk. You're like, "This wasn't what I was going to talk about, but I'm just going to wing it on this." Then it turns out to be one of the perhaps just legendary tech talk, and people really appreciated you.

You're like, "Wait, the guy who wrote this thing is going to tell us what's bad about it?" [Laughter] Classic. But it gave birth, too, because a third of the end of the talk is, "And that's why I made Deno."

I know that was a number of years ago, but can we just go back to that moment? Can you give us the birth of this thing? I think, the listeners of this show, if you don't know, that's what we're going to end up talking about.

There was Node. Node is great. Node is huge. Tons of usage of Node in the world. And here's the creator sitting here on this show who said--

Actually, I don't know how he feels about Node these days, but he's basically created a better version of Node and it's available for us here. So, tell us.

Dave: I mean even though -- backing up, sorry. What possessed you with the idea to put JavaScript on a server?

[Laughter]

Dave: I mean--

Chris: Okay. Let's go all the way back.

Dave: We're going back because I feel like when I heard that news, I was like, "Good luck, bud."

[Laughter]

Dave: I mean how was that? Was it as wonderful as you thought, putting JavaScript on the server?

00:03:51

Ryan: It was more wonderful than I could have imagined. That was kind of one of the--

There are kind of these unique moments in tech where you can kind of put two things together and they work really well, and Node was definitely a case of me just working in the right place at the right time. V8 had just come out. I had been working on NGINX modules and thinking about how to program non-blocking Web servers, which previously was very convoluted and very kind of a black art that needed very [laughter] advanced skills to kind of navigate.

I was also thinking about Ruby and Python and how a VEN machine and Python's twisted, how to kind of get non-blocking servers working in dynamic programming languages all around the time that Chrome came out. And with Chrome came V8. It was really just a matter of, "Oh, wow. I think I can build a Web server in JavaScript." Actually in C, but kind of surface it in JavaScript and give people the ability to program a non-blocking server where it can really handle many thousands of connections at once.

This non-blocking... The way that you program non-blocking servers is actually very similar to how you program front-end websites. You have a button and, when somebody clicks it, you get a callback. You don't start a new thread. When you have a server, you get a callback, essentially, when somebody connects to it or when a socket becomes readable or when a socket becomes writeable.

The kind of idea of working in callbacks is kind of the main restructuring in your brain that needs to happen for non-blocking servers. And it just so happens that JavaScript programmers are already thinking in a single thread, already thinking about callbacks a lot, and it's already kind of part of the paradigm.

Just putting those two things together turned out to be really a good idea. It was pretty clear, I think, from maybe a month into the project that, like, "Oh, this is really awesome, and this is going to be a big deal."

Chris: Wow! You're writing it in C, you said, right? Obviously, you can't write Node in Node, right?

00:06:40

Ryan: Yeah. Node is C++. Yeah, you start building little example servers. I think my first example server was a little IRC server written in JavaScript on top of Node, and it just was like, "Okay, now I can write an IRC server in 500 lines of JavaScript." This was just completely not possible before that.

Yeah, that was very exciting. It did take another five years before this became... You know it's clear that this was something cool, but it was not clear that this would literally be used by like every website. I mean Node these days is pretty much involved in if not actually serving the website--

Chris: Part of the build or whatever.

Ryan: It's certainly involved in kind of the build process for if you're using React or basically any front-end framework. You're using Node in some sense. That level of just having millions and millions of users was not super clear from the outset.

Chris: [Laughter] I'm sure it wasn't.

Servers and non-blocking servers, specifically, was part of the impetus, or whatever. But was there a moment pretty early, like, "But there are so many people out there that already know this syntax that I'm unlocking them, that I'm taking their skillset and making them more powerful"? Was that in your mind?

00:08:09

Ryan: Yeah. I've always been interested in scripting languages for that reason: Ruby, Python, JavaScript. I don't know. It excites me.

Doing something with computers is always fun, but if you can enable a bunch of people to do stuff very quickly. And clearly, scripting languages allow people to move very quickly is really fun and allows people to really, yeah, just move very quickly when you have kind of a garbage-collected scripting language.

Chris: Mm-hmm. I almost think of it... I mean this is a stretch perhaps, but when jQuery came alone, it was like, "Let's make the CSS selector kind of like the primary thing of jQuery. Let's take something that some people already know and give it to them in this other way."

I wonder if that was - I don't know - just a powerful moment. "Let's combine two things together!" and popularity happens.

Ryan: Yeah, I think the story of JavaScript is nobody would have invented this language. It's kind of a nasty language that has just kind of evolved.

You know Brendan Eich is the inventor of JavaScript. But there's no way that he would have sat down and made the language as it is today. It's just this weird, evolving thing that has a lot to do with social interactions, of many thousands of programmers that are working on standards and working on websites.

John Resig comes out with jQuery and that kind of influences the standards. Yeah, you get document query selector. I don't know. It's just kind of interesting how this thing is evolving.

These days, it's really the default programming language in a very real sense. It's kind of the English of programming languages. Basically, every programmer can speak JavaScript to some degree.

Chris: [Laughter] The English of programming. I think you're right about that. I was part of a group that taught kids for a while. I didn't do the curriculum. I just experienced the experienced the curriculum while the kids were learning, and the goal was to make them more front-end.

The goal was, let's get into the browser, and let's make a website that you can see because that's such a satisfying moment, I think, for a lot of kids. Or at least that was the goal of this class. But they started in Node because the point was, "Let's get used to the command line," and Node was great for them there because they got used to the syntax of JavaScript before they were introduced to DOM APIs and stuff. That was a long time ago, so Node has been around for a minute.

You invent it, get it going, but not forever. You haven't been shepherding Node through its entire history, right? You, at one point, stepped away from all that.

00:11:13

Ryan: Yeah. I was working for a company called Joyent, which has subsequently been sold to Samsung. Joyent bought the project from me very early on, and this was great for me at the time but kind of vested my interest in the project.

Yeah, I was the gatekeeper, as we called it, for the first two or three years of the project, and then handed it over to Isaac Schlueter, and then a chain of other people who were subsequently more and more distant from the project. It kind of created some controversy at some point with an IOJS fork of Deno at some point.

Chris: Oh...

Ryan: And the subsequent move of Node into the Linux foundation, ultimately.

Chris: Okay. Then I don't know how deep you want to go into those middle years. It's almost more interesting to get up to that point where this, I think, 2018 talk of, like, "Okay. I have this history with Node. I see some problems with it. I have it in me."

Not a lot of people have two major projects in their life. You do - somehow. [Laughter]

"I'm going to start over. I think I'm ready." What was the mental moment of, like, "I'm ready to do this all over again"?

00:12:50

Ryan: You know, in my mind, I was effectively trying not to work on Node for these intervening years because of this agreement with Joyent. And I think coming back to the project, trying to build on top of it later on, realizing that there are all these bugs. There are all these ways that Node is working that were just not intended to be that way. They were just leftover bugs, and now there's this whole ecosystem of people that think that this is somehow deeply embedded in the system.

I think, at the same time, just kind of realizing that the Web browser and true JavaScript is actually moving forward pretty rapidly. JavaScript is changing every year. It's not like a fixed language.

The move from callbacks to async/await, the move from CommonJS modules to ECMAScript modules, the general movement to TypeScript, in general, and just many other things. JavaScript of 2009 is clearly not the same as JavaScript of 2022 or 2018 - whenever I gave that talk.

Yeah, it's just kind of disappointing, and I talk about that in the talk, that effectively this project isn't really moving forward and the delta between Node and browser JavaScript--which you know browser JavaScript is always going to be the future of JavaScript. That's clear--is just getting wider and wider.

Chris: Do those standard bodies even care? Do they think about Node? Or are they just like, "Y'all catch up when you get to it"?

00:14:50

Ryan: TC39, they certainly think about it, but ECMAScript modules is kind of explicitly not CommonJS modules, which is kind of the required syntax that you have in Node. They think about it, but their main goal is pushing forward browser JavaScript, as it should be, and Node is a bit of an afterthought.

Yeah, I think that kind of widening gap just at the highest level is what that talk is complaining about.

Chris: I see, so if you land anywhere, you land on "I wish this server-side version of JavaScript was immediately in line as JavaScript develops. I want to be ready for that, ready for change."

Ryan: Coming back to your jQuery and CSS selectors, people should be able to take their browser skills and use it to build servers. That's the main idea. And the wider that gap becomes, the less utility you have there.

You want to be able to reuse skills, and the whole point of using JavaScript in the first place is to be able to reuse what people know from the Web browser. So, why does Node have its own HTTP client instead of the fetch API?

There are many of these sort of problems. You can chock it up to a couple of different things, but I think a big part of it is just that it's a big, monolithic C++ codebase that was created ten years ago, and it's pretty difficult to move that codebase.

That talk was just a demo of thinking about how maybe we could do things differently and what it might look like if we were going to design it today. I totally expected to throw away that code after the talk.

Chris: Really?!

Ryan: But surprisingly, yeah, people started contributing to it and got excited about it, and so I put more work into it. Yeah, now Deno is the top 20th software project on GitHub (in terms of stars, anyway). Yeah, many tens of thousands of users every week are using it.

Chris: That's wild. That's wild. We should get into the differences, but I guess one thing you have doubled down on then is that it is still JavaScript. The Venn diagram of what Node and Deno serves is pretty similar.

00:17:45

Ryan: Absolutely. Yeah, yeah. I think the main goals here is to make this easy for people to kind of take their browser skills and use them server-side, so we put a lot of work into developer experience, and that is a lot about standards and APIs and making sure that we're passing the Web platform tests. Like if you go on MDN and kind of look at the browser compatibility tables, you'll see Deno down there.

It is truly one of the Web browsers. It implements very exactly a lot of the APIs. It passes the same tests as browsers do.

Chris: Mm-hmm.

Ryan: But developer experience also extends to the LSP (language server protocol).

Chris: I think that's right. Yeah.

Ryan: Anyway, the thing that VS Code talks to, to give you Intellisense.

Chris: Give you autocomplete and all that? Yeah. Yeah.

Ryan: Yeah, to code formatting and just test, having kind of a test system built in, and just making it easier to get started with stuff without having to have a Ph.D. in NPM modules before starting building their project (just to kind of answer those questions in the same way). Taking a lot of inspiration from Go, actually, where they kind of have a full toolchain of tooling there. But yeah, developer experience.

Chris: Yeah, I notice you have a pretty good standard library like Go does. Go has all kinds of good standard library stuff.

00:19:31

Ryan: Yeah. Node never really had a standard library, which has created this kind of dependency problem where there are many, many small NPM modules that are servicing just super niche things. Left pad, I think, is the canonical example.

Of course, whenever you are adding dependencies to your project, that dependency is going to have another dependency, and that other dependency is going to have another dependency. And so, you always have the possibility of a dependency explosion.

But if you have kind of a common standard module system, then it becomes less of a problem. It doesn't exponentially explode like that.

At some point it's more like a diamond problem. You have five dependencies. Maybe they each have five dependencies. But they all kind of circle back to the main standard library.

Chris: I feel like JavaScript was already pretty thick with that stuff. You don't need a library to parse some JSON. You don't need a library to find something in a string. Whereas with Go, you totally do. [Laughter] You know?

Since JavaScript is already pretty thick with helpers, what's the top standard library thing that Deno adds, or any of them?

Ryan: Things that extend it beyond that, so parsing byte strings.

Chris: Oh, there you go.

Ryan: We have a collections module with RB trees, a bunch of algorithms like flag parsing or .emv is a very common module that people use to load stuff.

Chris: Ah, yeah.

Ryan: Just a semver parser, right? Just an asserts library for use, you know, asserts equals. Right? There are a lot of utilities that are very common but not so common that they're actually in JavaScript itself.

Dave: I feel like you're trying to throw my Jest testing setup under the bus here. [Laughter]

Ryan: Kind of. Yeah.

Dave: Implying that it's overly convoluted and has a weird require dependency.

Chris: What is the testing story? Is it Jest? Did you ship it with a tester?

00:21:56

Ryan: No, there is a built-in test runner.

Chris: Oh... Nice.

Ryan: And it's quite advanced, and it can do fancy things like making sure that all of your promises have completed by the end of the test. I think the main thing with a testing library is just to have one that everybody can use and not to have everybody kind of come up with their own.

More or less, all of these testing libraries are the same. Maybe some different terminology. Maybe some slightly different methods here and there. But I mean, more or less, you just need something. You need a bunch of functions that you can run with a command and see that they don't throw errors. Right? That's more or less what you're doing.

Chris: Yeah. Well, yeah.

Dave: Is that kind of your general thesis, like, we put too many flavors into the JavaScript ecosystem? Is that sort of what you're trying to combat?

Ryan: Yeah, there's too much choice. Yeah. There's too much unnecessary choice going on. I think, as programmers, to take a really silly example, tabs versus spaces. It's just like, "Are we really going to have this debate?"

I think every company I've ever worked in has had this debate at some point. It's just like, "This is just a waste of time. Just choose one and move forward." There is not really a big difference between the two (at the end of the day).

In many ways, we're trying to make some sane choices and just trying to alleviate people from having to decide those things. Do you really want to decide how your code is formatted, or do you just want everybody to use the same?

Chris: Hmm... I like that a lot. Please don't make me pick anymore.

Ryan: I hope we don't dive into a tabs versus spaces debate right now.

Chris: No, let's not. [Laughter]

Dave: We've got an hour. [Laughter]

Ryan: [Laughter]

00:23:56

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Sanity, the Sanity composable content cloud. Yeah! The SCCC power, awesome digital experiences for companies like PUMA, Sonos, Skims, Figma, and more.

Sanity makes your content composable, reusable, programmable so that your team can deliver outstanding experience to your audience faster and easier than ever. Their content authoring product, Sanity Studio, just got a major upgrade. Sanity Studio is an open-source, single-page app, super-fast to set up, easy to configure as your needs grow.

If you've ever felt bogged down by the limitations of a CMS, Sanity Studio now frees you to customize a content authoring experience for any type of experience. A couple of things that are particularly awesome: This new studio customization framework that enables you to tailor the studio to your specific needs without adding any maintenance overhead. Less code.

it also has full TypeScript coverage, so you can customize your studio with confidence, support from your favorite code editor. The new studio enables embeddable authoring, so you can now embed Sanity Studio as a dependency in another application.

You and your team will be able to navigate to the Sanity Studio using the familiar pattern like your website /admin. It's like any other CMS in that way, which means less context switching.

The studio also allows you to set up workspaces to deeply customizable environments, to organize your content by team, product area, region, readiness, or whatever works best for your team.

You can get started to try out Sanity with a free boosted plan with increased API and bandwidth limits. Just head to sanity.io/shoptalk to get started. Thanks.

[Banjo music stops]

00:25:58

Chris: There are some notable differences with Deno, and a couple of them that I think I really would love to hear more about. One of them, I think it's maybe even just from the homepage of it. It's this kind of secure-by-default situation, and maybe it's from your talk, too. If you download a linter -- I think was your example -- that can update your code, there's no reason that linter should have access to your entire computer. That's just weird.

Or if you execute some code, there's no reason that that code absolutely has access to the fetch API, or whatever. Why should it? I would prefer to give it that access if I give it to it, but not have it by default. And that seems like a huge difference between Node and Deno, to me, [laughter] somebody who has spent plenty of time trying to secure the execution of Node in weird environments.

I operate or a cofounder of CodePen, and we have all of these processors that we try to run. Recently, they're in Lambdas. That's nice. There's some security of running Node in a Lambda, but not all. There's still dangerous crap people can do. And it's like, "Gosh, I wish Deno existed then. I would have written them all in that and just have it been secure by default and rock and roll." You know?

Anyway, I said too much. What's up with secure by default?

00:27:20

Ryan: Where to start... Where to start... [Laughter]

JavaScript is actually one of the most security-conscious languages, but kind of ironically, in the Node and NPM system, we have some of the biggest supply chain attack problems out there, and in part kind of caused by this dependency problem. You just have so many dependencies in Node, and you're hooking.

With great power comes great responsibility, right? You're hooking into a huge amount of infrastructure, but there's no way you can audit all of that code. By default, in Node, you have complete access to the system, and that's kind of a shame because JavaScript, by default, is a sandbox. Right?

Each of your kind of browser tabs cannot access each other. They cannot read your browser cache and look at your credit card information.

I would consider this kind of adding to the delta between browser and server-side JavaScript. In Node, I just never thought about that. I was too busy trying to make servers with Node.

In Deno, yeah, basically, we just weren't as loosey-goosey with security as we were in Node. It's really hard to claw that back after the fact. But from the outset, we've built Deno with the idea that, by default, running your program, you have no access to the system.

Obviously, this is a server-side system accessing the network. Accessing the hard drive is probably something you might want to do at some point. And so, you can kind of conditionally plug holes into the system to allow read access to files. You can do allow net and give an allow list of say you only want to access googl.com and reject all other connections. You can just kind of conditionally plug holes in the system as the lowest privilege necessary for what you're trying to get done.

Chris: It's fricken' great. What else does that? Ruby doesn't do that. You know? [Laughter]

00:29:42

Ryan: Yeah. I don't think they can do that. I mean a lot of these--

JavaScript is just so security conscious because of the browser, right? The browsers have to be secure. You have to be able to visit a website that you don't trust. And so, just a huge amount of work has gone into hardening V8 and other JavaScript runtimes against attacks.

Why not use that outside of the Web browser? I think there are all sorts of situations that that is not just useful but kind of paramount, right? In particular, when you're starting out a project and adding some dependencies to it, do you really want to--? I mean do you know that when you NPM install something, that program can run... those modules can run post-install scripts which have unconditional access to your system?

Chris: I do know that. [Laughter]

Ryan: Any time you add an NPM module, you are giving unconditional access to your entire system. You have no idea of the thousand modules that are going to be installed on your system, what's going to happen. That's pretty scary.

Of course, the solution maybe is to always run that in a docker container. But I think [laughter] that is not happening for most developers.

Chris: Yeah, right. Easier said than done.

Ryan: Yeah, having, utilizing the JavaScript sandbox that is just available in V8 is very useful. And so, in Deno, you can always run this. By the way, in Deno, you can link to NPM modules and run them without concern about giving them -- without having to give them full access to your system.

00:31:45

Chris: Hmm... So, it does have NPM support. Yeah?

Ryan: As of recently, so when I gave that original talk, it didn't. The only way to hook into external modules was through HTTPS imports, so actually giving--

You could put your modules up on Jest or on GitHub and kind of put a URL to that in your code. Since version 128, which came out in November, last November, you can now import NPM modules. We put a lot of work into compatibility.

Chris: Do you import them the same way where it's just like import React from React? You don't have to give it a full path to wherever React lives?

Ryan: It's import React from NPM:React.

Chris: Oh...

Ryan: You still have to give the little URL up there because module specifiers should be proper URLs.

Chris: Should be URLs.

Ryan: NPM:NPM, that's kind of like a schema, a scheme for the kind of NPM URL. In some ways, it's kind of like a portal into this Node ecosystem.

Chris: It just looks like one, though, right? Does V8...? I don't know. I don't know what I'm asking. It just makes it look like a URL, but I guess that's enough to be a URL. [Laughter] I don't know - to distinguish those things.

Ryan: It is a URL.

Chris: Yeah.

Ryan: You can parse it with the URL class, for example. You can also use import maps if you want kind of bare specifiers.

Chris: Ooh... Nice.

Ryan: The traditional kind of React bare specifiers, so those can always be mapped back for kind of what people typically are using. But yeah, this is all kind of part of our pushing JavaScript towards the actual standards of what ECMAScript modules are supported to be, and not having this big delta between what browsers are doing and what's standardized versus what's happening in Node.

Dave: That felt like a big change. When Deno was announced, it was like, you don't get it from the package repository. You get it from the Internet. You get the module from the Internet. You saw the file. It's there.

Originally, too, it was TypeScript only, right? That was kind of the foundation. But, since, you've kind of layered in JavaScript support, or do I have that wrong?

00:34:21

Ryan: You have that wrong.

Dave: Okay.

Ryan: JavaScript support has always been there and it has always been a first-class language in Deno. TypeScript and JavaScript, it's not right to think of these as different languages. TypeScript is kind of JavaScript, just with types added to it. Right? It really is a very simple operation to take a TypeScript file, strip out the types, and then what's remaining is just a pure JavaScript file.

Anyway, we've always done that, and you're fully welcome to run JavaScript. I mostly run JavaScript with Deno. But it does have full TypeScript support, and I think TypeScript is where the language is going.

I think it is not standardized, but there are proposals for types as comments. Basically, when you have a variable and then you have a colon and then you have a type. Basically, what the proposal is suggesting is that the V8 or the JavaScript engine will just ignore that part and just consider it a comment. Eventually, browsers would be able to understand TypeScript directly.

That's a ways off, and that's a little bit speculative, but I think it's pretty clear that TypeScript is very useful to JavaScript programmers. JavaScript is great for getting started, but once you have a pretty complex program going on, TypeScript lets you scale that.

Dave: Pretty powerfully, yeah.

Let's say I have a Node app today. I'm running about seven right now. [Laughter] What does a migration process look like?

I'm thinking, like, what if I have a little server I'm running to whatever, to do some job - I don't know - do something? And then maybe getting more complex, I have a front-end app that builds a UI. Is that stuff Deno can do, or where is the sweet spot? What's the migration process like?

00:36:35

Ryan: I guess differing levels of migration depending on the complexity. Some simple kind of scripts that are pulling in some NPM modules, it's probably just a matter of modifying your imports where previously you might have done import express. You would need to now do import NPM:express. Again, import maps can allow you to avoid even that, but then you would need to create an import map.

Obviously, I guess even before that, in Node, you can do CommonJS modules. In Deno, you can't. We're kind of putting our foot down on that.

Chris: Oh, God. Thank you.

Ryan: We're not allowing you to--

Chris: That's so great.

Ryan: I mean it doesn't help our adoption because obviously people just want to run their old programs on this, but we're kind of putting our foot down and saying, "No, actually, you need to move to ES modules. You can use JavaScript. You can use your NPM modules, but you do need to use ECMAScript modules."

By the way, you can import NPM modules that use CommonJS. Internally, deep inside of Deno, we do understand CommonJS. We just don't allow you as a user to do that.

Chris: You write it? [Laughter] I love that. That's great.

Ryan: But you can actually import NPM modules. For example, express, I believe, is still written in CommonJS, and you can import express and run an express server in Deno.

Dave: Yeah. Yeah.

Ryan: I think it should be a pretty superficial change of some imports. We also require you to use file extensions in your imports. So, if you're doing import./src/server, you might need to change that to import./src/server.js. That is also in line with the ECMAScript standard.

I think, on that front, we might be a little bit more willing to allow that maybe with a warning in the future just to help people migrate. Yeah, some kind of superficial changes like that should get people up and running on it.

Chris: I don't think. You should keep it. Hardline. [Laughter] Got to use file extensions. It just seems better.

Ryan: Yeah, it's a tradeoff, right? That's kind of the big debates that we always have is, like, where to put our foot down. I mean our goal is really to push JavaScript forward and, like I said, close this delta between browser JavaScript and server JavaScript.

But, naturally, there's some pragmatism that has to come into this and allowing people to easily adopt Deno is also something that we're always considering and reevaluating. That's where we're kind of stuck with NPM imports for a while for that purpose. But at this point, the NPM imports have turned out to be really successful. It's working not with 100%. There's kind of a longtail of modules that are very old and don't work and do kind of nefarious things like use __proto__ which we were like, yeah, we're just not going to allow prototype hacking because that's just a security problem.

But 80% to 90% of NPM modules should work out of the box. The compatibility is very good at this point.

Chris: Does that mean it's a package.json file situation again then?

00:40:34

Ryan: It's not a package.json file. We do import maps. There are discussions about whether we should support... we should have Deno understand.

Deno does understand package.json when you do NPM imports. But for kind of the top-level code, you use import maps.

Dave: Wow. Neat. I kind of super like that, actually. I mean that's what you're trying to express, right, is just, "Hey, do this." Right?

Ryan: I encourage people to play around with it. I think you'll be surprised at how much cruft some of these choices alleviate. It should feel very clean and simple to get started with.

Dave: Do my Rollup, my Vite, my Webpack, do those all work as I'd expect on Deno?

Ryan: Vite, yes. Rollup, yes. Webpack, I am blanking on, but I think so. Yes.

Dave: Interesting. Yeah, I don't know. I've been thinking about front-end frameworks. You know how we do the big... Because we all have the module certification, and we do all the big bundling. Then we do the splitting. Then we do the shaking. Then we pay it works, and then it doesn't - or something.

But I'm just wondering if, like the import maps, it's just like, could something just slam my things together and give me an import map and, bingo-bango, that was my build process? I wonder if we're headed that way. I'd be curious about your thoughts of what steps the front-end needs to take because you're working on the servers and stuff. What does the front-end need to do?

00:42:18

Ryan: A little agnostic about that problem. Clearly, I think there have been some ideas in the past that maybe with HTTP2 pipelining and with ES modules that maybe front-ends don't need to bundle anymore and that you can literally just ship--

Chris: Don't bundle. No bundling.

Ryan: --ship all of your code directly to the browser. I'm suspicious of this. I kind of think that there's going to be bundling going on because where you can eek out performance, programmers are going to do that. It seems unlikely that many requests is going to ever be more performant than a single request for a bundle.

I guess where I do think that bundling will change is that right now we do bundling as a build step that happens at deployment time or before deployment time. I think with the introduction of new, easier-to-use serverless systems that are faster (and thinking in particular about Deno Deploy, the proprietary product that I'm working on, or Cloudflare workers) that we start having the ability to run JavaScript code in the cloud really, really easily and really that spins up super, super fast.

In the past, it's been kind of Lambda, and it's multiple-second cold start times and stuff. But now you can start thinking about running things like esbuild actually in the cloud in your server on first request.

And so, instead of having kind of an ahead-of-time build process for bundling, actually doing it just-in-time and caching those results so that you actually alleviate the whole build process and the whole, you know, "I'm opening a PR to this website. Now I have to wait for this thing to kind of build the site." But instead, just upload the code directly to the cloud and run that kind of just-in-time to build those JavaScript artifacts or do image optimizations or other things like that.

Chris: Ooh... That's some galaxy brain stuff. I'm not ready for it. [Laughter]

00:44:44

Ryan: Yeah, I think that's where we're going. I think we're not quite there yet. The technology is still kind of in its infancy, but I would imagine that it's just a much better developer experience if your deployments are always five seconds and you don't have to wait for some build process to run.

Chris: Yeah.

Ryan: Because ultimately, at the end of the day, your server is turing complete and can do all sorts of stuff. A big pattern right now is running React server-side and doing SSR to actually use React kind of the way that we used to use PHP as kind of a templating language and actually render static HTML server-side just-in-time for users. Why can't you also do that with a JavaScript bundling process server, server-side?

If we have the ability to run React code, we could as well also run esbuild. Right? We can run wasm up there. Yeah, the kind of serverless technology is improving quite rapidly now, and so I think that that's going to become more mainstream in the future.

Chris: I certainly agree with that. Cloudflare workers... Let's talk about Deno Deploy, too. But they literally are V8. I remember when I first was learning about that. I was like, "Oh, that's weird. I have to pre-bundle everything." They tell you explicitly it's not Node. It's not Deno either, apparently. It's just a chunk of V8.

But a lot of love for V8 in this podcast so far. Is Deno... is there V8? Node is not, right? It's like a rewritten version of all of JavaScript. Did you rewrite it all again for Deno, or is it V8 under there?

00:46:25

Ryan: No. Node is V8. Deno is also V8.

Chris: Oh...

Ryan: And Cloudflare is also V8, and Cloudflare workers was a very--

Chris: Everything is V8. Okay.

Ryan: Almost everything is V8. V8 is just one of the most serious battle-hardened pieces of software out there. I mean it's just very fast. It's very robust. It's just a great piece of software.

You can think of Node and Deno and Cloudflare workers as distributions of V8 kind of like there are distributions of the Linux kernel. These are kind of different flavors of that.

Chris: It seemed to be the year of flavors of JavaScript runtimes. We can lump Bun in there as well. Is that V8 too, or not?

Ryan: That's JavaScript core. Yeah, there are a number of demo projects out there kind of playing around with JavaScript runtimes. Just JS is another one that is kind of topping the Tech in Power benchmarks. That one is V8.

Chris: Interesting. I did not realize that all the way.

Dave: Everyone knows Bun is powered by Zig, but--

Chris: [Laughter] Thank you, Dave. I'm glad we got that out there.

Dave: Does Deno have anything fancy like that, [laughter] fancy programming languages under the hood?

Chris: [Laughter]

Dave: Or is it just more C++ and JavaScript?

00:47:53

Ryan: Deno is built on Rust and V8.

Dave: Rust? Okay.

Chris: Ah...

Ryan: Industry standard, very performant systems.

Chris: It's still one of the proper keywords, though. You have to either say Go, Rust, or an even fancier one like that in order to impress people these days, I feel like.

Dave: Well, this is very cool. I guess what do you want people to know about Deno today? Should we all just - this is our Christmas project moving everything over? [Laughter] Or what do you want people to know about Deno today or how to get started and try it out?

Ryan: Yeah, I mean it's focused on developer experience, security, and performance. As of recently, it is supporting NPM modules, and that support is here to stay.

Yeah, I'd encourage people to try it out. It should be a pretty great experience.

Chris: I'm thinking of Fresh. I don't know if y'all are involved with Fresh or that were other developers who took it on and did it, but that's kind of nice to see when an ecosystem has little tools like that that theoretically make it even easier.

Do you want to build a Web something with this? Then try this. Like - whatever. React has Next - or something.

Deno has Fresh - in a way.

00:49:25

Ryan: Yeah, Fresh is a Deno-first Web framework that is exploring, to great effect, some of these ideas that I was talking about earlier with doing kind of just-in-time JavaScript bundling, so it actually runs esbuild server-side.

Fresh uses this islands architecture for front-end JavaScript, so you kind of segment your code into server-rendered things and client-side JavaScript that kind of gets... The client-side JavaScript kind of gets loaded on-demand if you load one of those components.

The net effect of that is that if you build a website in Fresh, you will get a 100-page score on the Lighthouse for it.

[Laughter]

Chris: That's kind of good.

Ryan: It is very good at getting you a 100 Lighthouse score. It is more targeted towards content-heavy websites rather than kind of very dynamic websites. Think kind of e-commerce sites or wikis, blogs, things that are mostly static content with a shopping cart, like little bits of dynamic stuff versus something that is very dynamic like a dashboard. Yeah, dashboard is the right example.

I think the benefits, you can certainly do dashboards in Fresh, but you don't see the same benefits. Where Fresh really shines is kind of mostly content-heavy but with bits of interactivity.

If you care about performance and getting a 100 page score and kind of seeing the future of what it looks like to have a Deno-first Web framework, yeah, you should definitely... Fresh is a good entry point for Deno because comparing the Fresh getting started scripts to the Create React Script. Create React is just--

Chris: A beast, yeah.

Ryan: Minutes long of installation with hundreds of megabytes of NPM dependencies. Fresh is like two seconds. It's kind of ridiculously simple.

Chris: That's great. The showcase showing all the things that are possible is very robust for a thing that seems so relatively new. It's pretty cool to see.

00:52:01

Ryan: Yeah. Yeah. Fresh is handling some pretty serious production traffic, so we're using this for basically all of our sites at this point. It is handling many millions of requests per day. I'm hesitating whether I should go into the billions there, but definitely is production-ready software.

Chris: Mm-hmm. Then maybe we should end with what is the hosted service that you offer. I mean there's a pretty clear plan here, it seems like. This wasn't just like, "I don't know. I'm just going to do another open-source thing again and hopefully it gets really popular and maybe money happens again. Maybe the new giant buys it again - or something."

This is not that, right? This is like we're going to actually have a business enterprise of this.

Ryan: Yeah. I mean Deno... Node is not too far away from a lot of business needs, and we think that serverless is really in the area where this technology kind of where the rubber hits the road.

We built Deno not as a monolithic C++ project but as a module Rust project that's made up of many crates. What we do is the Deno open-source project and Deno Deploy are not really the same runtime, actually. We take those crates and recombine them and build a system called Deno Deploy, which is a serverless system. It has really great cold start times around the 100-millisecond range and really great response times. It allows you to run JavaScript - Deno or otherwise - kind of general JavaScript server-side at the edge that is running in 34 regions worldwide.

Yeah, Deno Deploy is handling many hundreds of millions of requests per day and is--

Chris: Woo!

Ryan: For example, it's acting as kind of a white label execution engine for some of the service. You might not realize it, but for example, Netlify edge functions is actually Deno Deploy under the hood, or Supabase edge functions is actually Deno Deploy.

Chris: Oh, is it? Okay, that's interesting. I was going to ask you. I was like, oh, maybe I won't bring up the Netlify ones because they're doing their own. You'd rather have people use Deno Deploy or something, but it's all the same. Use Netlify. All good. They pay me.

Ryan: I mean Netlify adds... makes it very easy to use and attractive. Yeah, it adds a lot of kind of... Yeah, the Netlify... It makes it interact with kind of the Netlify static hosting and stuff really nicely.

But yeah, under the hood this is Deno Deploy. Supabase edge functions, yeah. It is basically finding a niche as kind of a white-label serverless system.

There aren't too many true serverless systems out there. A lot of them are just rebranded versions of other things.

Chris: Yeah.

Ryan: That's not what Deno Deploy is. Deno Deploy is the actual infrastructure.

Chris: That's good. The lower level the better, almost. Dave and I could do ShopTalk functions. Just white-label it and throw a little DX around it.

Dave: That's what people want.

Chris: Everybody is making money.

Dave: Charge double. It's costing us.

Chris: [Laughter]

Dave: Baddabing-baddaboom, baby.

Chris: [Laughter]

Dave: This is cool, but it kind of comes down to this is a great choice for serverless because a lot of effort has been put into that security and performance, right? The footprint of Deno is very, very small, right?

Ryan: Yeah, absolutely.

Dave: Compared to....

00:56:08

Ryan: Don't forget the DX as well.

Dave: Yeah. Yeah.

Ryan: Deno Deploy understands TypeScript out of the box. You don't need to transpile and bundle. But yeah, we put a lot of effort into making sure that these things can handle a lot of load.

With serverless, you're basically building something that looks pretty similar to a Web browser. I mean you have many, many tenants, right? If you think of Chrome having many tabs open, none of those... All of those tabs are running separate applications that don't trust each other, and that's basically what a serverless system is doing. Except instead of a GUI thing on your desktop, you basically have a Web server, and you're kind of starting up all these tabs very quickly to handle requests from different parties. Trying to do that as quickly as possible is what we're good at.

Yeah. I think the secret sauce here is that we are not starting up docker containers for these. We're really utilizing the JavaScript sandbox and the fact... Think about how fast it is to start up Figma. Right? This is effectively Adobe Illustrator, right? But it installs on your computer in like one second.

These V8, these little JavaScript programs can start up very, very fast, and there's just been decades of work now to make these things as fast as possible. And so, we use that server-side to really, just in a blink of an eye, start up these things and respond to requests.

Yeah, this is what I mean by the next generation of serverless and serverless infrastructures is just much cheaper and much faster.

Chris: That's amazing! You can have this thing do anything from anywhere, right? From an edge location. Huge. Love it. [Laughter]

Dave: Very cool.

Chris: give it a KV store, and then we'll be really cooking.

Dave: That's Chris's pet feature.

Ryan: Yep. It's on my mind.

Chris: Cool.

[Laughter]

Dave: Well, great. Well, thank you, Ryan, for coming on the show and chatting with us about Deno. We really appreciate it. For people who aren't following you and giving you money, how can they do that?

Ryan: I don't have a Twitter, but you can follow @deno_land on Twitter. That is mostly me. And yep, I guess that's the only place you can. [Laughter]

Chris: [Laughter]

Dave: All right. Yeah. The website, of course, is deno.land. Deno.com now, no?

Chris: It looks like there's both, right? Deno.land is the open-source project.

Ryan: Deno.land is the open-source, and deno.com.

Dave: Oh, well, that's why I'm good at websites. [Laughter] Thank you. All right, well, thank you for coming on the show. We really appreciate it. That was very awesome and educational for me.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Join us in the D-d-d-d-discord. That's the best thing you can do. Patreon.com/shoptalkshow. It's a lot of fun.

This is the last episode of the season. We are going to take a little break. We'll be back in the new year with more guests lined up. Chris, do you got anything else you'd like to say?

Chris: I think that'll do it. Thanks so much, Ryan, and thanks, everybody, for listening. Take care. ShopTalkShow.com.