Deno 2 with Ryan Dahl

Welcome to Syntax. Today, we have Ryan Dahl on the podcast once again to talk to us about Deno two point o, what the future of Deno looks like, some of the new exciting features, and I'm sure we're gonna talk a little bit more about, JSR and and whatnot that comes up. Probably everybody knows this, but, Ryan, obviously, creator of Node. Js, prolific developer, and he's been the last I don't know. How many how many years has Dino been around? 4 or 5? I think 7, actually, since since we started it. It's been, yeah, maybe 4 since the it's become a company. That's that's awesome. Give us a quick rundown of of what Deno is for anyone who hasn't heard of it. Deno is a server side JavaScript

system. It's it's pretty, you know, in the same boat as Node. JS, and in a a pretty real way is is, like, my continuation of the the Node project.

Node has all of these ways of operating with Node modules, folders, and package JSON that aren't necessarily specified in any standard. Deno is really trying to simplify this and make make server side JavaScript as beautiful as it can be because JavaScript is the default programming language and deserves a great future.

Yeah. Yeah. Absolutely. And the one thing that I think a lot of people have appreciated about Deno is the fact that it is using web standards Vercel. But it it feels like it's just easier to get up and running with and easier to use and less less effort. Has that always been part of the goal with Deno to make it easy to pick up?

I mean, that was even the goal with with Node originally is is, I I mean, not working in JavaScript because it's a a beautiful language. We're working in it because it's very familiar to people. And as being a scripting language, you know, being able to program a web server, which was, you know, a main focus back in in 2009 with with Node. In just a couple of lines of code is is amazing. Right? And JavaScript has grown tremendously since since 2009. And, yeah, I mean, if you work in this language, you kinda know that things get pretty crufty, and, you know, there there's all sorts of disparate tooling that that needs to, be tied into your project. You you kinda need to be a bit of a expert in the node ecosystem to be able to kind of, you know, set set up, like, what is Prettier? Oh, Prettier JS the way that you format code. Oh, you need ESLint, or do I need ESLint? Like, you you know, like, there's just all of these little things that you guys JS experts, like, know from from the get go. Right? And you're like, yeah. Of course, we use Prettier. Like, but duh. Like, that's that's the way to do things. But there's all sorts of people out there coming from other languages, just getting started that don't know what Prettier is and don't know how to set that up. And being able to just provide that out of the box so that you can open a file and just start coding with a couple of lines and just I don't know. It it gets your your excitement flowing again. Right? Because you're just like, wow. I can can actually focus on on what I'm trying to do rather than all the other stuff.

Yeah. All the the frustrating parts of getting it all running. I often talk about this that experience I have as an outsider to the Python Sanity, where every now and then, I gotta run something that's in Python. And I realize that I'm a bit of an idiot, But I'm an outsider coming in, and I nothing ever works, and I don't have the right version installed. And people are telling me to use these other packages instead of Pnpm. I Scott Aconda, and everything JS. And, like, it's just like and I'm starting to see that hit the the note community where it's just like, oh, yeah. You gotta use all these things. Well, don't use npm. You gotta use this other thing, and it's just like, I hope that doesn't happen to our community where you have to have this knowledge of gotchas in order to just get up and running. And and Deno makes that just it's just so easy. You know? I don't even think you need a tsconfig to to run something. No. No. It's so simple.

Sing single single executable. There's there's, like, literally 1 file gives you your entire development setup. You Node? It gives you your LSP for integrating with with Versus Code. It gives you, your your linter, your formatter. It gives you Deno compile. It gives you type checking. Like, all all of it is is yeah. It's opinionated in many ways. And and I think for advanced users, that can rub rub people the wrong way. And and, you know, in in certain ways, Deno Deno kind of is not the most ideal experience sometimes when you're working with with kind of existing Node software. But for people just coming to it, it is very glossy and and and lovely. Yeah. That's that's what I want from JavaScript. Like, it should be like Duplo blocks. Like, you should just be like, yes.

Done.

This is beautiful. Right? Rather than just worrying about, whether I should use PIP or Anaconda or, yeah, I also have the same problem with Python. Okay.

Oh, that's good. Alright. So let's talk about Deno 2 point o, and I I kinda wanna one thing you just said that got me really excited is you're gonna be able to use Next. Js with it. So tell me about what Deno 2.0 looks like.

So Deno was started with the idea that we can reset expectations entirely in the JavaScript ecosystem.

