Deno 2.0 with Luca Casonato

0:00Dino is a free and open source JavaScript runtime built on Google's V8 engine, Rust, and Tokyo. It's designed to offer a more secure and standardized alternative to Node.js, with native TypeScript support. Dino 2.0 just released, and it's a significant update, focused on improved compatibility with Node.js and addressing developer feedback. Some of the key features are backwards compatibility with Node.js and NPM, native support for package.json and Node modules, and a stabilized standard library. Luca Casanato is a software engineer for Dino, and he spoke about the project on Software Engineering Daily in 2023.

0:38We're excited to have Luca join the show again to talk about the many changes introduced in Dino 2.0. Kevin Ball, or Kate Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow KBall on Twitter or LinkedIn, or visit his website, kball.llc.

1:20Luca, welcome to the show. Hey, thanks for having me. Yeah, absolutely. Excited to have this conversation. Let's maybe start. Do you want to, I know you've been on the show before, but maybe reintroduce yourself to our listeners, who you are, your background, and what your role is with Dino. Yeah, so I'm Luca Castanato. I work on Dino. I've been at the Dino company for four years, working on all kinds of stuff there. Initially, the website, documentation, then I moved into working on the open source runtime. I then spent a year and a half leading our Dino deploy team that builds our cloud product.

1:54And now recently have worked more on JSR and our new JavaScript registry. Well, yeah, not really Dino's project, but something that we've initially worked on. and then yeah Dino 2 most recently getting that release stripped. So let's talk about Dino 2. What's in it? What's in the box? What makes this a major release? Yeah so Dino 2 is Dino's like we're ready for enterprise release. You can use Dino. So Dino's existed for I don't know I think we did a 1.04 years ago if I recall correctly it was in 2020 May 19th. I don't remember but it's been a while and since then we got a lot of feedback from people that like Dino is a pleasure to use and they're really enjoying it.

2:35And it has like a bunch of built-in tooling, which it does. But there was also a lot of feedback that was things along the lines of, oh, I can't use this at work because I have a giant node project that like I can't move to use Dino overnight. And that makes sense. So, I mean, we spent the first four years trying to figure out like, where's the ideal? Like, what do we want to go to? How should the ideal JavaScript world look like? And then over the past year and a half, two years, we've been trying to figure out how do we make this work in a way that existing users with existing projects and existing frameworks and existing libraries can adopt Dino sort of in an incremental way.

3:09And Dino 2 is the release that does that. You can create an XJS app on your computer and run it in Dino and it works. With no changes needed, it just works, right? But you still get access to all of Dino's built-in tooling, like the linter and the formatter and the test runner and the coverage reporting and all that kind of stuff that the language server but yeah you can sort of do this on existing projects you don't have to create a new greenfield app to get started with so that's really what you know two is all about got it so i know a few of the things that were making it a challenge to adopt because i also looked at it back in 2020 and i said this looks really cool and also i could never pull this in but do you want to like maybe spell out what were the pieces that weren't there if you were using it before and that now if you come to dino two they'll just work Yeah, absolutely.

3:57So one of the biggest things that Dino 1 didn't really do is node modules support. So the node modules folder and NPM packages. So Dino has its own API surface that is modeled more after web APIs than after node APIs, because web APIs are generally more modern, right? They use promises and async await and like iterators, these kinds of things and not like legacy node streams. and a lot of those things unfortunately are new and thus there's a lot of old code that can't use them because they're using node apis so one of the things you know too is we added support for all the built-in node modules so think of like nodefs node crypto node i don't know v8 node vm node inspector all these things that you can require or import into your code you know just implements them out of the box now with exactly the same api surfaces node which means that if you have existing libraries that are written against those APIs, you can just use them now.

4:50So that was the first big part. And then the second big part was the ability to understand node modules. So Dino and Dino one has an ability to load external modules, obviously, but it doesn't really use node modules because we consider node modules to be sort of clunky. You have to set up a package JSON, you have this folder in your repository that you need to deal with. You have like a bunch of different lock files, you have like four different package managers you need to choose from, right? It gets very complicated very quickly. So we had our own module solution that is based on web standards, based on like HTTP imports, and more recently on JSR.

