Today, Charles, Dan, AJ, and Steve dive into a range of fascinating discussions. Joining this episode is special guest, Ryan Dahl, the visionary creator behind Node.js and Deno.

In this episode, they traverse an eclectic mix of topics, from humorous offbeat news and dad jokes to in-depth tech discussions. They explore the complexities and legalities surrounding free speech, offering diverse perspectives on its implications in the modern digital landscape.

But the heart of our discussion is Ryan Dahl's exploration of Deno 2, the latest evolution in JavaScript's runtime environment. You'll hear about its distinctive features, including the revolutionary JSR project, and how it aims to simplify and secure modern JavaScript development, addressing challenges and limitations found in Node.js. They also discuss the intricacies of TypeScript support, Deno’s security model, and the future potential of JavaScript in data science.

Join them for a lively conversation packed with insights, technical deep-dives, and plenty of humor. Whether you're a seasoned developer or just starting your coding journey, this episode is sure to offer valuable takeaways and an entertaining ride through the world of modern web development.

Socials

Picks

Charles Max Wood [00:00:05]:
Hey, folks. Welcome back to another episode of the JavaScript Jabber podcast. This week on our panel, we have Dan Shappir.

Dan Shappir [00:00:13]:
Hey. From a hot Tel Aviv.

Charles Max Wood [00:00:16]:
AJ O'Neil.

AJ O'Neil [00:00:17]:
Yo yo yo coming at you live from a blistering Utah.

Charles Max Wood [00:00:24]:
Steve Edwards?

Steve Edwards [00:00:26]:
Yo. Just one yo for me coming from a formerly warm but now cooling down Portland.

Charles Max Wood [00:00:32]:
Yeah. I was just outside, AJ. It's not terribly hot yet. It's gonna be hot this afternoon. Yeah. But, yeah, I'm also in Utah. I'm Charles Max Wood. We're talking to Ryan Dahl this week and Ryan.

Charles Max Wood [00:00:47]:
I'm just gonna do a little bit of an intro and then you can tell me all the cool stuff that you've done that I don't mention. But, you're largely credited with creating no JS. I know other people have been involved in that and you've moved on to also then create Dino. I think those are the kind of the big things that you're known for. Are there other things that people ought to be aware of other than that you're a cool guy?

Ryan Dahl [00:01:16]:
No.

Dan Shappir [00:01:16]:
Those,

Ryan Dahl [00:01:17]:
I think those are the the flagship, things that that I've done. Yep.

Charles Max Wood [00:01:23]:
Awesome. So, I'm I'm just gonna jump in. We're we're kinda doing this. We usually record on Mondays, and we're doing this out of band just so we could get you in and and let people know about what's going on here. So Dino 2 is coming out, and I think that's kinda where we wanna start. And, you know, you you sent us some material, but I kinda like to just let you explain some of this. You had Dino and, you know, dino's been out for a while, and I I know some people are using it and then and enjoying using it. But why did you need a dino too? Like, were were there were there things that you weren't able to do in dino 1 that you needed to do, or is it just, like, faster, better? And I I don't know.

Ryan Dahl [00:02:13]:
Yeah. I I I mean, first, there there is Node, and I I think, you know, the the idea that, JavaScript is this language that everybody knows and it's got a really great VM, via Chrome, this this v eight VM. And, JavaScript is is, you know, Node Node was essentially ideating on how you could take this client side programming language and attach it to servers and the fact that when you click on a button and get a callback, it's pretty similar to a web server getting a request and getting a callback and that event driven programming, is actually a pretty optimal way to to structure servers. And and, node, I guess it goes without saying these days, is is is pretty popular. So I I that project, you know, it's be used by, I I don't know, essentially every website. Right? Like, I'm I'm certain, we're recording this on streamyard.com. Probably probably uses Node in in some form or another. Almost all websites do it.

Ryan Dahl [00:03:26]:
It is, in in some some ways the cornerstone of of the Internet, and, that is largely because JavaScript is the default programming language and and so important. It is it is not like Java. It is not like c. It is, kind of intrinsic to humanity because so much of the world has been built on top of web browsers. Right? You access your library through the web browser. You access your bank through the web browser. And this infrastructure is not going to change anytime soon. It's, it's future proof in a certain way.

Ryan Dahl [00:04:01]:
Like, I'm pretty sure we'll be using hdp and CSS 5 years from now, if not 10 or 20 years from now. And, CSS and and, HTTP are not dissimilar to JavaScript. They are protocols that make up the web. And so JavaScript is kind of future proof in in this in this way, and, that's that is really the reason that Node has grown so big. I mean, Node was, you know, I think I did a pretty good job, attaching a web server to to JavaScript, but, you know, ultimately, it's it's kind of the growth of JavaScript that that drove Node's success. But, you know, Node has,

Dan Shappir [00:04:42]:
Before can if I can interrupt because I have to ask about this before you move on to what came after Node. So you you basically stated here, like, 2 big motivations for the creation of of Node. And I'm kind of curious if they if any one of these 2 was the primary one when you when you, like, envision initially envisioned it. 1 was, as you said, using JavaScript, which is the cornerstone of the web on the server side. The other being the event model and and, you know, the event loop and and all this mechanism, and which, as you said, turned out to be such a great match for, for the server side. Like, a lot of people initially didn't expect that, and you had the the foresight to see that, that it that it is such a great match. So I'm curious as to which one of these 2 was the primary motivation or were they, like, equal?

Ryan Dahl [00:05:50]:
It was the realization that those two complement each other that that was the creation of Node. So a little bit before Node, like, you know, let's let's say 2,008, 2,007, I was working on NGINX modules. NGINX is a is a kind of native web server that is written in c and is event driven. And at the time, driving event loops was kind of a unknown subject. Like, you you had to be a real expert. You had to really know what you were doing to to kinda drive EPOL in 2008. And I was aware that this was kind of the optimal way to drive web servers, as opposed to starting a thread per request. And I was, you know, enthralled by this this this thing and looking for ways to make this easier and bring this to a larger audience of of programmers.

Ryan Dahl [00:06:46]:
It was it was, like, literally, like, a 100 people who who knew about this and maybe maybe a bit more than that, but, like, you just had to be this, like, like an expert and and, part of some subculture to to to build an event driven web server. And I was looking at different programming languages, originally Ruby, looking at Haskell for a little bit, looking at ways to to kind of bind, to drive web servers in an event driven way and and in a, you know, backed by epol on on Linux, and inspired a lot by twisted Python and event machine in in Ruby. And the problem I you know, looking at those things deeply, found that the the big problem with those systems was that they interacted really poorly with the rest of the standard library. So if if you take, say, event machine in in Ruby, you realize that there's all sorts of blocking operations elsewhere in the Ruby stack. And and if you take kind of non blocking stuff and blocking stuff and just try to merge them all together, like, you just it ends in disaster because the the trick with with event driven web servers is you could never block the event loop. That's the that's the, you know, the the principal thing that that you have to do. And so you have to really build the system from the ground up to be non blocking and event driven. And, I I have the insight, you know, maybe maybe the the singular insight in my life, that, oh my god, JavaScript, it offers the the opportunity because there is no defined standard library.

Ryan Dahl [00:08:22]:
There's no defined way of interacting with the operating system in 2 2008. There was no server side JavaScript. This this offers kind of a clean clean, landscape for for me to build up a pure event driven web server and all of the associated, libraries that you need to do that. So if you're making, say, an outbound, TCP connection, you also have to drive that in a non blocking way. Or if you're doing a time out, you also need to you you cannot block the event loop when you sleep for for a couple of seconds. Right? All of this needs to be event driven. And, yeah. So this just works magically with JavaScript and makes all of this much more accessible to people.

Ryan Dahl [00:09:07]:
So, you know, I think the the broad, bent of what I'm trying to do is is make and I think this continues through dino 1 and dino 2, is trying to make programming accessible to people and and allowing them to to program, pretty deep, important infrastructure, you know, driving event driven web servers and and whatnot, with just a few lines of code and and, you know, without necessarily understanding what is happening, at the lower layers with with EPOL and and everything else that's going on. I think most node users have no idea about any of those those things, and that's great. It's a it's a clean abstraction.

Charles Max Wood [00:09:50]:
So I I guess what I'm wondering then is so so you popped the hood on d no one, and you said, we're gonna change out some of this stuff. Right? We're gonna we're gonna add some new features to the to the engine or, I don't know. This metaphor is gonna get real weird in a minute, I guess. But but but you so so what I'm wondering is is, you know, what what's different between dino 1 and dino 2 that get you to this thing that you're trying to create?

Ryan Dahl [00:10:19]:
Yeah. So, okay. Let me let me take a little step step back and and just, introduce dino Deno a bit. So, around 2019 or so, I I I've been working on other stuff. I I haven't been working on Node and kinda came back to to Node, and was starting to look at it deeply, and was really kind of disappointed about how I found the state of of Node. Obviously, I follow it, like, know that it's growing, but, you know, it did not feel like the clean, simple abstraction that that I was going for. You know, when you when you start adding all of these npm dependencies, you have, like, a 2 gigabyte node modules folder. You there there's there's common JS everywhere.

Ryan Dahl [00:11:03]:
There's ECMAScript modules. The the HTTP client in Node is different than the HEP client in web browsers. It was just this kerfuffle that, you know, really, disappointed me because this this is getting away from the goal of of, like, you don't need to know what's going on. You can just sit down and start programming. Right? JavaScript is for the children. Like, it it should be should be easy for people to to just, start getting programming, start getting going. Also on top of all of this, TypeScript was very clearly becoming a thing, and integrating TypeScript into your node project required all of this setup and configuration files and and builds, and it's just, it starts making it, not very nice to program in. And so I started Deno with with the idea to to clean up a lot of this stuff with a with a kind of from the ground up, runtime implementation, not in c plus plus like I did with Node, but, in Rust, a new new, new language, And really focus on making a TypeScript first, narrowing the gap between server side JavaScript and web browser JavaScript, really using web standards, making it ECMAScript module first.