We don't need to support NPM. We can use h e p s imports. We can have kind of a completely different registry.

And, like, we are pursuing simplification hard and experimenting in all sorts of ways. But it's become pretty clear over the last couple of years that there's a lot of NPM packages that people just need to use. Right? Like, you gotta pull in the, whatever, AWS SDK, and, like, there's no way around it, or you need to use a gRPC library. And, like, you know, if Deno doesn't support it, well, then you can't use Deno, and that's not a great experience. Right? The glossiness wears off really quickly. So it's it's become really obvious that we need to have support for NPM packages, and NPM packages are all built on top of the built in node APIs. And we've been under this JS, like, a really large undertaking.

And and, we've been working on this for essentially, like, 2 years now. At this point, Deno is getting really close. Like, it's kind of a long tail situation where it's going to be impossible to support everything in all its its granularity.

But, like, most NPM packages are working out of the box in Deno.

But in particular, like frameworks, things that, you know, might have a node modules folder and existing package JSON, Deno can also support, including, like, very complex frameworks like Next. Js that, build processes and and have all all sorts of stuff. So, yeah, you should be able to just run these things, Deno run Node, in your next project once we get to Deno 2. There's there's a few minor kind of breaking changes. Most people most Deno users are not going to notice the difference. No no major changes, but, there's kind of some some minor differences in kind of installation and and stuff that allow us to support these package JSON projects.

And, yeah, you'll be able to to run, Next. Js.

Wow. Wow. That's exciting. And what JS the process of supporting the entirety of NPM and and that look like? I Node, initially, a big part of Deno was taking all the node APIs and just and shimming them or or, like, trying to reimplement them. If you go into the Deno source code, you can look at a lot of the node modules and see that they are just reimplementing the API and using the Deno equivalent to that. Like, you look at the FS. If someone's using Node APIs in a package, it just makes them with the the Deno file system APIs. So, like, how do you even tackle that once you have the thing down?

A lot of the I would say, yeah, maybe 90%. Hard to put a number on it, but maybe 90% of the built in Node APIs are exactly that. Like, whatever you do, you know, CWD in Deno, in in Node, and you're you have the equivalent, like, Deno Scott cwd. It's it's just kind of mapping APIs. There's other ones that get very intricate though. For example, the HEP client in Node is intricate and supports trailing headers and all all sorts of all sorts of knobs and dials on it that we've had to kind of drop down to a lower level and implement directly in Rust, because, like, in Deno, like, our the HEP client is just fetch. And fetch is, like, relatively simple when compared to, say, the the Node HEP client.

And, yeah, it's it's that sort of work times a a100. Right? There's there's, like, a lot of of different APIs and a lot of intricacies to how they're working. And, yeah, that's kind of the API side of things. And then there's, like, the loading of modules and handling node modules and handling package JSON, which is which is kind of you know, maybe you could call it, like, the framework side. Like, when Deno is sitting in a node project, how how do you kind of interact with with all of those things? That is also also an undertaking in in of itself. And I'd say it's maybe 5050 in in terms of work on on both sides. Sorry if I'm being vague, but, you know, it's really wildly complicated.

Yeah.

I'm curious about, like, what parts are not doable. You know? Like, when we had the Cloudflare people on, and they said, yeah. Like, most of Node will work on on Cloudflare, but there's always some weird edge cases, especially when you get into the, like, native stuff in Node. Are there parts that you can like, if somebody is working on a project that is

obscure that might not work? These Yarn, like, small little things kind of splattered across the code base that are are hard to support. One thing that I was just just on a call about so we do support n API, so you can load node native node extensions, and those will work in Deno. So if if somebody's programming against an API, that will work. The SQL SQL lite 3 package on Npm uses a Libuv API that is not part of the the n API.

Stop me if if this is, this is going off. But, like, they're using some API that is not present in in an API, and we don't support that, LibUV API. And so the question is, do we implement that? Do we not implement that? Do we patch, SQLite 3 to use the equivalent n API stuff? And it's probably the latter. So, you know, there's some some amount of sometimes just updating packages. Deno supports all of common JS. You can't use common JS in Deno programs itself, like if you're programming Deno. But if you pull in an NPM package, it can use common JS. And so, you know, in in in some ways, we are pretty religious and, like, forcing you know, we we are pretty adamant that, like, we push people towards browser JavaScript as much as possible. And so we will not allow you to use require.