5:24But yeah, so in Dnode 2, you can now also just import any NPM package. We understand your local NodeModules folder. So if you want to move over to this like pure future where you don't have to deal with lock files and NodeModules folders on your disk, you can. But by default, we understand those out of the box now. And then the third thing is Dino now has a lot more package management built in. Previously, users may have used import maps to Dino, which is a web standard to help manage dependencies. But now Dino supports package JSON, and it can create your NodeModules folder from your package JSON.

5:59So it has the NPM install functionality baked in. We can read things from your private NPM registries, things like that. So it's really a lot of things that just make it easier to pick up and stick it into your existing project and just have your existing project work. Yeah, it's kind of the plays nice with others release in some ways. Exactly. Yeah. I'd love to dig into a few of those pieces. So one, you mentioned sort of support for some of these built in node modules and node APIs. And I'm curious, like, how do you see the evolution of server side JavaScript runtimes? Like, is there a server side standardization effort?

6:37because browser APIs, everybody's trying to agree on what those look like. Server side, what is that story? Yeah, that's a fantastic question. The answer to that is something called WinterCG, which is an effort that Cloudflare and Dino and some folks from Node.js as well, some of the runtimes joined up to create a community group within WhatWig a couple of, I guess it must have been two years ago at this point, to try to figure out what is the common subset of APIs that all these server-side runtimes should have. And currently, a lot of this common denominator is Node APIs, but really, in the limit, I don't think the world really wants to continue using Node FS APIs that were designed in 2008, right?

7:19Not a great time. So we're trying to figure out there two things. What web APIs are there that should work in servers and how should they work? So take Fetch or the Web Crypto API. And then the other thing is, what features are there not web APIs for that should work in service at runtimes interoperably using modern APIs? Think, for example, of TCP sockets or like things, how to read your environment variables or arguments past your script, things like that, right? So those are another part that WinterCG is trying to figure out, like, what is a common API that we can use here? And we're like an open community group in the W3C that anyone can join.

7:57and like sort of, yeah, we have contributors from all over trying to figure this out. And what would you say the sort of state of maturity is there? Like, is this something that all of the runtimes are already kind of in line with, or are we still hashing out and trying to get to some sort of consensus at all? So different parts are different levels of maturity. I think we've collectively agreed like what the baseline set of APIs is that everyone implements, like everyone implements fetch now, everyone implements response, request, headers, Web crypto broadly as well, maybe more obscure APIs like A to B, B to A, sort of things like that.

8:35We've collectively agreed on those on the APIs that are like novel APIs that are not web APIs. I think there's more work to be done there. We don't have any release standards yet or has anybody implemented them. I think the closest thing we have is the Sockets implementation in Cloudflare workers, which is sort of going in the direction of sort of where we want the WintersCG Socket API to go. But yeah, this is still very much something that is going to take a year, maybe longer to develop into something that can be actually shipped across runtimes. And like a lot of this is not even just designing the API, but it's also like writing tests to make sure that it works interoperably everywhere.

9:14and then obviously like getting user feedback, talking with all the database connection library authors, like think of your PSQL, like Node Postgres or like MySQL or I don't know, those kinds of things to then go and actually adopt them in their libraries, right? That's the step after that. So yeah, more work to be done, but yeah, we're making progress slowly. It's standards after all. Absolutely. Well, and it's a measure of maturity that that working group exists at all. Absolutely. means that we're more likely, I think, to see evolutions and more people trying to create these runtimes. Where do you see the sort of dimensions of competitiveness in runtimes?

9:56Why would someone choose a Deno versus a Node versus Bun versus WorkerD versus whatever? Yeah, I think part of it is obviously like WorkerD, for example, you can't use WorkerD unless you're running on Cloudflare. Makes it very easy. If you want to develop for Cloudflare, use WorkRD because that's your only option. And if you're not developing for Cloudflare, you don't use WorkRD because you can't use it, right? But between these other ones, I think it's a lot more nuanced. It's like broadly, there's a lot of things that are very similar across them. I think one thing that's wildly different at this point is stability.