Ryan Dahl [00:12:17]:
Making it batteries included, that is in in having kind of a tool full tool chain of of programming utilities that you need because, you know, it's not just the execution of JavaScript. You also need code formatting and linting, and you need an LSP to to connect to your editor. The list goes on and on. Like, you really need a full tool chain of of things. And, you know, in in my mind, that is the runtime's obligation to to provide those things. I really like how Go, does things. It's it is a all you need is is Go, and and, it it it gives you everything that that you need to get started. On top of all of this, the

Dan Shappir [00:12:55]:
If I can interject again, and I apologize for interrupting you, it seems that based said what you're saying is that you had this great idea, but in a certain certain ways, it was kind of ahead of its time. You you basically invented and created a lot of the ecosystem. And as the ecosystem evolved and matured and introduced by 4 certain pieces that were missing at the time, like, you know, ECMAScript models who just weren't available when you created notes. So you kind of had to invent common JS to to create this module system. So and and in a sense, you were kind of stuck with those inventions that you created even though over time, a lot of them turned out to be less than ideal. Is that a proper way of saying it? And, like, node can't change for the same reason that browsers can't change. I mean, a lot of us would be happy to go back maybe and change a lot of the various DOM APIs, but it's impossible because backward compatibility trumps everything else. You can't break the web.

Dan Shappir [00:14:13]:
And, likewise, you can't break the 1,000,000 applications that currently run on node. But the big difference is that on the front end, you know, the browsers are what they are. On the back end, you have the option of using maybe something else instead of node. You're not breaking compatibility if you decide to use something else. So is is does that kind of paint the picture of why you kind of instigated, Dino as like your your a certain a chance for redo or retry, something like along these lines of, hey. I now have promises. I can do a wait, stuff like that.

Ryan Dahl [00:14:54]:
I I I think of it in terms of, like, scaling limits. Like, Node just kind of reached this scale that, like, the the Node has this kind of small core philosophy. Like, the the philosophy of Node, you know, just kinda started breaking down at at at a certain scale. And I you know, it's unfair to say it's breaking down. I mean, like, Node is is the cornerstone of the Internet. Right? I mean, it's it's it's totally fine, but I I think there is is still an opportunity there JavaScript is going to last many years from now. We are not at the end state, and like Node in 2019, I think it's unfair to look at it and say, like, this is it. This is JavaScript for the rest of of time.

Ryan Dahl [00:15:36]:
Like, that is not the case. JavaScript is going to last many, many years in the future. In some ways, we're just at the beginning, and I think it is incumbent on us if, you know, if you care about this, if you're working in this ecosystem to try to simplify it. And I think it can be simplified by addressing these problems at the runtime level. The comment about breaking changes is is important, and I I think that's that's one of the things with Deno 2 that that we are reevaluating. I mean, Deno Deno started out with with very much a incompatible API and setup to to Node. And we have found that to be problem you know, nice in in many ways, but but kinda problematic at scale.

Charles Max Wood [00:16:20]:
Yeah. I I read a bunch about, like, the the NPM compatibilities and, yeah, some of the node compatibilities and some of the things that we read leading into this. So how much of that is in Deno 2, and how much of that did you just wind up bolting into Deno 1 piece at a time?

Ryan Dahl [00:16:38]:
I mean, Deno Deno 2 is not like a a hard break or anything. It is just, more and more features kind of, evolved into into Deno Deno 1. So, yeah, I I guess that's an important point to make is is that, like, anybody who's who's written a Deno program, like, that is going to continue to work. There's no there's no breaking changes, so to speak, in in d n o 2. What has been happening over the last 2 years is is we started, maybe 18 months ago, kind of started node built in APIs, in in d node. The ability to import node colon f s, for example, and and be able to read files from from there. And also NPM support, the ability to to kind of pull in NPM packages, kind of in in in a nicer, more elegant way, we think, than than in Node where you kinda need a separate, package manager and and kind of install these things into Node modules. In in Deno, you can just reference npm modules.

Ryan Dahl [00:17:44]:
You can do imports, npm colon chalk or npm colon express, and it just kind of it just kinda works. Like, it it kinda,

Dan Shappir [00:17:52]:
Deno itself has a connection. I have to ask about this because I recall when Deno 1 came out. Well, it was just dino back then, not dino 1. When dino came out, one of the main selling points, and a lot of people kind of got all in the huff about it, was that it didn't actually have a package manager. It was as I recall, it was you want something, you just downloaded it from the web. It arrives over HTTP. It gets cached, so you don't need to download each and every time, but it works just like your browser. You don't need a package manager.

Dan Shappir [00:18:31]:
And now all of a sudden, turns out that you actually do need a package manager. So was your initial need a package manager. Okay.

Technical Interjector [00:18:41]:
Correct me.

Ryan Dahl [00:18:45]:
Yeah. We we started with a so we started with ECMAScript modules. The the theory being ECMAScript modules is the real module system, not common JS, and that future JavaScript should be built on top of, ESM. And ESM the real? It is the real. I mean, it is it is, literally specified in in

Charles Max Wood [00:19:05]:
Oh, yeah. I I guess to that degree. Yeah. Yeah.

Ryan Dahl [00:19:09]:
And yeah. It's real in the sense that browsers, you cannot require in a browser, but you can import in a browser. And, you can import, HEP mod, specifiers. You can import, HEP colon / blah blah blah, and kinda link link to a a, JavaScript file, in a browser. So it is it is that is the real module system in in JavaScript. And so our our thinking was, let's expose this to server side JavaScript, and maybe this is sufficient for maybe this is all you need. Maybe maybe a cheat maybe maybe links is is all you need. And we went pretty far with this.

Ryan Dahl [00:19:51]:
Our idea was, like, if we build enough tooling around this and make this, ergonomic enough, that we could have kind of a decentralized module system where anybody can post code on any website and you can just link it into your your projects. It's pretty great. It's pretty great for small scripts.

AJ O'Neil [00:20:10]:
Why not Git? This is because it seemed like Go had solved this problem better than anyone else has ever solved it. And I think that Go modules had already existed by the time that Deno came out. So why

Ryan Dahl [00:20:23]:
inspired by Go.

AJ O'Neil [00:20:25]:
Yeah. Why not that's because it it I the talk I watched, it sounded like mathematically, from a graph perspective, the Go system is literally perfect. You cannot get better. You can get worse. You can make worse trade offs, but you can't make better trade offs.

Ryan Dahl [00:20:42]:
We again, we stick to the standards, so there is not a way to import a a, git repository in the web browser. And so we were reluctant to add something that that is not, something that works in the browser because, you know, the the axiom that that we have is that we wanna narrow the gap between server side JavaScript and browser JavaScript as much as possible. We wanna have the same APIs. We don't wanna have the same module system. And, yeah, you could you can add that on there. But I think our original take with with Dino was let's just stick to HEP specifiers and see how far we can get with that. That makes sense. Yeah.

Ryan Dahl [00:21:25]:
I I think we we essentially have the answer now, a couple years later, which is that it works for small scripts. It works really, really great if you're just scripting, you know, hacking together a little build script or or a little, you know, file manipulation tool or or something. You have a single file. You can kind of throw in some HTTPS imports at the top. You can kind of publish these things. It doesn't work so well when you start, having larger projects, multiple files, multiple packages. You're you're kind of having these URLs kind of strewn all over your code base. They they don't of course, a version string can be embedded in a URL, but without a real kind of semantic understanding of of what versions of modules you have.

Ryan Dahl [00:22:11]:
You have a lot of duplicated dependencies. You might have essentially the same, dependency with, like, a slightly different patch version, slightly different URL kind of in your dependency tree.

AJ O'Neil [00:22:24]:
Why not attack that at the standards body level? Because that seems that seems like a problem that is universal enough that has existed since the dawn of UNIX, I think. I mean, version numbers have been around, I think, since, certainly, since people have had computers in their home. So why why don't we have a standard at the at the web level or, you know, attack that with one of those with the one of those standard bodies?

Ryan Dahl [00:22:52]:
I mean, there there is essentially a standard for versions now, SemVer. And, we do participate in in the standard bodies, but, standard bodies are also very, very slow moving, and are are not necessarily something that you can. You don't want to standardize first and then implement. Like, we're we are we are trying to build, software for humans here and and, like, actually actually solve problems. And and so, you know, only work in the standards body is, I you know, attended TC 39 a couple of times. I have to tell you it's the the most boring thing I have ever done in my entire life. I just wanna it's it's like the I I'm trying to ship software that people can actually use. So, yes, we do, you know, Deno is a member of of TC 39, and we do interact with standards bodies, and we do try to make JavaScript better in in that sense.

Ryan Dahl [00:23:42]:
But, there's there's a pretty big gap between standards and implementation that that, allows for a lot of creativity.

Charles Max Wood [00:23:50]:
I have some paint drying that you can watch. I I kinda wanna go back to the imports, because you were talking about, yeah, pulling in through a HTTP and you, you know, you get the the library or whatever you need right, and it it loads it in and, you know, hopefully, it's all set up properly for the module import. It what what's changed. Right? I mean, I I've read the blog post about HTTP imports, and I think that's where you're headed here. So, you know, I I don't know if you had something to finish on that thought, and then, yeah, where are you going? Because it's pretty gratifying to see import maps in there.