However, if you pull in an Npm package somewhere deep in in the bowels of the system, it is actually there is an implementation of of require. It's pretty transparent, though. And, hopefully, you know, the code that you're writing doesn't interact with that in any way. Do you think on the topic of require, do you think we need to do, like, a hard break from require? I know there's a couple big package author authors have done that,

but the just the common JS seems to be sticking around forever.

Do you think we need to do something aggressive or just kinda ride it out for another 6 years?

I mean, it's it's likely a Python Python 3 situation. Very Sanity.

Yeah. It's it's kind of just a big change that's for better or for worse. I mean, it it's something that that we're going to deal with. I like the new import syntax. I like that it's statically analyzable. Like, I there's a lot of good things that come with this. I like that it's you know, you can use this in the browser, but it is complicated in in many ways. The hard break that that yeah, I I don't think we need, like, a hard, hard break. And I think Deno is living proof that that, like, we can have a strict, ESM first, runtime that can still support common JS. Right? So so I don't think there's there's, yeah, there's no hard break required for users, but maybe a good time to pivot to JSR. JSR is is a package registry that does support npm dependencies. You can publish packages that can depend on common JS packages in npm, but we we do a hard break. You cannot publish or require common JS stuff to to, JSR. You must use ESM. I I think there's no going back. Like, for sure, the world will move to ESM. It's just a matter of how long it takes to get there. And so I I think, you know, all of us kind of working in in the space, I think, you know, really, really can do the world better by by just pushing this along as as fast as possible because the alternative is just arduous years of of, like, an in between state that, Toast that I I think doesn't benefit anybody.

I think Deno's approach is great, though. I mean, your applications are going to work if somebody somewhere is using a require.

But the fact that you're not being allowed to, I think that's that to me is seems like the right fix or at least the the right direction. You guys also added package dot JSON. I know it was a like, was that Dena 1.3? Was that when that came out? I know it that was, I think, like, last year or sometime.

What was the decision to add package dot JSON like? Was that a tough call to add? I know that, you know, in the past, people would make, like, a deps dot t s file or something Node do their imports. And it's almost like a sudo package dot JSON. What was the reasoning behind eventually giving ESLint add package dot JSON?

First of all, that there's just a lot of software that uses package JSON and that if we're supporting NPM dependencies, it's not really a stretch to have a a package JSON with with kind of a a dependencies field in it. Browsers don't know anything about package JSON, and we are looking for ways to build builds on the future of JavaScript and really give kind of a a browser compatible way of of sharing modules.

And so we recommend people use import apps actually for defining dependencies and and kinda mapping long URLs of that reference dependencies in into kind of short bare specifiers.

And we've taken this I I would call this kind of v two of of the depths dot ts, convention that that we had early on in in Deno.

Imports maps work work a lot better than that. But package JSON, like, yeah, there's just so much software that that uses it, and it's so easy for us to support it. Right? To not do so is is kinda ridiculous.

And so, you know, essentially, there's there's kinda 2 modes in Deno. Like, you can run with a package JSON, or or you can run with with an import map. It's it's pretty transparent to users. And and, you know, hopefully, it still gives that Duplo block like experience where you sit down and, you just start start using Deno, and it's like, oh, wow. Okay. It just just works.

I I like it because I'm very much standards forward. Any new code that I write in server side, I make it based on fetch and web Wes and web response and and all that type of stuff. And but then I do have, like like, legacy code there Scott legacy, but just, like, code that I've written before this that that Scott needs to come along. And I I love that Deno does that because it just it makes the hard parts kinda just smooths it over. And then I know that my my new code going forward is is only gonna be web standards based, like JS or Hono? Is it what do you call it? I've been calling it Hono for at least 2 years. Is it Hono? I I Node been calling it Hono, but what what do I know?

You're you're probably right. I know a few things. Yeah.

Because CJ also calls it Node. And every single time I call it hono, I feel self conscious about it. Trusted with with these type of things.

But I'm curious. People aren't listening right Node. Like, okay. Well, I have I have a Node app even myself. I've got an Express application.

I've got a Next. Js application. They all work together, and it it goes to my database.

What would I gain

