Time Jump Links
- 00:32 Guest introduction
- 01:23 The famous talk title
- 10:48 Stepping away from Node
- 12:35 What was the motivation to start Deno?
- 21:40 What is the testing story with Deno?
- 23:55 Sponsor: Sanity
- 25:42 Secure by default
- 31:46 Does Deno have npm support?
- 41:21 Do rollup, Vite, Webpack all work with Deno?
- 45:52 V8 in all the things
- 48:17 How should people get started with Deno?
- 52:26 What is the hosted service Deno offers?
Episode Sponsors 🧡
New Studio Customization Framework enabling you to tailor the Studio to your needs without added maintenance. Yay, less code! It has full typescript coverage, so you can customize your studio with confidence from within your favorite code editor.
The new Studio enables embeddable authoring. You can now embed Sanity Studio as a dependency in any application.
Navigate to the Sanity Studio using a familiar pattern: yourwebsite.com/admin, which means less context-switching. Studio allows you to set up Workspaces, which are deeply customizable environments, to organize content by team, product area, region, readiness, or however works best for your team.
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.
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.
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--
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."
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.
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.
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?
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?
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.
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.
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.
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.
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.
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"?
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.
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"?
Yeah, I think that kind of widening gap just at the highest level is what that talk is complaining about.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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]
[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]
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?
Ryan: Where to start... Where to start... [Laughter]
Each of your kind of browser tabs cannot access each other. They cannot read your browser cache and look at your credit card information.
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]
Ryan: Yeah. I don't think they can do that. I mean a lot of these--
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.
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.
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.
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.
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.
Ryan: You have that wrong.
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?
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.
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.
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?
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?
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.
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.
Chris: Ooh... That's some galaxy brain stuff. I'm not ready for it. [Laughter]
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.
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.
Ryan: No. Node is V8. Deno is also V8.
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: 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?
Ryan: Deno is built on Rust and V8.
Dave: Rust? Okay.
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.
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.
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.
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.
Yeah, Deno Deploy is handling many hundreds of millions of requests per day and is--
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.
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.
Dave: Baddabing-baddaboom, baby.
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....
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, 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.
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]
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.