Ryan Dahl [00:24:30]:
What what's what's changed is is that, it just like, first of all, it doesn't work at scale. Like, versions are a problem. We have the problem of servers going down. So if you have some dependency that has some other dependency that is hosted on, you know, a personal home server and that server goes away, then, like, the the all the the transitive dependent, dependence of of that, program of that module, die along with the server. So there's a reliability problem. But I I think the overarching problem is that, when you're dealing in in kind of bigger projects, you have problems like, hey. I need to use the AWS SDK. Like, I need to talk to s 3 or whatever.

Ryan Dahl [00:25:13]:
And we really don't wanna be in a situation where you need to rewrite all of this software for Deno, and that that gets very problematic at at scale. Right? I need to use, gRPC. Right? Like, we I I we we we cannot rewrite the world, given all all that has been done in in JavaScript. So this And

AJ O'Neil [00:25:37]:
This is actually one of my big questions because it seems like node fills a niche, and it's really imperfect, but it's you know, that that niche is full. And there's, you know, there's there's Deno and there's BUN, and and, I I think there might have been another project that maybe has already burned out. But, you know, there's there's these projects that have major advantages over Node, but they're an incremental improvement. Node was a big bang, and the the future advancements are like just another galaxy. Right? So when you look at the ecosystem, I was actually really excited back when Deno was heartbreak because I thought, great. This is a chance for us to get quality software that's been thoughtfully written that's not just everybody who's ever touched a computer throwing something up on NPM. Because the stuff that's on NPM, 99% of it is garbage, and there's, like, that small, small percentage. And that and that's just, like, that's just a Pareto distribution.

AJ O'Neil [00:26:47]:
I'm not I'm not, like, trying to throw out a disk there. Like, most of the information in the world is wrong. Most of the you know, most of anything is gonna trend towards the less useful and the honed, the specific, the skilled. You know, like, most athletes aren't Olympians. You know? So I like, for me, the idea that we were gonna have a clean break from Node and we were gonna be rebuilding the core pieces just clean was super exciting. And these seem to be in juxtaposition. You're saying, well, we need to rewrite the engine, but, actually, we don't need to rewrite the libraries. Where does that how how does how do those reconcile? Or why is why is that okay?

Ryan Dahl [00:27:28]:
We we added NPM support and and node built in support, to be able to pull in modules, including ones that use common JS and and, development patterns that we consider to be antiquated or or deprecated. And there is, unfortunately, an enormous amount of complexity to be able to support common JS in in an ECMA script only only world. But that doesn't change kind of the the overall philosophy of Deno, which is to level up JavaScript. We don't allow our users to say use require or to, do kind of poor development practices. We we were really encouraging people to, level up JavaScript. But, being able to pull in, gRPC from from NPM is absolutely necessary when you need gRPC because gRPC is is freaking complicated and, like, nobody's going to rewrite that. So in a sense, like, a hard break is kinda nice until you realize that, like, there's a lot a lot a lot a lot of infrastructure out there. The way that we can encourage people to, have better development practices, to write clean code, is what we're doing on on JSR, which is a a new open source registry, that is kind of a superset of NPM.

Ryan Dahl [00:28:51]:
Like, you can depend on NPM modules in in JSR, but, we have something called the the JSR score, where you get a higher score if you follow better development practices. So it it kinda allows people to to publish trashy code, and I agree with you. There's kind of a power law distribution in terms of quality of of anything, and there is going to be a ton of crap out there. So So there's a ton of of packages on JSR that are going to have, like, a 0 JSR score, but we tell you how to improve this. Add JS docs to to to your exports, use typescript, use, you know, various things to to, kind of encourage people to to up the quality of of their the code that they're distributing. And, yeah, I I I think this is I think this is the right tactic. Like, we we we need to have kind of stepping stones into the future. Again, JavaScript is going to be here for many, many years, and the, you know, Node.

Ryan Dahl [00:29:55]:
Js of 2019 is not the end state. Like, I I just I firmly believe that because because there's just too much economic pressure to make JavaScript better. So we need we need kind of, ways to incrementally improve this. And as as we were saying before, Node has all sorts of dependencies on existing software. It's very hard to fundamentally change how Node operates. It's effectively impossible. You can kinda tack on, different things here and there, but you really need a project like Deno to to, kind of fundamentally think think about these things differently. But that you know, it's it's it's not a kind of binary story.

Ryan Dahl [00:30:37]:
Like, we we do we have realized that we need to be able to pull in NPM modules and be able to use, say, gRPC or the AWS SDK. Otherwise, people can't really develop real software in in this thing. And, again, we are we are not doing this as an academic exercise. We are trying to write software for real people.

Dan Shappir [00:30:58]:
So you said something you said something that was really interesting to me. You you said that, effectively, you can pull any existing NPM module, which obviously uses which was obviously written or developed for node, which means it uses node practices, node structures, node APIs, etcetera. But when I'm developing in Deno, I'm intentionally restricted to the Deno way, which is the better way.

Ryan Dahl [00:31:32]:
Yeah. I I wouldn't call it the modern JavaScript way. Like, we we just encourage better best practices. Yeah.

AJ O'Neil [00:31:39]:
Because it's standards.

Technical Interjector [00:31:41]:
Yeah.

AJ O'Neil [00:31:41]:
It's standard. It's not Deno.

Ryan Dahl [00:31:43]:
Yeah. So we're basically well,

Dan Shappir [00:31:44]:
it's it's kinda more than standards, and I'll touch on that in a second because there are certain things in Deno that I wish were part of the standard, like the I wish that the Deno, quote, unquote, standard library was the JavaScript standard library. And I'm if like, my biggest complaint against the JavaScript language as it is is that it's really lacking a standard library. And I would have loved for the Deno standard library to be the the the germ or the root of of that of such a standard library. But going back to my my previous question or point was that I didn't, is is a point that I didn't understand or know before was is the fact that effectively your you've created, like, 2 kind of distinct, runtime environments with under one hood. There's, like, the dirty scruffy environment that you need to support for the existing node modules, and there's the cleaner, nicer environment where you write your own code. So you you can The node modules that you import can do things that you can't intentionally

Ryan Dahl [00:33:03]:
That's right. Yes.

Dan Shappir [00:33:04]:
Do. That that's really interesting and something that I didn't realize.

Ryan Dahl [00:33:09]:
So for example, the node modules that you import might use common JS, of course, but they might also have, like, a process global. Process global is not a web standard, so we we avoid having, the process global in in Deno. So in in your kind of top level script that you're writing, although you might pull in express, which might very well call, process env, the the top level scripts will not be able to call process env without a an explicit node colon process import if you're following.

Dan Shappir [00:33:45]:
So you've created a sort of node virtualization environment within d know, and you're effectively running the node NPM modules within that, again, quote, unquote, node virtualization environment, sorta.

Ryan Dahl [00:33:59]:
Yeah. I mean, virtualization environment is, suggests that it's, yeah, suggests that it's virtualized in in some sense. So I wouldn't call it that, but, there there is, yeah. There's there's all sorts of of kind of trickery that that we do to to make this, kind of hidden from the user.

Dan Shappir [00:34:21]:
And how compact how compatible is it? I mean, what level of compatibility were you able to achieve? I mean, it can't can't have been easy. Let's put it this way.

Ryan Dahl [00:34:30]:
It it it's it was not easy. It took us a very long time, a lot of lot of engineering effort. The level of compatibility is fantastic. It's it's very good. We've been working on this, like I said, for for about 2 years now. There's always going to be a long tail of incompatibilities, and and we consider any module that we can't run a bug and and we will fix it. But it's really, really good these days. So Deno can even import node modules that have extension modules to them, like compiled extension modules that use nAPI, for example.

Ryan Dahl [00:35:05]:
So so Deno implements all of the an API binding layers. It's it it goes very deep, and, it's it's you know, our our goal is is, you know, let's let's call it 4 nines of compatibility or something like that. There there's always going to be a tale of incompatibility, but, but it yeah. Like, essentially, anything that you pull in, should work out of the box and and Yeah. You know, these days.

Dan Shappir [00:35:30]:
The the big the big problem with projects like that from my own experience is that, like you said, like, everybody uses this, like, 90 something percent of the modules that people use are essentially the same models. Like, there are certain small subset of modules that are the most popular by far. But the problem is that a lot of organizations use another module in addition to that. So the question always is, am I not going to find myself stuck because some weird module that some developer that worked here 5 years ago imported and I'm dependent on and it does something really, really out there and and the environment has a problem with it.

Ryan Dahl [00:36:17]:
I mean, it's it's it's always possible, but, the the compatibility layer happens at kind of the node API boundary. Right? Node has all of these built in modules like FS API. And Deno implements these very, very deeply and well. And so I would expect even random side modules are going to work. But like I said, there's a there's a long tail and and there will be incompatibilities. But, yeah, I I would encourage people to try it. You will be shocked. You you can import essentially anything.

Ryan Dahl [00:36:52]:
You can take Next JS, and, you know, create Next JS app and do, Deno run dev in in there and and this will this this works. Right? So Deno can can, take any package JSON node first project and run this natively in in Deno as well.

Dan Shappir [00:37:11]:
And the other question that I have is, again, one of the, one of the, defining aspects of Deno when it came out was the security and the sandbox model. The fact that you you're you're sandbox by default and you open up search certain aspects, and you only open up those aspects that you actually need. Well, again, my question then becomes, do you run into issues with that when you're using arbitrary node modules that have no concept of this security sandbox? And and if so, how do you deal with it?