by moving out of Node and just running that application in Deno? The secure by default aspect of Deno is still pretty awesome. You Node? If you have an API server and it's Yep. Just kind of juggling some connections between, you know, doing some auth here and sending it out there, like, it shouldn't have access to the file system. Like, you should really just you should be doing security at multiple layers and, you know, giving an allow list of domains that it can connect to, I think, makes a whole lot of sense. Right? It's it's a little bit more to configure, of course, but, V eight just gives you all V eight is a secure sandbox, and and being able to utilize those things out of the Bos is is pretty great. Obviously, the the TypeScript support is is pretty awesome. You Node? I think for Next. Js in particular, there's not a whole lot that you're going to gain from from using Deno because there's a bundler. You Node? The development process is already very smooth. It's going to look very similar to to how it it works with with Node. But, you know, I think an Express API server is is a perfect example where you can just reduce all sorts of complexity by moving to Deno. Get rid of your TS config file. Yeah. You know, move to move to TypeScript.

Essentially, you could get rid of your package JSON entirely.

You can make it secure, by, you know, only allowing it to make net connections and not, say, write to your file system. You know, your development experience should be pretty simple as well. If you're using auto formatting, just run Deno formats. If you're doing linting, our our linter is very, very fast, like a 100 x faster than ESLint. It's all implemented in Rust. That comes out of the box for you. And so as you start coding in Versus Code, you'll get nice little yellow squiggly lines underneath your stuff, and there's essentially nothing that you need to set up. And I I think there is a nice now with with Deno 2, like, there there is a pretty nice onboarding path to this. I think previously with Deno, you would have had to make, like, okay, stop the world. Let's switch. You Node, let's rewrite for Deno, and then I get all of this great great stuff. And, you know, maybe you're just not ready to make that switch all at once. Right? You're not ready for a 2,000 line diff. But, with Deno, you should you with kinda the new features that we've been adding, this should be an incremental operation. So you you should be able to to just start it up with with Deno, first of all, and then incrementally start, doing doing a few things. Right? You might run into a few few little gotchas, like the process variable doesn't ESLint. Should give you a nice nice error, and you import Node colon process and and kinda get get past that. So we kinda push you in in certain ways. But, generally, it should be a pretty smooth process. And at the end of the day, your your project ought to be in, opinionated, straightforward TypeScript that has very few configuration files, if any, and, yeah, you know, web standards forward.

It should also make the like, like, talk about deploying it and and hosting it. It should make the deployment significantly easier because there's not a whole bunch of steps to compile everything and cache things and and whatnot.

And then, like, what about, like, actual perf of, like, the website running? Would is there a possibility that it would use less resources?

Oh, for sure. Oh, yes. I never mentioned this because Bun hammers on this. It's so Yarn, but Deno is very fast. Deno Deno is crazy fast. Deno outperforms Bun a lot. I don't feel so confident to put a graph above the fold on our website. I think that's like, cherry put benchmarks like that are a little disingenuous.

But Deno is very, very fast. So if you compare, say, express throughput against node, you can expect, I don't know, 2 x improvement.

But maybe a more important metric, you know, depending on where you're deploying this to. But, you know, for example, if you're deploying this to AWS Lambda, you know, throughput is not necessarily your primary concern. Cold start latency is is your primary concern. And Deno has all sorts of nice features there, like Node code caching, which is essentially like a byte code representation of your source code that, essentially, we have best in class, cold start time on Lambda, for example. Performance in Deno is fantastic, and it should, across the board, work better than Node and is essentially on par with BUN, who does a a lot of great performance work but is wildly overstated in how they cherry pick their benchmarks. And if you want to see all of the errors in your application,

you'll want to check out Sentry at sentry.ioforward/ syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to sentry.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rolls. Alright.

What do you think about BUN implementing

like, just going hog wild in implementing nonstandard stuff? To to each their own. I I, you know, I I just have this theory that JavaScript is here for the long run and that this isn't a, like, 2 year sort of thing. This is, like, a 20 year sort of thing. Yeah. Because infrastructure is just software infrastructure relies so heavily on the browser.

And so I I just think it's really important for us to think long term about where we're going with this thing. And, yeah, we're building we're building Deno for for the future.

Yeah. And and I guess in that same regard, like, Node seems to be I don't know if it's it's from the pressure of Deno and BUN or what, but Node seems to be getting a wild amount of new features lately, whether that's ENV support, SQLite, even the type stripping that that's available. What are your thoughts on on the additions to node overall? Do you think it's being too much jammed in there, or or is it a positive thing? I mean, I I started the small

