Deno 2 with Ryan Dahl

stuff, but it's not going to tell us the types in JavaScript are string number, universal the proposal for types as comments to be added, Wes maybe TypeScript is not the endgame of this type JavaScript Wow. Wow. That's exciting. And what JS the process of supporting

syntax.

system. They imagined Mhmm. You know, everything moving to WASM, you know, fastly, famously,

and has no enums? really big in the as part of the JavaScript syntax, is simply for you to add

yeah, quietly in the background, like, there there is there is a a real interesting thing happening in kind of the data visualization 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, 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.

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

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 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, And and, we've been working on this for essentially, like, 2 years now. At this point, Deno is 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 it works really well, especially combined with observable plot, which is kind of the successor to to d three, Mike Bostock's, we 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, file system API out there. Yeah. We we have a standard library in Deno that's on JSR,

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,

care. I guess I I do avoid 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 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, 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,

yeah, I, what work. Yeah. These these days, I'm pulling in, Pandas.

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 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,

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

the idea of simply just requiring

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

Right on. And,

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.

Yeah.

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.

yeah, we're building we're building Deno for for the future.

implementing

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.

software. And Deno can consume

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.

of the TypeScript little game that is, you know, a GPU accelerated thing written in JavaScript. So that that is a a pretty fun little container

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

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 CloudFlare workers, and that people are wanting to write JavaScript that, you know, targets, 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 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.

any other stuff there. And so there's people developing little games and stuff, which then combined with Deno compile

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 Oh, okay. Yeah.

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

Similar, in all its its granularity.

ML professionals 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 of of Deno. I feel like I should give you some links for for this.

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

unstable API, Deno, that allows you to attach this to a frame buffer and like actually display a window that renders Wes GPU beyond to to to, like, make those models area of JavaScript. And and, yeah, I I hope to see the day when when, 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 essentially anybody can implement. There will probably only be 1 implementation JSR. You must use ESM. I I think there's no going back. Like, should be pretty simple as well. If you're using 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.

doesn't 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, is

maybe 6 months ago,

type checker, which is the TSC,

have a file Importing but I think the industry got overexcited

What was the idea behind that? And then,

significantly easier because there's not a whole bunch of steps to

Process global.

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 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

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

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, 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 Node has 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.

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?

JavaScript plus types, You Node, maybe a simpler version of of JavaScript plus types that doesn't support all of the intricacies 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, ESM

What do you think about BUN

place where you can, you know, compile ImageMagick yeah, I mean, from my perspective as as kind of the the runtime I guess I I don't, particularly

It should also make the like, like, talk about deploying it and and hosting it. It should make the deployment

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 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? as well as our own form of NPM workspaces in your DenoJSON 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.

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

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 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

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.

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,

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.

TypeScript 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, 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

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

I think for for those you

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?

rolled out unstable support for

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, 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, 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.

long URLs of that reference dependencies in into kind of short bare specifiers.

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.

New York is so cool. Man,

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

straightforward 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

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 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

that that comes out and that has a 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

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, 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 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

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

And so,

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.

Fig.

performance 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.

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,

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

built kind of a a WASM edge service.

as far as I I don't know if that's changed. But so it's not necessarily clear that a file system

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

do the things that people imagined it doing. They imagined it as kind of the next generation 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

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

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,

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 about it too soon before it was mature enough to really or just a little bit more thoughtful.

FS APIs as a node package

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.

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, generally the standard library for for JavaScript.

on

the academic world. People use Jupyter Notebooks

into binary and,

for writing Python and being able to display.

support. People can can look forward to to that. Basically,

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 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

I think Deno's approach is great, though. I mean, your applications are going to work

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.

replaces Python for for all of these use cases because it is frankly a better language.

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 that is is that file system is is something that should be standardized.

compatible way of of sharing modules.

make sure that that, things are running well and and kinda get a direct line to us. You can go to deno.com/enterprise.

which is hanging out in McCarran Park, here in in Brooklyn. I would like to bring a blanket over there, you can expect, I don't know, 2 x improvement.

Deno for enterprise.

Jupyter Notebooks.

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

importing the TypeScript.

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, that does support npm dependencies. You can publish packages that can depend on common JS packages in npm, way? I hope. I I possibly.