Ryan Dahl [00:37:50]:
Yeah. So I haven't haven't mentioned that, but that that is indeed one of the kind of flagship things that that we were trying to do with Deno is, like the web browser and and, you know, this goal of of kind of narrowing the gap between server side JavaScript and and browser JavaScript. Browser JavaScript is super secure. Right? You're running untrusted code day in and day out in every single tab, and the v eight VM provides a super secure sandbox for this. And, in Node, you know, we were more interested, in in what we could do, rather than thinking too much about whether we should be doing it. No. We we, we we just I I wasn't thinking about security back then. I was thinking more about

Dan Shappir [00:38:33]:
You were about breaking barriers. Let's put it this way.

Ryan Dahl [00:38:36]:
Exactly. Yes. And I I think, you know, now with with, with some years to to think back on that, I I think being able to utilize the secure sandbox that v eight provides is it should be it should be mentioned. V eight is the is the the real workhorse here behind Deno and Node. And in some ways, you can think of Deno and Node as kind of, you know, if if v eight is the Linux kernel, then then, Node and Deno are kind of like 2 Linux distributions. Right? Two different distributions of of v eight. Anyway, we we we in Deno, we do use the security of the v eight VM. And by default, when you run a program, whether it has NPM modules or not, you have zero access to the system.

Ryan Dahl [00:39:23]:
You cannot make network connections. You cannot read from the file system. You cannot see environment variables. It doesn't matter if your NPM dependencies or dependencies of dependencies call process m, whatever. All of that is gated in Deno. Because, again, we've reimplemented all of this, and and so that extends to the NPM modules. And and you are able to gate access at a pretty fine grain layer, in the user space at at the v eight level, and and kind of say say whether, whether things are are able to access, say, the file system or if if they're if they're able to make outbound network connections or listen on a socket. All of that is controllable and it does extend to the compatibility layer.

Ryan Dahl [00:40:08]:
It's a very nice aspect of of the system. You you kind of have to provide a few more flags and it's a little slightly less ergonomic because, like, yeah, in many cases you do want to turn off the sandbox. Right? If if you're running, you know, if you're writing a script, like, probably it's probably going to interact with the file system. It's probably going to interact with with the network. But, you know, there are many cases where maybe you're just writing a proxy server and you really don't need access to the file system at all. It's very nice to have that at your fingertips and be able to gate at that access.

Dan Shappir [00:40:39]:
The the cool thing about it though is so what what I'm understanding from you is you can start fully sandboxed, open whatever features you know you need, then start using the various node modules. And then if something breaks because of security, because of the sandbox, and I assume that there's the appropriate notification for that so you are aware that, you know, this module tried to do something that it's not allowed to do, you can then decide whether or not, you know, you actually need that module and are willing to grant that security aspect to it. And and conversely, you might ask yourself, hey, why is module that's supposed to be doing networking want access to my file system? You know, maybe I should be more suspicious about what it's actually doing.

Ryan Dahl [00:41:38]:
How how do you guys feel about a screen share? I guess this is a podcast, so probably

Dan Shappir [00:41:42]:
Oh, you can screen share for the the for we can do a quick screen share, but, you know, our listeners obviously are losing out.

Technical Interjector [00:41:49]:
I'll

AJ O'Neil [00:41:49]:
do descriptive reading.

Ryan Dahl [00:41:52]:
Let let let me see if this works. Well well, let me see. Can I share a window? Yes. Let me just pull up a terminal here.

Charles Max Wood [00:42:02]:
AJ, I want descriptive singing.

Ryan Dahl [00:42:05]:
Can you see this?

AJ O'Neil [00:42:07]:
I'm listening along at home. We can't see anything yet, but now it's a terminal.

Steve Edwards [00:42:11]:
Chuck, be careful what you ask for.

Charles Max Wood [00:42:14]:
Right.

Ryan Dahl [00:42:15]:
So let let me just, whatever, test dotts, and and let me just just show

AJ O'Neil [00:42:20]:
you what Vim, by the way, not Neovim like a noob for those listening.

Ryan Dahl [00:42:25]:
This is this is actually Neovim. But whatever. I'm not.

Steve Edwards [00:42:31]:
Yeah. The the NVM at the top was a dead giveaway.

AJ O'Neil [00:42:35]:
His alias did his BIM, like a professional, not like a noob, by the way.

Ryan Dahl [00:42:40]:
Let let's say we wanted to make so I'm I'm console logging hello, and let's just say I want to, like, make the background color red. Okay? And and I think how you do this in node, you often use the chalk library. So you can import chalk from and in Deno, you just do chalk. Okay? And then you can say something like chalk dot

Dan Shappir [00:43:01]:
So it's npm colon chalk to tell it that it's it's an NPM module.

Ryan Dahl [00:43:06]:
That's that's right. So you can do something something like this. Hopefully, this works. So, deno test. And what you see here is that it says, Deno request environment access to force color. Chalk is reading environment variables. And so I can I can say, like I like this? No, and deny that. No, you can't read that.

Ryan Dahl [00:43:28]:
No, you can't read that. No, you can't read that. You can't read that. Can't read that. And it logs it, not in color. Let let me let me try this again with, allow m, or just dash e to allow environment variables. And now Chalk has has operated correctly. So yeah.

Ryan Dahl [00:43:49]:
I I mean, a really simple demo, of course, but it it's, Chalk was not built for security sandboxes. Like, it knows nothing about this. But, you know, through through our compatibility layer, we are gating access to the environment variables. And maybe you didn't know that Chalk was was actually accessing those things, and and you decide that, like, hey. Actually, I don't wanna use Chalk. I don't wanna expose my environment variables. Let me do kind of the Deno first way of doing this, and in fact, the web standard way by putting a a, you know, percent, c there and and doing background color red, is actually the, you know, web standard e slash Deno first way of doing this. This is how you do it in the browser.

Ryan Dahl [00:44:32]:
And now you don't now you don't need any any control access. You can you can just, use use the CSS directly here. Are you following me?

AJ O'Neil [00:44:42]:
Yep. Yeah. For those of you that are listening along, you can actually pass a CSS style as a string the same way you would put it in HTML as a, an argument in console dot log Yeah. To fill in a percent c. So you can have a string with 3% c's, and then you can add 3 styles.

Dan Shappir [00:45:03]:
As I recall, you can also do the same thing in the browser dev console.

Ryan Dahl [00:45:08]:
Yeah. Yeah. This is a Yes. We we do not invent APIs. So this is not like a Dino Dino e thing to to do. We're we're,

Dan Shappir [00:45:15]:
Yeah. But but for those who are curious, the the same way that you can use colors in your console logs inside the browsers, work in Deno the exact same way. That's that's the the basic Yeah.

Ryan Dahl [00:45:28]:
But the I think the main main point there is is that, like, Chalk, does read environment variables. Probably knew but nobody knew that. But maybe you're sensitive to that. Maybe you have, secrets in your environment variables, and maybe you don't want to allow access to that. Chalk's a pretty simple example, but this kind of extends to any NPM module. And and so you can kind of see what these NPM modules are doing and and decide, specifically if you want to allow access to that. So, yes, the security sandbox is is still, you know, a primary thing in, you know, and and we think pretty important.

Dan Shappir [00:46:02]:
What I really like about this is the fact that, you know, we've been in in the context of security, there's been a lot of talks about, the the problem the security issues when people, like, take control over existing projects and insert malware into them, kind of creating all sorts of supply chain issues. And and the Dino approach is a very interesting safeguard against that because if somebody introduces, malware into an existing package to do something that it isn't supposed to do, there's a good chance that the existing sandbox could prevent it from actually doing that. And all of a sudden, you'll get that error and the thing won't maybe won't work, but you haven't introduced a security vulnerability.

Ryan Dahl [00:46:51]:
Yeah. It gets it gets really problematic when it comes to, like, NPM post install scripts. Like, anytime you add a dependency, like, any dependencies of that dependency are going to run their post install script. You're you're essentially in in in node anytime you add a dependency, you are running untrusted code from random people on the Internet on your computer without any sort of sandbox. Like, it's very problematic.

AJ O'Neil [00:47:14]:
Plug plug for socket. I use socket because I don't I don't I don't want to be running untrusted code from random people on the Internet when I have client work and AWS keys and, you know Yeah. That sort of thing. I forget what their website is. It's socket.

Ryan Dahl [00:47:35]:
Dot dev.

AJ O'Neil [00:47:36]:
Yeah. Socket.dev. Yeah. Socket. And that that links in. They think they have GitHub actions that will link in on push to monitor your package JSON as well as, an alias for NPM so that it hooks into the NPM install and make sure that, malware doesn't run on your computer.

Dan Shappir [00:47:54]:
Yeah. And and we and we did that for us on our on our show a while back. We should probably have him on again.

Steve Edwards [00:47:59]:
Episode 155.

Charles Max Wood [00:48:02]:
I'm gonna change our direction just a little bit here, unless there's something else you wanna add, Ryan, before I do that.

Ryan Dahl [00:48:07]:
No. No. Cool.

Charles Max Wood [00:48:09]:
So so one of the other things that we're seeing come through is JSR. And, so I I wanted to talk about that for a bit too here. We've already been going for 50 minutes, and I wanna be mindful of your your time. But, yeah, it looks like an interesting project. Do you kinda wanna set the stage for what it is and why you even created it?

Ryan Dahl [00:48:31]:
Yeah. Like, post GitHub acquisition, npm is, like, not evolving at all, and No. You know, it's it's kind of the the central, place where you share JavaScript code. Like, this is pretty unfortunate. Like, JavaScript is is a very vibrant world with all sorts of changes happening. You know, we're moving to TypeScript. We're moving to ESM. And, like, the the the place where where everybody is sharing code has is effectively dead.