node theory, and that kinda dominated node development for for a long time, small core, and kick everything out to NPM. You know, I think that theory had a time and place, but it's it's pretty clear, you know, in the Wes twenties now that that, the run times can be doing much more to simplify development. And I think for sure, Node is is looking at what, Deno is is doing and and saying, hey. We could also do that. Right? The the this also seems like like a good idea.

My fear is is with Deno is is that we actually just act as an r and d shop for for, like, figuring out these features, and then and then, like, like, they actually get implemented in in Node. But, yeah, I, it's a possibility. I think there is a use in taking a hard look at what we're doing with server side development and Vercel side JavaScript and making it beautiful. And it's really hard to do that deeply in a, what, 15 year old code Bos, c plus plus code Bos, like, Node. Like, it it can move, and I I'm really happy that it continues to evolve and and is I I mean, I I essentially wake up every day and just like, is this real? Like, did did I really make that project that is, like, running every website on Earth? That's that's awesome. Yeah. Yeah. So and, like, I'm happy that that they're evolving, and and Node success is is, is my success in in in many ways. So, yeah, happy happy about it, but I I also think that it is limited in how far it can go just due to where it's starting and and the number of users it has. I'm pretty sure I saw the other day that the privacy stuff, the experimental privacy stuff, was scrapped or taken out, which JS, like, one of the I I remember, initially, I was trying the demo, and my feedback was make this more like Deno because Mhmm. You fire up a Deno script, and it'll be like, hey. This code is trying to access

your file system, or are you sure you wanna allow it to ping out to this URL? And I was kinda bummed to see that because the supply chain attacks lately are getting out of control. Like, I I saw something like 70% of node modules were were some sort of spam, and there's all these projects trying to find them out. And it's only amount of time before you Pnpm install something 11 levels deep that nukes your computer. You know? The the post install script being run by default is just

so terrible. Like, people should be very concerned about post install scripts. I mean, it's one thing if you had some dependencies that you've audited and, like, you kinda know what they're doing. But the idea that you could just, like, you know, Npm add something, and it's executing random code from the Internet that, like, not even the thing that you're you're adding necessarily has vetted. I mean, that's yeah. It's a recipe for disaster. Like, post install scripts have to Wes. It like, 100%. There's no world in which this is going to continue to work like this.

And it's it's one of those things where it's like, you know, let's just do this faster. Like, we can suffer for for years years years, or we can just just, all agree that post install scripts are bad and move forward as quickly as possible.

Yeah. I think that's where Deno 2 really comes in handy here because you'll be getting those security

improvements while not having to really modify too much. I mean, even I was just googling SvelteKit Deno, and it's pretty much just use the net you know, the Deno 2 env var to make sure that you're using Deno 2, and that's it. That's pretty amazing that you can Deno feature. Deno underscore feature feature equals 1, which, by the way, if if Deno 2 is not out when you're when people are listening to this, that's at that environment variable, and that kind of feature flags turns on all all of the features, which are you know, to to the average user is going to be completely transparent,

but there's, like, minor small things that have big impacts that that it's those. One of my favorite Deno projects lately JS it it's Loom or Loomay. I don't know how people say it, which is just an incredible static site generator and and CMS project.

When we shared that on our daily dev, it got a massive amount of clicks. People seem to really resonate with it. I was wondering if there were other projects out there in Deno land that you really admire or or think are pretty amazing beyond Loom. I mean, I would be remiss if I didn't mention Fresh. That is obviously a a great web framework that we're developing, also aiming to release a version 2 of that here at some point. It's a whole community of people doing like Deno desktop stuff. So Deno has a Wes GPU built into it, and there's an API, unstable API, Deno, that allows you to attach this to a frame buffer and like actually display a window that renders Wes GPU without a web browser, okay? So Node can do this with kind of a a Chrome setup, Electron or whatever, but like you can actually like render GPU accelerated Windows in Deno without any other stuff there. And so there's people developing little games and stuff, which then combined with Deno compile allows you to ship a 60 megabytes little game that is, you know, a GPU accelerated thing written in JavaScript. So that that is a a pretty fun little subcommunity of of Deno. I feel like I should give you some links for for this.