10:26Like Dino and Node have been out for a long time. We've like the first commit to Dino was, I think six years ago at this point, all the bugs that we get are like things that we've done recently. It's like not old features, like all the old features, they work perfectly fine at this point they're stable. Another one is tooling, right? Like Node has some tooling within, but it's much less than let's say Dino. Dino has a built-in format and a built-in linter. It has benchmarking tooling. It has a built-in language server. It has TypeScript support out of the box. I could go on about this. It has like compiling to a single executable.

10:59We've had that for nearly four years at this point. So I think that's a lot of that. And then the other thing is like, are there things around it that would entice you to use one runtime over another? So for example, are there libraries that you would like to use that favor a particular runtime? Or are there frameworks that favor a particular runtime? For example, like if you want to use Fresh, which is a web framework that Dino has been working on, you probably want to use Dino, because that's what it was built for. But yeah, conversely, I don't know if you're using Elysia, that may be something you want to use Bun with, because that was built for that.

11:31But yeah, really, I think I don't know, I'm going to use Dino, but I'm also biased. So everybody make up your own mind. Try out things. They're also easy to use now. Totally. Well, and one of the things that you alluded to there, which is a kind of perpetual question in the JavaScript ecosystem is like the extent to which you get everything together in one. Dino bundles a lot of pieces together for you versus are you doing mix and match and are you making your own choices on all those different pieces? I'm kind of curious how Dino approaches this question of what should be bundled with the runtime versus what belongs in user space?

12:08Yeah. So the inspiration for why Dino has all these things built in is not the JavaScript ecosystem, surprise, surprise. It's the Go ecosystem, the Rust ecosystem. These are languages Go was released, I think the same year as Node.js. But unlike JavaScript, it has a bunch of built-in tooling, like in its tool chain, when you install Go. It has a built-in formatter, it has a built-in linter, it has a built-in package manager, has all these things that sort of come right out of the box. And it turns out that people really, really like this. If you ask people what is great about using Rust, one of the top answers is going to be like, it just works out of the box, right?

12:43Like I can have a GitHub ActionScript that installs Cargo. And then that comes with a formatter and a linter and a testing framework and a benchmarking framework and a package manager. And like it compiles my code and all that kind of stuff all at once. And that's really what we were going with, with like having all these things in Dino natively. I think the question of like, what do we actually decide to include is what do we think we can do well? Like formatting, we think we can do very fast, very good formatting. So that's something that we built in. We think we can do the same for linting, testing, benchmarking.

13:17In Dino 1, we had a bundle sub command that would like take your JavaScript code or TypeScript code and bundle it into a single file. But we realized that this was like not where we wanted it to be. Like bundlers are incredibly complicated and we did not think that we could at this time at least offer a competitive bundler built into Dino. So Dino 2, we removed it because we don't want to ship like something that's sort of half baked and doesn't really work very well. We want to ship things that like you can rely on them, right? Like you don't have to think about whether you should use them or not.

13:48You can just use them because they work, they're stable. And our bundler was not that. So yeah, we removed it. But other than that, I think, yeah, things that we think we can do well. Those are things that we'll include. Yeah. Things you can do well. And you mentioned a little bit the simplicity piece, which reminded me of, I was looking at, I think it was a release YouTube video you all did where you were really going after Node around simplicity. I'm kind of curious, as you absorb more and more pieces to be able to be enterprise ready or plug and play, how are you approaching sort of keeping the experience simple?

14:23Yeah, I think the biggest part of that is having good defaults, right? Like our defaults are, take for example, TypeScript. When you set up a TypeScript project in Node, you don't just have to open a file and write some TypeScript code in it. You have to set up a tsconfig file and you have to make like 18 decisions, right? You have to decide, do I want strict mode on or off? What libs do I use? What version of types node do I use? Like there's an endless amount of configuration that you have to do before you can write the first line of code, which makes things very not simple, because that means between two projects, even in the same company, you can have wildly different configurations.

14:59And like before you can start reading code, writing code, you first have to go look at all the config files to see how this project is set up. That is one of the things that Dino completely eliminates. Like we have a config file that you specify dependencies in if you want to. You don't have to, you can. And other than that, you don't have to have anything in there for like a standard project, You don't have to set up your TypeScript config. There's a default TypeScript config that all Dino projects use that is like all the options you should use, not the options you shouldn't use. We've made this decision for you.