Ryan Dahl [00:49:00]:
There's all sorts of security problems as as, we were just discussing. It's just, it's not fun. Like, have you I I'm sure everybody here has published an npm module. You tried publishing, like, something that's written TypeScript? Have you dealt with, you know, common JS, ESM? Like, what what what sort of output do you have? How does the exports thing work? Like, it just gets really complicated, and, again, kinda gets gets away from this JavaScript being for the children. Like, this, this should be a toy like language. This is a scripting language. We are not programming in c plus plus. Like, it should be it should be fun and nice, and the registry could be supporting us so much more here.

Ryan Dahl [00:49:44]:
And as I said when we were discussing, h e p specifiers, you know, we kind of come come around to this this, realization that a centralized registry is actually very important for reliability. You Can't have things hosted on random servers. So we, we have created JSR. It is open source unlike the NPM registry. It is meant to be a community service and is is is, you know, managed by me right now effectively and the the Deno company, but but we we intended this to be a community service and open source and and community driven, and it is just delightful to use. If you if you have ever published to NPM, you you will you will immediately see the benefit. Like, you can just publish your typescript. It just works.

Ryan Dahl [00:50:32]:
It is really meant for a world in which there are multiple JavaScript runtimes. The node package manager is meant for a world in which there is node. But, in 2024, we've got Node, we've got Dena, we've got BUNT, we've got Cloud Player Workers, we've got, the browsers. Right? There's there's many different places where you're going to be running JavaScript and it's important for a registry to support all of those, targets that that you might be writing JavaScript for. It's very important for it to support TypeScript. And we've just got all sorts of, useful features in there that are attempting to level up JavaScript. And I I think I mentioned earlier the j s r score where, you know, we give you a kind of a point score for for your package, and it's probably going to start off with 0% because most stuff is crap. That's fine.

Ryan Dahl [00:51:25]:
But in order to get towards a 100% score on on your j s r, score, You have to implement things like, having a description for your package, making sure that, there's documentation for it.

Dan Shappir [00:51:40]:
Test coverage?

Ryan Dahl [00:51:42]:
Test coverage is not one of the is not one of the things that add, factors into the JSR score because it's really hard to, decide in general across multiple run times how what sort of test coverage you have. So one one

AJ O'Neil [00:51:58]:
thing oh, go ahead.

Ryan Dahl [00:52:02]:
Well, I I just wanna say, suffice it to say that that we put a lot of thought into into JSR. And, Yeah. I I I really think this is this is where we should be having the the vibrant sharing of code in in the future. It's it's it's delightful to use.

AJ O'Neil [00:52:19]:
So one thing that very much concerns me is that code should not be vibrant. Code should be dull and dead. Right? And most of these registries and all of them that I'm aware of kinda play off of the, you you know, the it's it's it's kind of like social media.

Dan Shappir [00:52:39]:
Game of

AJ O'Neil [00:52:39]:
the So the idea is to update and update and update. And so what ends up happening is that what's always on the home page are the mar the modules are the the are the most insecure, the least well engineered, have the most bugs, because they're the modules that are just always changing or or being written new and will never be finished. And then the code that is mature and stable, the code that you wish that you would find, ends up being at the bottom of the pile where you'll never find it. And then these modules that are just making constant changes are the ones that become popular, whereas the modules that are the diamonds in the rough that have 3 stars are the ones that are like, it's got full documentation. It's tight. It it it's simple code.

Dan Shappir [00:53:29]:
I'm not sure I agree, AJ. I mean, people are still using Express, and Express is not is, in fact, supposedly dead. So

AJ O'Neil [00:53:38]:
Well yeah. Okay. Once once a module has carved out a niche, that it's game over. Right? The the people are always gonna use that module forever. But I'm talking about the pattern of giving immature and buggy code priority because it's the code that's always being updated as opposed to stable code that works well. You know, do you are you a do you see that as a problem, and do you have a way to promote code that is stable over code that changes frequently or is new?

Ryan Dahl [00:54:16]:
I I I also kind of disagree with the premise. I mean, I I think, you know, in in some sense, the I agree with you that, like, people should strive to get their packages to a final state and that the code should be boring and not interesting. But, obviously, the techno the software stack of the of of humanity is growing, and new things need to be developed, and and they will need to be iterated on, and we need a place to share those things.

AJ O'Neil [00:54:49]:
Yes. I I agree with that. But for example, once you've implemented, a JSON parser, you're done. Now, thankfully, a JSON parser is so boring, it gets to be in the standard library. But there are many things where once you've implemented them, they are done. If you are publishing updates, that should reflect negatively upon the package score because you should not be publishing updates to something that can be complete and having projects

Ryan Dahl [00:55:20]:
where software. Right? Not everything is j o'clock.

AJ O'Neil [00:55:23]:
Syncing. Yes. But if you're kitchen syncing something, if you're building a framework where every week you're adding a new feature and another feature and another feature and another feature, then you're just creating kitchen sink bloat. Right?

Charles Max Wood [00:55:34]:
Maybe. Yeah. I mean, do you may have a tool that that's what people want. I mean, there there are systems. I mean, take Ruby on Rails, for example. A lot of people love working in it, and it kind of kitchen sink stuff, and they keep adding things to it that do more jobs. So, I mean, I

AJ O'Neil [00:55:52]:
sure the web standard is changing all the time. You probably don't want has to adapt to that.

Dan Shappir [00:55:58]:
You probably don't want the kitchen sink a logging library, and we saw where that leads when it when that happens. But you probably do want to kitchen sink something like a re like, Next JS maybe or or Ruby on Rails. It kinda depends on on where you are.

Charles Max Wood [00:56:13]:
I I'm There I'm just saying that curating this in that way is a huge job, and I don't it it doesn't sound like Ryan and the other folks at Deno are necessarily I mean, they see some of the problems, I'm sure, but I don't know if they're interested in solving that problem.

AJ O'Neil [00:56:31]:
I'm saying heuristically, not always favoring the things that are buggy and changing constantly. Having some, like yeah. Just not giving superpowers to the people that are just publishing weekly, and I'm sure so many company companies But are you are you suggesting that update hacking.

Ryan Dahl [00:56:49]:
Like, publishing should be hard so that, you you can't change it. Like, I I don't think things should be unnecessarily hard to No.

Technical Interjector [00:56:56]:
No. No.

AJ O'Neil [00:56:57]:
No. I'm I'm saying giving so for example, you go on your website, packages, recently updated, new.

Ryan Dahl [00:57:05]:
I

Technical Interjector [00:57:06]:
see. I don't

AJ O'Neil [00:57:07]:
want packages that are being updated all the time, and I probably don't want packages that are being new unless they're pretty close to completion.

Ryan Dahl [00:57:16]:
But I I don't I mean, that's just something for the home page. I don't think this is the primary mechanism for finding stuff. I I mean

Dan Shappir [00:57:23]:
What is the primary mechanism for finding stuff? Because it seems to me like for an NPM, the primary mechanism for finding stuff is Google. So

Ryan Dahl [00:57:32]:
Yeah. Yeah. And I I I think the same is is true for JSR. I mean, we do have a search there. I I wouldn't call it perfect yet. And the JSR score that I mentioned, which again encourages boring coding practices, like, you know, just have have some docs, you know, like, factors into the the search results. But, like, ultimately, like, a registry is going to have lots and lots of stuff on it, and you're not going to necessarily, like, find a list of all the things that are on the pack. Like, you can't have a list of all the things on npm and scroll through it and and find it.

Ryan Dahl [00:58:06]:
It doesn't matter whether it's search sorted by new or or not. You're going to find

AJ O'Neil [00:58:10]:
it in the word now. Search engine optimization. Right? Like, if you want to hack the system, you can just publish updates. You can just bump the minor version and basically do nothing, and it'll show up on the home page. Google ranks the NPM home page higher than it ranks other pages on the Internet. Right? So there is and you're publishing I'm sure you have whether it's a, like, a a an XML feed or whether it's, you know, some sort of JSON feed, but there's I assume there's something that you're publishing where you're probably putting out to search engines and whatnot and things that the things that are updated frequently are the things that are get gonna get the highest, I see. So

Ryan Dahl [00:58:51]:
Absolutely. I see. Benefit. It's a reasonable Over things that you're worried that the that the kind of new recently updated column on the JSR homepage, like, impacts the SEO of of, like, crappy packages. I mean, yeah. Okay. Sure. I I can

Dan Shappir [00:59:10]:
I would like to I'd like to pull us back to before we finish, I'd like to bring up another another another topic that you mentioned several times? And it's also interesting because Node recently did a change regarding that as well, which is TypeScript support. I mean, like, the big one of the one of the biggest things sorry, Chuck. You wanna say something? Well, I'm gonna

AJ O'Neil [00:59:31]:
ease in the type script in the same

Charles Max Wood [00:59:33]:
Well, I I wanted to just ask one other question about JSR here real quick.

Dan Shappir [00:59:37]:
Go for it.

Charles Max Wood [00:59:37]:
I mean, because because, you know, we were talking about the quality of the packages and things like that, but my question is is how do you use it. Right? Is it is it the import maps and the imports like we're talking about before? Is there a c l, con I was gonna say CLI, but a command line interface for those who aren't t l a, 3 letter acronym

Ryan Dahl [00:59:56]:
Yeah.

Charles Max Wood [00:59:57]:
Savvy? And is it only for publishing? Is it for pulling them into my prep? Yeah. How how does this all kinda hang together so that I can go, okay. JSR looks, to me, better in some cases than NPM.