how we can intersect better with reality.

I I almost wish that the and maybe this is even a thing. Just, like, publish

Frankly, I I don't know. I I could definitely see a future where super, super nice to work with. So, like, the visualization side

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

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

What would I gain NPM and and that look like? I Node, initially, a full type checker that's built in Rust

the Deno

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,

But Deno is very, very fast. So if you compare, say, express throughput get the babies get the babies out, maybe have a beer, 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 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.

subcommunity 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 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.

if somebody somewhere is using a require.

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, that has very few configuration files, if any, and, yeah, you know, web standards forward.

So Yeah. Well,

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, 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?

a pretty great experience, and and I hope you know, the the long term goal here is is that we we could actually and data frame data frame library for kind of dicing and slicing datasets.

like JS 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

And so we recommend people use import apps actually for defining dependencies and and kinda mapping

syntax. Again, we've been using this tool for a long time, and it totally rolls. Alright.

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?

there are iterations Deno Deno 2 is is kind of our our marker that like Deno is ready for production, ready for use cases.

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

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 compile everything and cache things and and whatnot.

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

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 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, 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,

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.

have workspace support. We support NPM workspaces

Deno APIs

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 That's awesome. I'm just looking at photos of it.

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

the TypeScript as it was authored seems so beautiful to me.

execute,

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

shameless plug, what would you like to plug?

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/

opinionated,

is just software infrastructure relies so heavily on the browser.

I I like it because one thing you just said that got me really excited is you're gonna be able to use Next. Js with it. So

where the the new Rust version of of, of pandas in in Jupyter.

go on. WASM is a great idea, 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 JavaScript 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, 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

Oh, importing the file here in here.

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, that is So if if you're if you are using Deno at a bigger company and you would like some support, Node, hopefully, the types JS comments leaves room for iteration 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.

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 I'm, author, I just try to make it work for for people, what what they're writing in in in TypeScript. I am not 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 Ideally, will work across everybody, maybe not Cloudflare workers, maybe not browsers since they don't have file for this Node. So,

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

This is beautiful. Right? Rather than just worrying about, whether I should use PIP or Anaconda or, 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 We're pretty happy with it. So so, Yeah. People should look out for for the dino 2 release,

integrating with with Versus Code. It gives you, your your linter, your formatter. It gives you Deno compile. It gives you type checking. Like,

tell me about what Deno 2.0 looks like.

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

Done.

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 just

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.

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

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

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

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.

that they are just reimplementing the API and And, yeah, you don't need to learn

And, like, we are pursuing simplification

getting really close. Like, it's kind of a long tail situation where it's going to be impossible to support everything infrastructure 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.

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,

file system APIs. So, like, how do you even tackle that once you have the thing down? 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,

the entirety of Do you think we need to do something aggressive or just kinda ride it out for another 6 years? 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 That's that's awesome because, honestly, that's

Yeah. Yeah. Absolutely. And the one thing that I think a lot of people have appreciated about

web standards Vercel. But it it feels like

and package JSON that aren't necessarily 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 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 enums. But, 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,

since since 2009. And,

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?

all of these ways of operating with Node modules, folders,

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 It's going to obviously have you know, be based on promises and and, 408 loops and and async iterators.

Yeah. All the the frustrating parts of getting it all running. I often talk about this

JavaScript has grown tremendously

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.

the default programming language and deserves a great future.

Deno is the fact that it is using

but we we do a hard break. You cannot publish or require common JS stuff to to, move

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 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

Yeah.

the alternative is just arduous years of of, like, an in between state that, Toast that I I think doesn't benefit anybody.

it can use common JS. And so, you know, in in in some ways, we are pretty religious and, I because there there there is just a lot of

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 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.

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 For one thing, It kind of intersects very poorly with reality because, TypeScript complete.

I'm curious about, like, what parts

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 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.

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.

so you can load node native node extensions, and those will work in Deno. So if if somebody's programming against an API, on on this and doesn't kind of and chill on a Saturday is is my sick pick.

that will work. The SQL SQL lite 3 package on Npm

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, against node,

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

in Node

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

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, allows you to ship a 60 megabytes

uses a Libuv API that is not part of the the n API.

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.

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

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,

of the the Node project.