15:29Don't worry about it. The other part of it is if there's parts of Node that we sort of need to put into Dino for backwards compatibility, we try to shield you from them if they're bad in some way. Like we don't, for example, encourage you to write CJS code in your project. We encourage you to write TypeScript code with ESM. And that doesn't mean you can't use CJS. You can. But we very actively steer you in the direction of using ESM. right to sort of adopt modern tooling use libraries that are actively maintained and not outdated we have a lot of documentation that tries to guide you to do things in modern ways like all of our documentation on if you look up like how to make an http request from dino it's going to show you how to do with fetch not with node http because that's the future right using fetch not using node http a lot of things like that just make things much simpler yeah you sort of alluded to this when you talked about the typescript versus cjs but i'm curious so a lot of very opinionated frameworks, we'll provide you an escape hatch where they say, we're going to have these defaults for you.

16:33We highly recommend you go with it. But if you really have some strong reason to change it, here's how you do that. What does that look like in Dino? Yeah, I mean, we, for many things, have that same option. There's a, like, as I said before, we really want you to write ESM and TypeScript, but you don't have to. You can write a.cjs file and you can write a, like,.js file rather than a.ts file if you want. And we'll let you do that. And if you really want to turn off, like, I don't know, trying to think of some obscure TypeScript option, no implicit any, I don't know. You can go into your Dino config file and find the place to turn that off.

17:07But you shouldn't. It's there for like you're migrating an existing project and you like temporarily need this for a moment, but stop. Don't do it. Stick with the defaults. Don't do that. Bad. But that is really important for migrating legacy stuff because you never know what you're going to run into there. Yeah, no, absolutely. And I mean, that's really why we've added a lot of these escape patches in Dino 2. Dino 2, for example, has the ability to work both using a local node modules folder that was created by Dino, work with local node modules folder that was created with like NPM or PNPM or Yarn, or work with our global node modules folder where you don't see the node modules folder at all because it's like hidden in a cache directory somewhere.

17:46And the default is to use the global one because that's nice and clean and you don't have to deal with it. But sometimes if you're like in a existing project that has a complicated PNPM workspace or like a Yarn workspace with Yarn resolution plugins or I don't know, crazy things, right? Crazy big project with weird configuration. Dino will just accept that and it will work with your existing node modules set up, node modules folder that was not set up by Dino as MISK patch. And at some point, if you decide, OK, I'm all in on Dino, you can like start making that move, right? You could like switch over from Yarn workspaces to Dino workspaces and then have Dino install your Node modules folder and maybe eventually completely get rid of all your local Node modules folders and just have a global one.

18:28But it's not something we force you to do right away. You can sort of adopt it incrementally and then over time move to this nice pristine world of no Node modules folders. Can you tell I don't like Node modules folders? I can't. Well, and let's talk a little bit about modules and registries and things like that, because another big thing that came out this year was, or at least that I saw an announcement about this year was JSR. What is that? Why is that? And how does that interact with Dino? Yeah. So, I mean, the reason Dino was created initially was Ryan Dahl, the creator of Node, came back to Node after 10 years and thought, okay, this has gotten too complicated.

19:06And I mean, a similar thing happened with NPM. So NPM is obviously Node's package management system where you like publish your packages. And there's been a lot of innovation on the client side, the package manager side of this. We initially had only NPM. We got Yarn. We got PNPM. Now, there's a bunch of other tools that will also let you install NPM packages faster, better, more securely, whatever. But we really didn't have anybody that was pushing NPM the registry. If you look at NPM the registry, they really haven't changed in 10 years, right? The last major change they did was added a little TS icon in the top left to packages that have type definitions.

19:46And that was what, like three years ago? And then they have a files tab that's been in beta for probably also three years that when you click on a file, it doesn't put the file in the URL. So you can't like link to it. You can tell that there's not been like a lot of active investment in NPM. So that's what JSR is about. JSR is a new package registry. So the server side part of the packaging story where you can publish your packages to. And JSR natively supports TypeScript. JSR packages can import from NPM. They can be imported by NPM packages. But yeah, they natively support TypeScript. They have built-in documentation generation.