Ryan Dahl [01:00:12]:
It's it is better than NPM in every in every situation. I I I guarantee you. It's it's fantastic. You can use this so if you're using Deno, it's it's like we have native support for JSR. So you can just do import jsr colon, your package just like you can do imports, npm colon your package. Right? It's it's a URL in the system. So Deno has native support for this and you can, of course, put JSR specifiers into your import maps and turn them into bare specifiers if if you know what those words mean. If you're using, node or a button, you can use, the n npm compatibility layer.

Ryan Dahl [01:00:56]:
Like, behind the scenes, all of these packages are actually exposed as an npm registry, npm.jsr.io, and you can, add them to your package JSON. So there is, really great docs on, on, JSR, and I'll I'll just drop you a link here. But, on on each of the package pages, you should be see, like, a little usage statement, and it will tell you the commands to run to add it to your to your package JSON. But, yeah. The the the the support gets really, really good when when it comes to Deno where where it all is is super smooth and and, requires no extra commands.

Charles Max Wood [01:01:38]:
Awesome. Yeah. I just put that into the comments on Facebook, YouTube, and Twitch as well so people can find it if you're watching there. And we'll we'll try and get it into the show notes as well. But yeah. That I mean, that that was what I wanted to know is, hey, it looks like a great experience. So yeah. And and this is ready now.

Charles Max Wood [01:01:56]:
Right? This isn't something you're announcing and saying, hey, try it in a couple weeks. It's out there.

Ryan Dahl [01:02:01]:
It's Right. It it's it's done done and done. No. We're we're still iterating on it, but I I think, it is, like, 99% done. Like, it's it's working. It's fantastic.

AJ O'Neil [01:02:11]:
Well, if I understood correctly, dino 2 is just an iteration. It's like dino 1.87, but at some point, you just need to go to 2. Right? Are there it sounds like there's a few milestones, but it's not That's

Ryan Dahl [01:02:23]:
right. Right.

AJ O'Neil [01:02:23]:
It's not a rewrite.

Ryan Dahl [01:02:26]:
It's not a rewrite. And and the main thing is is that this NPM support is is, really, you know, at 4 nines of completeness. It's, like, complete. You have this option of j s r available to you if if you want to have, the leveled up version of of npm. Yeah. I I think it's you know, there there's other aspects of this that we haven't gotten into, like the long term support. Deno is very stable at this point. We are not changing anything.

Ryan Dahl [01:02:58]:
We're introducing long term support in in Deno 2, and we also have workspaces, in in Deno 2. But that you know, it's kind of getting Deno 2 is about scaling up projects to to to, you know, relatively large code bases where, you know, I think Deno started with, like, really great for single files. And and, you know, we're what we're trying to do is is keep it keep Deno great for single files, but make sure that it scales up to to projects that, you know, have a 100000 lines of JavaScript in it. And that includes the NPM support, that includes n, JSR, that that means the long term support, and, workspaces all all kind of factor into this, like, scaling up of of, of Deno.

Dan Shappir [01:03:40]:
So I I would really like to sneak in 1 or maybe 2 things before we wrap up. Let's see if I if we manage it. So the one of them I started to mention was the types of support. Like, the as you said initially, you in a kind of similar way to how you recognized early on the the role that JavaScript could and should play on the server side, you realize early on that the the market was heading towards TypeScript. And in fact, like, I think the majority of of JavaScript code in the enterprise is actually TypeScript. And and you introduced, like, effect built in support, like, from the get go. Interestingly, now Node has just introduced a sort of support for TypeScript as well by effectively stripping out all of the type information, essentially treating it like comments and running what's left. Is that similar to what you do or do you do something different?

Ryan Dahl [01:04:48]:
It's similar to what we do. Yeah. When you run TypeScript in Deno, we a very nice attribute of of, TypeScript is that it's a super cheap operation to, transpile that into JavaScript. You don't really have to understand the types. You just strip them

Technical Interjector [01:05:03]:
out.

Ryan Dahl [01:05:04]:
And that's how Deno runs things. Deno also has the type checker, the TypeScript type checker in it. So if if you run Deno check, it will check your types. And the TypeScript is kind of fully baked in through the system, through the linter, through jsr. The, you know, Deno tries very hard to make it so you don't need to write any configuration files. No no tsconfig necessary. So the the TypeScript goes much deeper in in d n o, but, yeah, indeed, node is node is picking up on on, some of the features of of d n o.

Dan Shappir [01:05:42]:
So It's fair enough that's

Ryan Dahl [01:05:44]:
important in node.

Dan Shappir [01:05:46]:
So because you're effectively just stripping out the TypeScript, you really don't care about the TypeScript configuration because, I think it it was, Matteo, Colina, who you probably know, once said that TypeScript is not a language. It's a universe of languages because you could really specify what kind of language it is via your TS config. And there's certain and there's certainly truth in that. You can really modify the way the TypeScript as the language works. But as I guess that if you're just stripping out the types and effectively just ignoring them, then it all all boils down to the exact same thing.

Ryan Dahl [01:06:30]:
There's there's a bit to unpack there. So first of all, Deno does not just strip types. Deno understands the types deeply. Deno Deno has deep type script support in it, as does j s r. Like, this this typescript support goes goes very deep in the system. So much much more so than just stripping types. It's true that you can, configure TypeScript in different ways and and TypeScripts with different configuration the code bases with different configurations can, be incompatible with each other. We strongly believe that TypeScript should move to a single configuration, single language, world where you can actually distribute TypeScript as the primary code, not the TypeScript TypeScript JavaScript.

Ryan Dahl [01:07:19]:
And that is one of the main features of JSR. You literally write the TypeScript and distribute the TypeScript because we believe that run times like Deno and Node in in the future, will be able to understand that TypeScript directly. And so we we believe in in linking TypeScript together and having a single, configuration. And I think, a lot of people people might think that there's a world of possibilities and all of these possibilities there is a world of possibilities with TypeScript. You can you can set all sorts of things, but not all of those possibilities are equally ranked. Okay? There there is there is a good way to configure TypeScript, and Deno pushes you towards that configuration as is JSR, that part of the JSR score. So, we we encourage the default, best practices in in in TypeScript. And, we encourage, using TypeScript as as a primary language and distributing TypeScript and linking TypeScript to TypeScript and not introducing always this, compile step.

Ryan Dahl [01:08:24]:
I think this is unnecessary complication, because ultimately, the the code that people are writing is TypeScript, and and having this this kind of, intermediate compilation step and linking step is, it creates complications for people.

Dan Shappir [01:08:40]:
Yeah. But the compilation step also serves a certain purpose, I think, because at the end of the day, TypeScript is not about runtime type checking. It's about it's about development type type checking and compile time type checking. If you're taking away the compilation, you're also negating effectively the compile time type checking. You kind of want a certain middle step, don't you?

Ryan Dahl [01:09:06]:
No. Deno Deno has Deno check subcommands that that runs the the type checking. It's it's effectively like a a lint, right, on on your on your, so you'll you'll when you're developing, of course, you'll see this in your LSP. You'll see red squigglies and and the the TypeScript, TSC kind of running in the background. But also during, you know, when when you push to CI or whatever, you should also be running deno check, which which is, you know, effectively TSC and, check those types, and you should get errors if if those types are not correct. So, there's no compilation step. You're still just So

Dan Shappir [01:09:44]:
no compilation linking instead of compilation, basically, is what you're saying? You're you're not getting rid of a step, but you're replacing a compilation step with a linting step. Yes. So if I'm running a step anyway, what's the benefit of linting over linting and compilation? Why not do the compilation and

Ryan Dahl [01:10:08]:
end of time? Think think about what happens think about what happens when you write a typescript module and you distributed this this to NPM. Think about what you have to think about the the type stripping, and you need to build a build process to create JavaScript, and you need to think about the output of that. So you you need to generate some some code. Right? You need to run TSC and and create a disk folder and and have kind of the the typescript JavaScript outputted into that folder. You have to think about, you know, what flavor of JavaScript you have. That is all not abstracted away from you. Right? In in Deno, in JSR, that is completely gone. You do not think about that.

Ryan Dahl [01:10:51]:
You don't even know about that. If you're a user, all you are using is TypeScript. So, yes, in your CI script, you still have one line that says Deno check, and that effectively does your type checking for you. But there's a whole bunch of complication that is completely alleviated from you. And I think as a user, when you go to use JSR, you probably are not even aware of this, and the overall vibe that you get is just like, holy shit. I did not realize this could be so simple. Because you're you're not necessarily it's not going to be, like, kind of a conscious not not everybody's thinking about their disk folder and the distribution of of JavaScript all of the time. Right? This is this is effectively internal details that have been because npm is not evolving are exposed to users.

Ryan Dahl [01:11:35]:
And when you go to a system like JSR or Deno where where we kind of deal with TypeScript natively, The end effect, the vibe for for the everyday programmer is just holy shit. This is crazy simple. I didn't realize it could be this nice.

Dan Shappir [01:11:53]:
Cool. Makes sense. Now I don't know if we have time to touch on that, but my second question was about it seems that one place where DNO has been really successful compared to node and apparently more appropriate is in edge computing. Is that correct? I seem to recall that.

Charles Max Wood [01:12:12]:
Getting edgy.

Ryan Dahl [01:12:16]:
Deno is, node is bigger than Deno in every in every respect. So, you know, do you know

AJ O'Neil [01:12:22]:
what I'm saying? Processing time. No. The

Ryan Dahl [01:12:29]:
well, sorry. I I got the it reversed. Yes. That is correct. Yes. Do do you know do you know the company? I think what you're alluding to has an edge compute, commercial service called Deno Deploy and Deno sub hosting. And, yes, we we this is how we make money. We we we provide services around edge compute.

AJ O'Neil [01:12:51]:
Well, we've heard of other companies using Deno because of its, better performance characteristics that we've as we've interviewed other people. So I think that's where our our bias leans toward what we've heard from, like, you know, other people on the show and whatnot. Or is that