Because of, like, Tolinski section of your website. Yeah. We do. Yeah. We share a lot. Yeah. To a large extent, like, what we want is people not to be developing Deno software specifically, but we want them to to be developing kind of TypeScript first, modern, ESM software. And Deno can consume JS long as it's as it's modern. And and so, you know, we encourage people to to publish to JSR, which kind of, you know, has somewhat of a linting system and and kind of encourages you to do best practices. I think one of the things that that I'm hoping to reset with people in Deno 2 is that you don't need to write Deno software. Right? Just just write JavaScript software. Like, it's it's going to work in Deno. Like, don't use require.

Process global.

If you need a Node API, pull pull in the built in node APIs with an import statement. To a large extent, this this stuff should just work. Right? It's not a rewrite the world situation anymore.

And, yeah, you don't need to learn Deno APIs for the most part. The Node API that I I've been fighting for on the winter CG for so long is, file system API. There's no movement to, like, unify a file system API. Do you think we'll ever see that?

I mean, not all systems have file systems for a long time. Do you know do you know Deploy didn't have a file system? Cloudflare Workers doesn't have a file as far as I I don't know if that's changed. But so it's not necessarily clear that a file system that file system is is something that should be standardized.

I think for for those you you probably wanna reach out to node built in APIs or or the Deno APIs, which, you know, are largely the same as node built in APIs, just a little bit better, or just a little bit more thoughtful.

I I almost wish that the and maybe this is even a thing. Just, like, publish the Deno FS APIs as a node package so that I can because I write a lot of scripts on my computer and a lot of build scripts and a lot of moving around files and, syntax websites all markdown Bos. Wes do a lot of that. And often Wes it comes to time to saving the file, we go, Wes do I want this to run right now? Maybe there is some sorta universal

file system API out there. Yeah. We we have a standard library in Deno that's on JSR, and it should be noted that JSR is not just for Deno. Part of what we're trying to do is is recognize that there's a plethora of, JavaScript run times out there, you know, browsers, Deno, Node, BUN, CloudFlare workers, and that people are wanting to write JavaScript that, you know, targets, you know, some subset of those or or all of those. And we have published, the Deno stand you know, what previously was the Deno standard library, but we hope to make it into just generally the standard library for for JavaScript.

And there is a file system library in there that has, you know, fancy utilities like warp and stuff. We're still in the process of porting this to Node, but I think, you know, my my hope is is in the future, you would pull in the standard file system library from JSR. It's going to be have all your types be beautifully, TypeScript complete.

It's going to obviously have you know, be based on promises and and, 408 loops and and async iterators.

Ideally, will work across everybody, maybe not Cloudflare workers, maybe not browsers since they don't have file for this Node. So,

TypeScript, we had Luca on the podcast to talk about JSR. And one of the big things I was really excited about is, like, you just published your TypeScript. You Node? There's no build step. There's no, like, weird like, with NPM, like, somebody has built it and then minified it. And then if you wanna look at the code that is running, you gotta open up the node modules. And with JSR, they will compile it if you need it if you need to use JSR with something like Node. JS. But the idea of simply just requiring the TypeScript as it was authored seems so beautiful to me.

Importing importing the TypeScript.

Oh, importing the file here in here.

Oh, see, that's my, that's my old JavaScript developer cred where I say requiring it, but, yes, importing the JavaScript straight from it. I'm curious about your thoughts on, not types, but, the proposal for types as comments to be added, Wes maybe TypeScript is not the endgame of this type JavaScript

thing. You Node, I'm I I always talk about kind of the future future of JavaScript and how we wanna narrow the gap between server side JavaScript and browser JavaScript. And kind of the inconsistency in this argument is that, like, Deno is heavily TypeScript Bos. And it's like, well, web browsers don't support TypeScript, so where where the hell does that come from? And that is is where I think that type you know, like, we're just kind of inferring a little bit. But, like, my my feeling is that TypeScript is the future of JavaScript. It is where JavaScript is going. We just have to standardize it, and it's, we can't wait around. Like, we wanna make this future happen sooner rather than later. And so, yeah, I I think TypeScript' comments, is not yet a fully formed proposal, but I think is the direction that that JavaScript will be going. And and so I, you know, I I would imagine, you know, 5 years from now, Chrome executes TypeScript natively because it just can do the type stripping, you know, inside of of V eight itself, which would be beautiful.

The type stripping versus type checking algorithms are very different in terms of complexity. Like type stripping, super easy. Like, you can you can write, like, a very simple tool that that can type strip very fast. Type checking is a level of complexity that is beyond what essentially anybody can implement. There will probably only be 1 implementation of the TypeScript type checker, which is the TSC,