20:21They have a much more secure publishing flow that uses OIDC on GitHub Actions to sort of prevent people from accidentally leaking private access tokens, which is, yeah, supply chain security. I'm sure many people are worried about that in the JavaScript space. It's really a head-on attempt to try to fix all the things that NPM hasn't done in the past 10 years. But yeah, doing it in a sort of backwards compatible way where you can import JSR packages from NPM and import NPM packages from JSR so that these things can work together and it's not like a stop the world and migrate sort of thing. Reminds me a lot of Pika, which I don't know if that project ever went anywhere, but I remember talking with Fred K.

21:03Schott or listening to a podcast with him trying to do this, where at least in that world, part of it was trying to push to being ES modules first. And it sounds like with JSR, similarly, you're pushing for TypeScript first. Yeah, like JSR is very much TypeScript first, JavaScript supported, but TypeScript first, and then ESM only. So you cannot publish CJS to JSR, for example. We've made a hard cutoff, like stop CJS development instead, ESM only going forward. And that allows us to do incredible things that you could never do if you have to do with CJS and ESM and not TypeScript, like documentation generation.

21:40The fact that for every package that is published to JSR, we can automatically generate documentation for every symbol, for every export in your package. It's huge. It's like Rust has had this for 10 years, Go has had this for 10 years, and in JavaScript, we've never had this because NPM didn't implement it and it's not an open source project so nobody can implement it for them right it's like a closed source private thing that github is keeping alive and jstr is yeah different it's an open source project it's hosted by the dino company but really it's a very open project where you can contribute things and if you want to have a new tab on the package page that shows you some cool new information it's a bit of pr right it's not behind a locked door and you need to become a Microsoft employee first.

22:22Yeah. So you mentioned that you can install NPM packages with JSR. How do you deal with NPM packages that were not TypeScript, for example? Are they not installable via JSR or like, how does that work? Yeah. So NPM packages, you don't install NPM packages like through JSR or JSR packages through NPM, but rather they're complementary. And in the way that NPM packages can rely on JSR packages, like they can depend on JSR packages and JSR packages can depend on NPM packages. But ultimately, it'll be your package manager like PNPM or Yarn or even NPM itself that pulls the JSR packages from JSR and the NPM packages from NPM.

23:01And this is just done through like, you can think of JSR as like a private registry of sorts for NPM if you're using NPM. And that way, you can use all existing NPM packages, whether they're TypeScript or not, But you only get the features, the documentation generation, for example, if you're actually publishing to JSR. So if you're publishing your TypeScript source code to JSR. That makes sense. You mentioned documentation generation. You mentioned some of the supply chain security. Are there other benefits of going to JSR over NPM? Yeah, it's a lot simpler. I mean, at least in my opinion. You can create a package by, like the simplest package is a single TypeScript file and a JSR.json that has a name, a version, and an exports field.

23:46And the export field is just the path of your TypeScript file. And that's it, right? There's no tsconfig to set up. Very importantly, you publish the TypeScript. You don't have to publish like the JavaScript plus d.ts files. No, you publish the TypeScript. so you can like publish a new package in a couple minutes rather than like having to go through and set up the configuration and make sure that it works across cjs and esm and all these things right jssr just handles all that for you so i think a lot of it is like really it makes your life a lot easier if you don't have to deal with all this configuration kind of a recurring topic recurring topic well is that showing up anywhere else that we haven't talked about yet for this Yeah, sure.

24:28Dino Deploy, we can talk about that very briefly, is our cloud hosting product. Same sort of deal, right? You can write your JavaScript code, put it in a GitHub repository, and just link it to Dino Deploy. And it deploys, and you don't have to deal with configuration. Like a lot of the things that we do at Dino are like this. Our linter is like this. You don't have to configure your linter. You don't have to configure your formatter. You don't have to configure your tests. You don't have to configure your editor. You don't have to configure your package manager. It just works out of the box. And you can tweak it if you want to, but don't.

25:00Just stick with the defaults because the defaults are pretty good. Speaking of Dino Deploy, and I think one of the interesting things that you all have is you have this dual identity as open source projects, multiple JSR, Dino, all these different things, but also for-profit company. And I think one of the challenges going back to NPM that they faced is when they started running out of money and then Microsoft absorbed them and then stasis ensues. So how is Dino making itself sustainable here? Yeah, I think the answer is different for different parts of Dino. I'll start with JSR. So with JSR, we don't want JSR to be a Dino product.