Ryan Dahl [01:13:06]:
Generally generally, performance is better in in, you know, it is, yeah, we spend a lot of time to to make make it great.

AJ O'Neil [01:13:18]:
What do you have this might be faux pas. Bun. What about Bun?

Ryan Dahl [01:13:24]:
Bun is, was there a joke there? Fun is is a reimplementation of Node, that is trying to outperform it. So I I think they've done some nice ergonomic moves. They're also kind of building the package manager in into the run time, which I agree with. I think that's that's a good step, and also taking on kind of this, TypeScript type stripping feature from from Deno. But, you know, basically have have the have the idea that, yeah, 20 2019 JavaScript is is the end state, and all we need to do is make this faster. And and I I fundamentally disagree with this. I think there there is really something to level up here and improve on. I I do not think we should continue to use common JS require indefinitely.

Ryan Dahl [01:14:20]:
So, you know, the I think, Bun in in many ways is is is, you know, trying to do, Deno, but but maybe learning from our mistakes. You know, they they very aptly are focusing on node compatibility. But, yeah, to what end? Why why rewrite node exactly? That that's that's always my question. I think rewriting Node in Rust yeah. I mean, I'm sure it's I'm sure it's fun. Ultimately, that's that's not what I'm trying to do here with with Deno is is rewrite Node in in Rust. We are trying to level up JavaScript and make this stuff fundamentally simpler for for developers. Performance wise, I find the the benchmarks that they have at the top, you know, above their fold on on their their websites, are not wrong, but they are cherry picked.

Ryan Dahl [01:15:14]:
The the the the performance situation with Deno is fantastic, and Deno outperforms Bun in all sorts of circumstances in many of the ways that matter more. For example, if you want to, you know, if you're running on AWS Lambda and you're concerned about your your primary concern is not necessarily about hello world throughput, which is the the benchmark that they have up on their page. But Agreed. It's a little unfair. Actually, it's it's it's very cherry picked. And I think, with a system, JavaScript run times are have all sorts of functionality that, you know, span there's there's thousands of APIs that that have been implemented. Performance changes all across the the board here, but, you know, I think if you if you look at the overall picture, the the performance situation is vastly overstated, and and, above the fold on on Bun's website. And, yeah, I I think generally have the goal of of reimplementing Node.

Ryan Dahl [01:16:14]:
And, Yeah. That's that's that's, I guess, a goal, but not not what I'm trying to do. We're we are we are trying to level up JavaScript and kinda build the JavaScript for the next 20 years.

AJ O'Neil [01:16:26]:
That was an excellent line to end on. Yeah.

Charles Max Wood [01:16:30]:
Good stuff.

Dan Shappir [01:16:30]:
By the

Steve Edwards [01:16:31]:
way, to answer your question, the rim shot was because you mentioned the magic word pun. So I just had to throw that out.

Ryan Dahl [01:16:36]:
I see. I got it.

Steve Edwards [01:16:37]:
I'm thinking about pun and bun, and I was like, okay. That deserves one right there.

Charles Max Wood [01:16:42]:
Alright. Well, let's do picks. Dan, you wanna start us with picks?

Dan Shappir [01:16:47]:
If I unmute myself, it will be helpful. This is the 2nd show that I'm recording in 1 week, so I'll excuse myself and say that I'm all picked out, and, move on to the next person.

Charles Max Wood [01:17:02]:
Alright. AJ, what are your picks?

AJ O'Neil [01:17:06]:
So I tried Swift, and I have not had enough time with it to give a a a true take, but I'd like it. I have this problem with macOS as they introduce these, you know, permissions and, you know, the tools that I used to have that work, they kinda stop working or new bugs get introduced as they're changing out all those permission models. And one thing that's been happening lately is my network drives become unmounted. And then when my computer wakes up, they're not remounted. And so I wanted to create something that would listen for the unlock event and then mount my network drives. And it ended up being the the demo code was 10 lines of swift, and then I expanded that out because I wanted to make it, like, a normal project with command line arguments and, you know, the stuff that I typically do and kinda get a feel for it. And I really, really like it. It's it's kind of, to me, it kind of feels almost on par with Go in in some respects.

AJ O'Neil [01:18:23]:
I don't think that they're maybe as thoughtful and deliberate in the way that they present APIs as go is, but it is very explicit. And it there's there's enough training examples that as a person who had never touched swift before, I was able to use GPT to to pretty much, you know, be the code assists. My my primary code assist in in creating my program, which ended up being more than 10 lines. It's more like a 100 because of the like I said, there there was some arguments parsing and some other stuff and me just playing around. But, yeah. So I'm I'm gonna pick Apple's Swift. It it it it seems to be a really solid language, and I, yeah, I I don't know. I I have it.

AJ O'Neil [01:19:22]:
It's different. It's diff it actually reminds me more of PowerShell than of anything else, which that sounds like a disk, but it's not. PowerShell is probably one of the best things that Microsoft has ever turned out. PowerShell is incredibly well engineered and thought out. It has a different paradigm. It's actually a much more functional paradigm, but and and it doesn't have a concept of standard in and standard out as much as it has a concept of pipes and streams. And so there's not just standard in and standard out. You can I think you can have an arbitrary number of streams, but they're they're kind of functional in the way that they work almost like channels and go or something? I I don't know quite how to explain.

AJ O'Neil [01:20:01]:
But, anyway, Swift is Swift is a pick for me. And then

Dan Shappir [01:20:06]:
Before you move on, it just what you said about, GPT just occurred to me that we had totally forgot to ask Ryan which AI which ML model are you going to be building into Deno?

AJ O'Neil [01:20:18]:
Yeah. Yeah. What's your what's your AI strategy for the future?

Ryan Dahl [01:20:24]:
I I I really you know, doing a startup, like, that that question gets asked unironically, very often.

AJ O'Neil [01:20:31]:
So Oh, I know.

Ryan Dahl [01:20:32]:
Yeah. I I our our, our, our technology is is pretty orthogonal to this. But if you go back and and kinda look at some of my stuff, Deno actually started out as a TensorFlow plus node project. We I was coming out of Google Brain and and, wanting to do ML models in JavaScript. And we we haven't touched on kind of the Jupyter Notebook support in in Deno, but, you know, I guess suffice it to to say that that I think, data science and statistics and stuff in JavaScript is a thing that will happen in the future. And although I'm primarily working on the module system and and kind of getting the run time up and running right now, I I have dreams of of kind of stealing statistics away from Python and and scientific computing and and, making this work in in JavaScript really nicely.

Charles Max Wood [01:21:24]:
I I love the idea. To be honest, I've been thinking for a while that I I would love to see something like that in a language that I find more approachable. Right? So, you know, for me, that's Ruby and JavaScript. But, you know yeah. Just just having those capabilities in these hands. And I I think, especially JavaScript with the reach that it has, I mean, that that would be amazing. So I'm all on board with that.

Dan Shappir [01:21:53]:
AJ, did

Charles Max Wood [01:21:53]:
you get all your picks out?

AJ O'Neil [01:21:55]:
You know, one more. I think I'm gonna have to switch my my, browser screenshotting service from running with BUN to running with Dino. So I I'm just testing it right now. It worked. I was able to just, like, change two lines of code, but what process dot exit was one of them. But now it's not closing. I'll figure that out. But yeah.

AJ O'Neil [01:22:19]:
So so I guess I guess I'm a Dino fanboy again. Ryan, I've I've had some things to say in the past. So

Steve Edwards [01:22:28]:
What?

Dan Shappir [01:22:30]:
You?

Steve Edwards [01:22:31]:
I am shocked.

AJ O'Neil [01:22:31]:
I've no. Be between like, as this cycle has gone from, you know, Node and Dino and BUN, I was, like, on the Dino train for a while, but I was really frustrated with some stuff. And then I was on the Bun train, so I'm, I'm JavaScript fluid. Alright.

Technical Interjector [01:22:46]:
Well, all good. We're we're

Charles Max Wood [01:22:48]:
try we're

Ryan Dahl [01:22:49]:
trying to figure it out. Hope hopefully, you have a nice experience with with Deno in the future.

AJ O'Neil [01:22:56]:
Well, it's it's gonna improve my, my performance on opening up a binary to run Chrome to do a screenshot. So

Charles Max Wood [01:23:04]:
Alright. I'm gonna jump in and derail us back to, Steve. Steve, what are your picks?

Steve Edwards [01:23:13]:
Okay. Ryan, I'm not sure if you're aware, but the high point of all our podcasts is my dad jokes. So hence my name, dad joker.

Technical Interjector [01:23:22]:
So wait a minute. Okay. Supposedly,

Steve Edwards [01:23:27]:
30% of the world's population lets their pets sleep in bed with them. I'm really upset, though, because I tried it yesterday, and now my goldfish is dead. And the other day, I learned that Albert Einstein was a real person. This whole time, I thought he was a theoretical physicist.

Ryan Dahl [01:23:52]:
And then

AJ O'Neil [01:23:53]:
I liked it. That was so good. They don't

Charles Max Wood [01:23:55]:
get better.

AJ O'Neil [01:23:55]:
That's the best one you've had in ages. That was the best one you've had.

Steve Edwards [01:23:58]:
Pretty high bar. And then last night, I saw this breaking news story that, during the day, actually sorry. During the day, Count Chocula, the Stay Puft Marshmallow Man, and the Teddy Graham's bear all perished in a fire, and they said s'more at 11.

Dan Shappir [01:24:15]:
What what what your joke about Einstein reminded me of of a dad joke about this, young physics student who's at a party and he's dancing with some girl trying to pick her up, and and he says, you know, Einstein's dead, Einstein's dead, and I'm not feeling so well this evening. I guess that didn't land.