because of the level of complexity involved there. Yeah. It does feel like people keep trying to do it and then giving up halfway or just a a step in. Yeah. Yeah. There's been a few projects to try to do it. And I'm I'm curious once we get types as comments because the spec is simply this syntax, as part of the JavaScript syntax, is simply for you to add stuff, but it's not going to tell us the types in JavaScript are string number, whatever. Right? So I'm curious if do you think, like, once we get that, is there going to be, like, a a new type of TypeScript that that comes out and that has a a full type checker that's built in Rust and has no enums?

Frankly, I I don't know. I I could definitely see a future where there are iterations on JavaScript plus types, You Node, maybe a simpler version of of JavaScript plus types that doesn't support all of the intricacies that TypeScript supports. I think what's pretty clear is, like, browsers themselves will never do the type checking. I I don't think that's that's something that will happen.

Node, hopefully, the types JS comments leaves room for iteration on on this and doesn't kind of hard lock TypeScript into into the the primary position. But like very, very clearly, adding types to JavaScript allows us to scale this programming language much, much further than without the types. So I think it's an absolutely necessary future. And because, again, JavaScript is for sure going to be here, like, I I think I think this is inevitable.

And it's like a a means of, like, I guess, code style even. What is your thoughts on some of the nonstandard language features like enums or namespaces in TypeScript? Is that something you avoid when you're personally writing TypeScript, or or do you take advantage of all of the things?

I guess I I don't, particularly care. I guess I I do avoid enums. But, yeah, I mean, from my perspective as as kind of the the runtime author, I just try to make it work for for people, what what they're writing in in in TypeScript. I am not

super opinionated about how TypeScript itself is is written. One kinda cool thing I wanted to shine a little bit of light on is the Jupyter Vercel for Deno. So really big in the AI world, really big in the academic world. People use Jupyter Notebooks for writing Python and being able to display.

Often, it's big in, like, data and stuff, but can be can be for anything. And as somebody who writes a lot of demos, I've been sort of yearning for Jupyter Notebooks for JavaScript, and everyone's like, use observable, use the whatever, and none of it has has really worked. But Deno kinda quietly, maybe 6 months ago, rolled out unstable support for Jupyter Notebooks.

What was the idea behind that?

Deno works really great as a single file. Like, it's it's really great for scripting because you don't you don't need a package JSON. Like, you can just Yeah. Put some imports in and start working from a single file. And that actually is exactly what you want for notebooks as well because you just have a single cell. You don't need to set up a, you know, a whole directory structure of things. And and so, like, it lends itself really well to this, notebook style programming that's so often used in in the Python world. And and, yeah, right now, Deno is is effectively the the way that you execute JavaScript in in Jupyter.

And it works really well, especially combined with observable plot, which is kind of the successor to to d three, Mike Bostock's, work. Yeah. These these days, I'm pulling in, Pandas.

I'm, using observable plots. It's a pretty a pretty great experience, and and I hope you know, the the long term goal here is is that we we could actually move quite a few people who are programming in in Python over to programming in in JavaScript and actually doing data science in in JavaScript. I said pandas, but I meant polars, which JS, the the new Rust version of of, of pandas and data frame data frame library for kind of dicing and slicing datasets.

Oh, okay. Yeah.

That's that's awesome because, honestly, that's often, like, a barrier to entry for a lot of this stuff is that it is all written in Python. Or if you wanna be able to make a custom UI for the output of it, like, JavaScript and HTML and CSS are pretty good at outputting that type of stuff. So if you could write your your Deno code to to work on the data and then you write a little bit of JavaScript code Observable plot is, like, years ahead of, like, anything that you have in the Python world. Like, people are still using Matplotlib in Python. Like, it's absolute trash compared to to Observable Point, which is just

super, super nice to work with. So, like, the visualization side is obvious on for data analysis. It's it's just kind of the the mathematics and the data loading side that that needs to mature. But with TensorFlow. Js and Pollers, like, this stuff is becoming more and more at our fingertips with Deno and and the Jupyter Vercel. You know, we we work a lot on on NPM compatibility and making sure, you know, web developers can, work well in this system. But, yeah, quietly in the background, like, there there is there is a a real interesting thing happening in kind of the data visualization area of JavaScript. And and, yeah, I I hope to see the day when when, JavaScript replaces Python for for all of these use cases because it is frankly a better language.