Steve Edwards [01:24:39]:
I'll give you a, rim shot anyway for the effort. That's all I have, John.

Charles Max Wood [01:24:47]:
Alright. I guess it's my turn for picks. So I'll jump in with, I always do a board game pick. I don't know if I did this last week or earlier this week, so I'm just gonna pick it. And if you get it twice in a row, I am sorry. I'm gonna pick challengers. It's a game it's kind of a mix between capture the flag and war. It's a relatively fast game.

Charles Max Wood [01:25:11]:
You play 7 rounds. Whoever has the most points at the end of 7 rounds, the the 2 top people go head to head, and whoever wins that one wins. And, effectively, it's a deck building game or kind of. So you draft cards. You can put 2 cards into your hand or one higher level card on some rounds into your hand. You're building out your deck, and then you flip the cards over, and they have different abilities. And so, anyway, sometimes they stack nicely. And, essentially, there's, I can't remember what the zone is on the side of the the the playing field, but, you can stack up to 6 types of cards on the sites.

Charles Max Wood [01:25:57]:
If you run out of room there, your opponent wins. If you run out of cards, your opponent wins, the round, and then they get a trophy that has the points on it. So the gameplay, is relatively simple. It's just knowing how to get the cards to synergize is is the game you're really playing. And then knowing when to pull things in and out of your hands so that you don't bust on putting stuff in onto your bench, right, and running out of room there. So it's it's a terrific game. I think board game geek rate weights it at 2 something. I didn't look it up.

Charles Max Wood [01:26:35]:
But it's it's super fun. It plays up to 8 people. That's the other, thing that I like about it is that, usually, you get a board game and it'll play 4. Sometimes it'll play 5 or 6. Challengers plays up to 8. And, everybody gets a card that just shows you where to sit next so that you're playing. And, yeah, the board game weight is 1.78, so it's pretty approachable. I think my 8 year old could play it.

Charles Max Wood [01:27:03]:
I don't know that she'd really do well with the deck building piece. Right? Put all these together, you know, to to have a mighty hand. But I think she could, to a certain degree, know, oh, I really like these cards or pick the higher the higher number cards so that you can win the flag back. So, anyway, I'm gonna pick that. Came out in 2022. I played it at the game board conference up in Layton, and it it was awesome. So, anyway Is

Ryan Dahl [01:27:37]:
it good for 2 players?

Charles Max Wood [01:27:39]:
Yes. You can play it with 2 players. It is probably better with 4, 6, or 8 players. If you have an odd number of players, there's a robot deck that, gets progressively harder as each round goes by because it's got things like, this card is worth whatever round you're on or however many fans, which is the points you have or things like that. So, you know, it it's kinda set up to kinda match your hand, but you play both hands when you're playing against the robot. So so if you can play with odd number of players too is what I'm saying. But, yeah, it's it's typically better if you have at least 4, and that's just because then you get to switch up who you're playing against. But you can definitely play a 2 player.

Charles Max Wood [01:28:29]:
Yeah. Sounds good. Yeah. It's it's pretty awesome. So I'll put the BoardGameGeek link in here, and then I'll go find an Amazon affiliate link here in a minute. Then other picks, there was an article that came or not an article, but a blog post that DHH put out, basically talking about free speech. And basic essentially, what he was saying is that people have the right to say things even if they're offensive, even if they're awful, even if they're full of crap. He didn't say full of crap.

Charles Max Wood [01:29:02]:
He said some he he used the word I'm not gonna use on the podcast, but, you know, but you have the right to say what you're gonna say. And and I like the idea of that just from the standpoint of, hey. Look. At least I know who you are. Right? I I and I think most people are smart enough to figure out, yeah, you know, you're saying this and you really are full of crap. So, but but he was responding mostly to the stuff where they're sending sentencing people to, like, 20 months in jail for posting something to social media that's offensive in England.

AJ O'Neil [01:29:36]:
And Oh my goodness.

Charles Max Wood [01:29:37]:
Yeah. Just Very true.

Steve Edwards [01:29:39]:
I've seen the videos.

AJ O'Neil [01:29:41]:
Yeah. I Yeah. I the the thing that and you see this in the United States too, and it you know, it's cherry picked examples, but they give an example of, like, a a man essayed a woman and got 6 months, but a person who posted something mean on Twitter got 20 months?

Technical Interjector [01:30:00]:
Yeah.

Dan Shappir [01:30:00]:
It's it's a it's it's problematic because unless you know, it's very easy to get specific cases wrong if you don't know the details. Like, you know, on the one hand, it's obviously free speech and we're all we're all in favor of free speech, but then turns out that incitement was made. So it's it's, you know, it's it's like, if you say, you know, go out and kill all such and such people. Right. Yeah. So I'm not saying that it's not that it's right or wrong. I'm saying that you need you should have

Technical Interjector [01:30:32]:
the full context before making judgment.

Dan Shappir [01:30:32]:
I tend to reserve my making judgment. I tend to reserve

Technical Interjector [01:30:34]:
my judgment until I

Dan Shappir [01:30:35]:
have, you know, as much as it was. Mob boss with a coordinated attack, it doesn't matter if

AJ O'Neil [01:30:39]:
on Twitter you

Dan Shappir [01:30:40]:
say go kill someone.

AJ O'Neil [01:30:41]:
I mean No. If it was a leader of a terrorist organization, that's one thing.

Technical Interjector [01:30:46]:
It depends

AJ O'Neil [01:30:46]:
on show. Look. But in some terrorist organization, that's

Dan Shappir [01:30:48]:
one thing. It depends on show. Look. But in some countries, it is. You know?

Charles Max Wood [01:30:53]:
I I didn't mean to open this can of worms, but, I will say

Dan Shappir [01:30:57]:
that yeah. Again, I'm I'm not being a huge crush. I'm just saying that in some countries have different laws regarding free speech than the US does, and you should be cognizant of that.

Charles Max Wood [01:31:09]:
Yeah. I recognize that. I think I think the issue that he's pointing out and he didn't go into, like, incitement and stuff. Right? He was just saying, hey. Look. You should be able to say wrong things. And and that I agree with. Right? Yeah.

Charles Max Wood [01:31:21]:
Down to incitement. If you're encouraging people to go out and hurt other people, you know, obviously, that that's a real problem. But if you're expressing your opinion, you can express bad opinions. Anyway,

Technical Interjector [01:31:35]:
I'm

Charles Max Wood [01:31:35]:
trying to think if there's anything else I wanted to pick. I I have an AI summit that I'm putting together in October, so keep an eye out for that. Other than that, Ryan, what are your picks?

Ryan Dahl [01:31:49]:
I really like grain.com. This is, some tool that helps you, record meetings. And Deno Deno is a company. Deno Deno has, is remote, and and we have, meetings with with people. And and, yeah, Grain just helps you record it and, make some transcript of it, and, I find it just super useful to to it's just got a great interface. So pretty pretty simple tool, but but, and I'm sure there's probably other ones, but I I've been finding a lot of utility from Grain.

Charles Max Wood [01:32:27]:
Awesome. Alright. One last thing, and I we should have asked this way earlier, but if people wanna see more information about dino 2 or if they wanna reach out to you and say, hey. I like this or I don't like that, how how do they find you?

Ryan Dahl [01:32:41]:
Yeah. I'm, rough c rough_c on on Twitter, with deno_land on on Twitter, and to deno.com on on the webs. And, yeah, there's a Discord. You can you can find my email if you search hard enough. So, yeah, feel free to

AJ O'Neil [01:32:59]:
get this Rai?

Ryan Dahl [01:33:03]:
Rai, the Twitter handle or what?

AJ O'Neil [01:33:06]:
Yeah. Well, I thought you were Ry. Were were you not Ry?

Ryan Dahl [01:33:09]:
I I I was Ryah or with an h, in, like, 2010. But, Yeah. I I stopped using Twitter for a number of years and just just came back a couple of months ago.

AJ O'Neil [01:33:22]:
Well, I'm sorry for your mental health. I'll offer you some aspirin if you need it.

Ryan Dahl [01:33:30]:
It's still it's it's it's fun being on Twitter these days. Yeah. Back in the note days, it was very noisy.

Charles Max Wood [01:33:37]:
Oh, I bet.

Dan Shappir [01:33:39]:
That explains the that explains the shockingly low number of followers you have. Yeah. I was Yep. By the way, Chuck, did you give Ryan the chance to do pics?

Charles Max Wood [01:33:51]:
I did. Yeah. You picked Grain dotco.

Dan Shappir [01:33:53]:
Oh, I missed it. Sorry. I wasn't I wasn't paying attention. Sorry.

Charles Max Wood [01:33:59]:
Yeah. Alright. Well, we're gonna go ahead and wrap it up. Thanks for coming, Ryan. And thanks to your team. They've done an excellent job, kinda keeping us informed so we could do this.

Dan Shappir [01:34:11]:
And and thanks for making such a huge difference to the web. I consider the web to be, like, maybe one one one of the greatest achievements of humanity of all time. And and and I think that, you know, you and the Dino team, but even you personally, have made a significant impact on that. So thank you for that.

Ryan Dahl [01:34:35]:
Yeah. Well, I I don't know if I can take credit for the web, but I I can take credit for Node, which, yes. Thank you. And, yeah. Thanks for having me on. It was fun.

Steve Edwards [01:34:47]:
Well, thank you for the reminder of the Flint Stones every time I hear the name.

Charles Max Wood [01:34:51]:
Alright. Till next time, folks. Max out.

Steve Edwards [01:34:54]:
Bye. Cheers.