That's and what about, like, the AI stuff as well? Do you see a lot of that moving towards? We had Deno on from Hugging Face, and he showed us his new transformers JS. We're pretty excited about that. Do you think a lot of the AI stuff will go JavaScript

way? I hope. I I possibly.

I because there there there is just a lot of ML professionals out there who program everything in in Python, and and, you know, everybody uses PyTorch. And and there's just a lot of momentum in in kind of the Python direction. It's it's the main way of doing this. And trying to do anything in JavaScript is completely possible, and there's better and better tooling every month, but it's still, very far away from where the Python world is is in this. And so it's it's a you know, especially with with the AI boom happening, I I wonder how how long it will take ultimately to do kind of equivalent things in in JavaScript. But TensorFlow. Js is really good. Like, I I I think people would be kind of surprised that, like, you can totally write, you know, very sophisticated ML models in in JavaScript. And, you know, because the all the computation is offloaded to the GPU, like, it it's not really up to the runtime performance to to to, like, make those models

run effectively. It's it's all it's all offloaded. What about WASM? I'm curious about that. Every time we have somebody on, we ask them their thoughts on WASM and and WASI.

Is WASM still a thing? I don't know. Yeah.

So Yeah. Well,

go on. WASM is a great idea, but I think the industry got overexcited about it too soon before it was mature enough to really do the things that people imagined it doing. They imagined it as kind of the next generation container system. They imagined Mhmm. You know, everything moving to WASM, you know, fastly, famously, built kind of a a WASM edge service.

It kind of intersects very poorly with reality because, actually, what most web developers wanna do is write JavaScript. They they actually don't wanna write in Rust. They don't want a build step in in their process.

And they don't want to take their JavaScript and take Quick. Js, compile it down to to Wasm, add it on, and then execute it in WASM all, you know, 10 x slower than if you did this in in V eight. So, you know, my my opinion is is that WASM is a part of JavaScript, a subset of JavaScript, that JavaScript is actually the the umbrella thing, and that WASM is is a place where you can, you know, compile ImageMagick into binary and, execute, stuff in JavaScript in there. So I think WASM will continue to mature, but, like, the yeah. I think I think everybody who's who's, like, gone out and tried to build, say, a a company on top of WASM doing kind of whatever WASM container hosting services is is not Yeah. Not doing very well at the moment because that is not actually how people wanna build stuff. Yeah. It's good. Yeah. That that tracks. Is there anything about Deno 2 that we didn't cover that you wanna make sure people know? For one thing, we have workspace support. We support NPM workspaces as well as our own form of NPM workspaces in your DenoJSON file. So you can you can have kind of your monorepo set up with multiple packages there. And that all works very well with JSR if you're, like, publishing a a bunch of different things. Deno is going to release a, long term support version. We've been working on Deno for a while. It is stable Node. And I I think, you know, we wanna make that explicit to people in in Deno 2 and kinda give people explicit guarantees about long term support. People can can look forward to to that. Basically, Deno Deno 2 is is kind of our our marker that like Deno is ready for production, ready for use cases.

It is not going to be changing majorly post Deno 2. I do not see a dino 3 in the future. Wes put a lot of thought into how we can intersect better with reality.

We're pretty happy with it. So so, Yeah. People should look out for for the dino 2 release,

later this year. Alright. Next section we have here is sick pick, and shameless plugs, what do you got for a sick pick for us? Last time, you sick picked flying a kite, and you live in New York City, which I I still remember that Bos for some reason. I thought it was such a good sick pick, but curious what you have today.

Similar, which is hanging out in McCarran Park, here in in Brooklyn. I would like to bring a blanket over there, get the babies get the babies out, maybe have a beer, and chill on a Saturday is is my sick pick.

That's awesome. I'm just looking at photos of it.

New York is so cool. Man, I need to come back there. That's cool. Alright. I guess I have one of those. Going back there. Yeah. Yeah. Yeah. Although November.

Yeah.

Right on. And, shameless plug, what would you like to plug?

Deno for enterprise.

So if if you're if you are using Deno at a bigger company and you would like some support, make sure that that, things are running well and and kinda get a direct line to us. You can go to deno.com/enterprise.

Fig.

Cool. Wes, thank you so much, Ryan. This has been awesome. It's always awesome having you on. And, thank you so much. Yeah. Thanks, guys.