The Changelog: Software Development, Open Source - Leveling up JavaScript with Deno 2 (Interview)

Episode Date: September 26, 2024

Jerod is joined by Ryan Dahl to discuss his second take on leveling up JavaScript developers all around the world. Jerod asks Ryan why not try to fix or fork Node instead of starting fresh, how Deno (the open source project) can avoid the all too common rug pull (not cool) scenario, what's new in Deno 2 & their pragmatic decision to support npm, they talk JSR, they talk Deno KV & SQLite, they even talk about Ryan's open letter to Oracle in an attempt to free the unused "JavaScript" trademark from the giant's clutches.

What up nerds, I'm Jared and you are listening to The Change Log, where each week we sit down with the hackers, the leaders, and the innovators of the software world to pick their brains, to learn from their mistakes, to get inspired by their accomplishments, and to have a lot of fun along the way. On this episode, I'm joined by Ryan Dahl, creator of Node.js and Deno, his second attempt to level up the world by leveling up JavaScript developers all around the world. We cover a lot of ground. I ask Ryan, why not try to fix or fork Node instead of starting fresh?

How Deno the open source project can avoid the all too common rug pull not cool scenario? What's new in Deno 2 and their pragmatic decision to support NPM? We talk JSR, we talk Dino KV and SQLite. We even talk about Ryan's open letter to Oracle and his attempt to free the unused JavaScript trademark from the giant's clutches. But first, a thank you to our partners at Fly.io.

Over 3 million apps have launched on Fly, including ours. And you can too in five minutes or less. Learn how at fly.io. Okay, Ryan Dahl on the changelog. Let's do this. What's up, friends? I'm here with a new friend of ours over at Assembly AI, founder and CEO, Dylan Fox.

Dylan, tell me about Universal One. This is the newest, most powerful speech AI model to date. You released this recently. Tell me more. So Universal One is our flagship industry leading model for speech to text and various other speech understanding tasks. So it's about a year long effort that really is the culmination of like the years that we've spent building infrastructure and tooling at assembly to even train large scale speech AI models. It was trained on about 12 and a half million hours of voice data, multilingual, super wide range of domains and sources of audio data. So it's super robust model. We're seeing developers use it for extremely high accuracy, low cost, super fast speech to text and speech understanding tasks within their products, within automations, within workflows that they're building at their companies or within their products. Very cool. So Dylan, one thing I love is this playground you have. You can go there,

assemblyai.com slash playground, and you can just play around with all the things that is assembly. Is this the recommended path? Is this the try before you buy experience? What can people do? Yeah, so our playground is a GUI experience over the API that's free. You can just go to it on our website, assemblyai.com slash playground. You drop in an audio file. You can talk to the playground.

And it's a way to, in a no-code environment, interact with our models, interact with our API to see what our models and what our API can do without having to write any code. Then once you see what the models can do and you're ready to start building with the API,

you can quickly transition to the API docs, start writing code, start integrating our SDKs into your code to start leveraging our models and all our tech via our SDKs instead. Okay. Constantly updated speech AI models at your fingertips. Well, at your API fingertips, that is. A good next step is to go to their playground.

You can test out their models for free right there in the browser. Or you can get started with a $50 credit at assemblyai.com slash practical AI. Again, that's assemblyai.com slash practical AI. All right, I am here with Ryan Dahl, creator of Node, and more recently, but not that recently, it turns out, Dino. What's up, Ryan? Hey, how's it going? It's going well. Thanks for joining me. You know, I was just on YouTube checking out some of the Node documentaries.

I think Honeypot put up a new one that's a little bit shorter about the origins of Deno. And I was looking like 600,000 people watched the Node.js documentary. I think the new one has thousands as well. And I wondered, did you ever think this would happen to you? Like just for slinging some C++ code and putting your ideas out there, you're kind of an internet celebrity now day after day it continually surprises me i it's just you know i like every year like this is how big node will be right and then you know the next year it gets bigger and bigger uh it's it's uh yeah a privilege to have worked on on this well well deserved and of course, not just yourself, hundreds, scores of people working on Node over the years. And of course, Deno, you are primary on Deno, but a team over there as well. And gosh, I said not too recently, because you've been working on Deno a long time now. Hasn't it been like six or seven years? in 2019 and just kind of got off to a slow start demo for a conference.

But yeah, it's been plugging away at it. Yeah. And we are on the edge of Deno 2 now. So you're going to have an official 2.0 launch pending coming very, very soon. It's in a release candidate, so I'm sure people can get out there and use it right now today, right? Yeah, it's basically feature, yeah, the release candidate is almost exactly what will be there. Yeah, we released Deno 1 back in 2020, so it's been four years now.

We've talked a lot about, we thought about this for a while about what to do for Deno 2 and teased it multiple times, but always kind of pulled back from it because we're like, yeah, actually, no, it's missing this. We're not sure.

Like we have to, so we've thought long and hard about this release. And yeah, I'm excited to finally get it out there. The cool thing about Deno and its origin was these 10 mistakes I made with Node in that conference talk, like you mentioned, and then this was your second effort to rearrange the letters, start fresh, fix some of those mistakes. But you've been working on Deno now for seven years. And so I'm not saying there should be a third effort, but like, are there things you've

learned about Deno or do you have Deno regrets at this point? It's been long enough. Everybody has regrets, right? Sure. I mean, there are things that i said in that original talk that dino 2 actually goes back on so for example like introducing the process global variable is is i think uh you know one one of the the things i regretted about node turns out like yeah i i think the we're just kind of hitting reality with with you know how big the npm ecosystem is and just realizing that and this is this is kind of a big part of dino too is is just realizing you know if you're going to if you want to be able to pull in some random npm library like grpc which you definitely want to be able to do because it's super complicated and like you're not going to rewrite that you have to be pretty close you have

to you know basically implement the node built-in apis and although we look at this very carefully and still have a core philosophy of leveling up javas JavaScript and narrowing the gap between server-side JavaScript and browser JavaScript and looking to the future of JavaScript. Deno is not a re-implementation of Node in Rust. There is work that has been done to be able to import NPM packages and be able to run Node projects out of the box. And yeah, at this point with, with Deno too, like it's pretty great. Like you can basically drop into, uh, most node projects, let's say modern node projects if they're using ESM, uh, not if they're using common JS and, uh, use, use Deno with them. So you initially started with a clean cut from NPM as well with your own URL based imports. And you since had, I mean, you

basically had to do that stuff because there's so much, like you said, there's extant code out there. There's packages that you just don't want to have to re-implement on the Deno side, because let's be realistic. I mean, when Node came out, I remember that first call to, for contributors that you gave. And it was like, come create things for Node.js because it was available for use, but there was no standard library, there was no code there to use,

and people did. It was amazing. I mean, it was like the frontier of web development server-side was, make a Node package for this. I mean, the person who made the gRPC package initially, of course that was probably years later, the person who made the gRPC package initially, of course, that was probably years later. I'm not sure when gRPC became interesting to folks,

but that person, it was Greenfield. And they were probably highly motivated to do that. But nowadays it's like, well, I already have Node. I have a gRPC over here in NPM. It's now a barrier to Deno, right? It's no longer Greenfield. It's like, do I want to rewrite this or port it over? And so when did you guys make that call?

And was that a tough one to finally? It's a pragmatic choice. You have to kind of ditch a little bit of the pure idealism of the fresh start, right? Yeah, a very, very difficult decision to be made after wringinginging our hands over over long periods of time yeah i mean the original idea with the dino module system is uh let's follow the esm spec exactly let's follow exactly what browsers do and browsers allow you to have hgps imports in there and local imports and can we actually like build an entire module system on top of that? The answer is yes, you can. And it works pretty nice. Like it's pretty great, especially for like single file scripts and kind of small little programs, you can you can just kind of drop in some imports

in there and get off to the races pretty quickly. It gets problematic as you kind of scale up in complexity. And in particular, when you need to interoperate with different systems, right? When you need to pull in the AWS SDK, right? Like there's just some things that you are not going to rewrite. And, you know, I think we've found a middle ground here

with like NPM specifiers where, you know, we're still staying true to the ESM spec. These are still URLs, URIs in in that it's NPM colon express. Yet, in order to pull in NPM packages, it's much more complicated than the HEP specifiers. I mean, the beauty of the original Deno vision was like, oh, this dead simple resolution scheme

that really makes it easy to interoperate with. If people implemented this, it makes it very easy to interoperate with stuff. And yeah, frankly, the reality is that works to some scale, but we're interested in making software for lots of people. And I'm not satisfied working on a runtime that 500 people can use for small scripts. I really want to make software for millions of people.

And server-side JavaScript is truly millions of people. I'm pretty convinced that you need to be able to pull in NPM modules and understand package JSON and implement the node built-in modules in order to make any progress. Otherwise, you just face this boil-the-ocean problem. Yeah, exactly. And you have to meet people where they are for them to actually benefit because you're trying to make software that's A, used by the mass developers and B, has to then be useful to all of them or many of them.

You're not happy, like you said, writing a niche runtime that 500 people use. Back in the day, go back seven years, I know you had this initial idea and it was like, I think in that, in that initial speech, you said that Node kind of offended some of your sensibilities over time. And I know there's a lot of personal history there and there's, you know, job related stuff and lots of baggage there, just mental baggage. I'm sure it was just more fun to start fresh with something else. But now that you're like competing with your previous creation in terms of getting people to use Deno. And that's probably an uphill battle because Node is established

and it's like the de facto. And it's probably hard to move certain people. Is there an alternate world where instead of starting fresh that you just said, like, I'm either going to fork Node and start from there and change these things, or I'm going to rejoin

the Node technical steering committee and like, I don't know if that could have even happened, but moved it in a direction. Because then you wouldn't have to regain all these users. You'd have all the millions of users already. I'm sure that's possible, but I am still pretty adamant that this new base infrastructure

that we've built for Deno, the Rust code base that we have, the secure by default capabilities, the native TypeScript support, the fact that we have all these built, these web standard APIs, the fact that it's all in one tool chain, right? It's literally a single executable that,

you know, has a LSP, has code formatting, has linting. I'm not willing to sit in committees for 13 years trying to make all of that stuff happen. I think the failure mode of Deno might be that it ultimately ends up being an R&D effort because Node these days looks at what we do and says, oh, okay, actually, that's a good idea. Let's kind of pull pull this in

like like the native typescript support but i i am bullish on on what we're doing i think it is very useful to have dino.exe that you can hand to not just uh deep javascript developers that know what prettier is and know you know know how to configure how to get started with the project, but can hand it to some random Java developer or, you know, somebody coming from PHP or, or whatever, just allow them to get started very easily. And I think this, this idea of striving for simplicity is, uh, well, let's put it this way. JavaScript, I continue to believe, is not like other programming languages. It is something like the default programming language because so much of human infrastructure

is built on the web. And because JavaScript is like HTTP or CSS or HTML, it is one of the protocols of the web. It has a future that you can't necessarily say about Swift. You know, lots of people use Swift, a lot of infrastructure is built on Swift, but it's not like JavaScript. JavaScript will be here five years from now, if not 10, if not 20, if not, you know, forever, it might, this may be like like really deeply embedded in human in humanity at this point and uh i think it's i i think it is worth the effort to try to strive and make this simple and

you know allow server-side javascript which obviously is is useful to have the fetch api to to you know use use the same apis that are in browser, to use ES modules, right? I think this is kind of slowly coming around that people are accepting that ES modules is actually the standard. But I mean, gosh, how long is it going to take, right? When you run a file in Node these days, it is still not defaulting to ESM. It's common JS. So good point. I mean, I think the autonomy and the ability to move

quickly and not have to convince others of your ideas is, to me, highly desirable in any software project. So I 100% understand why you went that way and your take on javascript is on point there's been two recent rankings released one from ieee spectrum which had js i think it was one or two maybe python was one javascript was two in terms of surveyed from their readership and but then typescript was like five or six so if you combine those two which i mean come on you might as well just combine those two uh clear number one and so on, you might as well just combine those two, clear number one. And so there's academia right there.

And then you go to industry. Red Monk recently did their rankings this year, top 20 languages in use in industry, according to their tech, you know, their methodologies. I'm not sure what the methodologies are, but you got JavaScript number one, and then TypeScript is down there at five or six. And so imagine how number one, number one gets, if you just combine those two. Or mean github top languages on github as of the 2023 survey which um i'm familiar with

i tweeted something about it is uh javascript number one typescript is number three and python is number two so it's like yeah no it's, I like, and, and, you know, just, just as a programmer, you know, like if you're going to give, it is the default programming language, right? Is, is kind of the shared, the shared knowledge that all programmers have. So going back to Deno as different from Node from this project, we'll definitely get to Deno too, so bear with me. But here's a thought that I had. Deno is different insofar as it's a startup, right? This is a business and that's different and new. That constraint

informs a lot of decisions, I'm sure. How has that constraint helped Deno as a project over the seven years of its inception? I mean, it's worth pointing out, first of all, that Deno is MIT licensed. So it is essentially public domain software is completely free, right? It's not a commercial product. Our commercial product is in kind of cloud hosting services. But yeah, when I was working on Node, there was a time where it was very clear that Node was taking off and I could not hire any people to work on this. And that was a ridiculous situation because the company I worked for saw this as some sort of marketing effort, when in fact, like this was the most important thing that that company was undertaking, or, you know, back in 2010, we didn't have the same kind of funding

situation that we do in these days. And, you know, I building software like node or Dino is a expensive undertaking, right? Software engineers are expensive. It requires a lot of time and energy to work on stuff. And it's good to have clear direction and not just a herding cats, right? You have, you move very slowly when when, like you rely on external contributions, and it goes in different directions. And yeah, I want to, you know, I have certain software that I want to build, and I want to push it in a certain direction. And this is software for the masses to that that is not so far away from all sorts of business concerns. So I think it's totally reasonable to have a company around this. And I think it's kind of the right incentive structure as well for building open source

software. You know, there's this two sides of the same coin, like there's open source developers out there that will complain about, you know, how they have to work for free and they have to deal with issues and random people like writing in. And then there's other people out there complaining about VC funded, uh, open source projects that like, you know, Oh God, like what, what, what's kind of the motivation behind this? Are they going to, uh, you know, do something sneaky here? I, you know, I think these are the same problem. Like we, we need to get paid to write software. We're building open source public domain software. MIT license is very, very free. People can fork it, they can that's, that is, that is unacceptable. But

beyond that, like being able to build some software, release it for free, and then, you know, use that software in other situations for commercial purposes, like perfectly aligns the incentives. And, and, you know, I am fortunate enough to be in a position where, where we were able to raise money to work on this. Is that no re-license thing, is that formalized in any way? I mean, I feel like there should be some sort of like no rug pull clause somewhere or somehow in a way that you can't just say,

well, I, Ryan Dahl, say that it's never going to happen. Like, sure, that's great. But then what happens if somebody else runs the company or you get, I'm sure there's a board of directors, maybe you get X, X size as the CEO. And then that's, I comes in and says, well, we're relicensing to fair source or something else. Well, it is, it is MIT licensed. So you can go start a company and you can fork Dino and then you can release it under, you know, you can make a, you know, hire a bunch of engineers and work on it for two years and then license those changes under something else. Right. And it's, you know, it could be that, you know, Deno goes in a different direction and the, you know, Deno 4 or whatever gets relicensed.

What we've built so far is MIT licensed and, and will be that, that way. And no, there's no legal system in which this is dictated other than my own integrity. Right. And, and saying that this is what, that what we're doing as a company. So, yeah, I mean, Well, you haven't pulled the mask off and said muahaha in the last seven years. So I expect, you know, more of the same in terms of, ah, I'm now relicensing and everything I do in the last seven years. So I expect more of the same in terms of, ah, I'm now relicensing and everything I do in the future is going to go against everything I've said in the past.

It's just there's good intentions. And then we have, over time, change in organizational structures, it seems, that usually changes what ultimately leads to a relicensing in the future. So I'm always curious if people have thought about how to somehow just formalize their intentions, maybe even if just saying out loud is sometimes all you can do. Well, I think it comes down to the business model.

So you get into trouble with open core business models because you have to decide, are these features commercial features or are these free features? And that kind of aligns the incentives in a poor way where you're basically, you know, stealing from the open source users to, not stealing, of course, these people are developing it. But, you know, the incentives are just kind of the commercial is pitted against the open source. And what I'm trying to do, I have long recognized this. You know, I want my business model to be orthogonal to the open source project. So it helps it. You know, we're developing a JavaScript infrastructure that can be used in many places.

We don't sell a, you sell an enterprise version of Deno with special enterprise features. We sell hosting services. We sell things that are orthogonal to Deno itself. Yeah. I do think that's the best model so far for the style of software that you're building. Of course, different types of open source

I think lend themselves to different models. We're all figuring it out. But I think it's really misplaced to look at somebody who is, or anybody who is putting out free public domain stuff and say, you are doing something wrong. I mean, that's somebody else's time and energy that's being put into essentially free software, right? That's, you know, whatever happens with it in the future. I mean, you know, at least that software is free and benefits humanity in some way. But yeah, you know, I think a lot about this stuff and I, I, I really want to, uh, set up Dino as a company to not be in a position where, uh, it needs to be, uh, relicensed, uh, in the event that like I am somehow not part of the company. That's an inconceivable proposition, uh, right now, but

you know, who knows? Well, you know, the old saying, no good deed goes unpunished and it's doubly true on the internet. I mean, you are going to be criticized if you go left, and you're going to be criticized if you go right. Yeah. And that's just kind of how it works. Yep. Okay, we're here in the breaks. I'm here with Faraz Bukhdige, founder and CEO of Socket.dev.

So Faraz, you put out this fire post recently on X. And I'm gonna paraphrase, you say the XZ package backdoor was just the tip of the iceberg. Give me just a peek behind the scenes of this incident and what you mean by it's just the tip of the iceberg. Yeah, so I think the XZutils backdoor was really eye-opening to a lot of developers. It showed the vulnerability of the open source ecosystem. You had this maintainer who had been tirelessly maintaining this package for 15 years, who was targeted by nation state actors who created like literally, it's like a spy movie, right? They had multiple personas personas fake personas that were

contacting this poor maintainer and uh you know working on him psychologically to convince him over the course of two years to add them to the repository and give them publish permissions and they did this through us through a bunch of kind of negative messages but also by being helpful and by sending good positive pull requests it's really really like, I really think it's out of a spy movie, just kind of the level of effort that they put into this. And what they were able to do is get access to this package. This is built into pretty much every Linux server out there. And what this would have let them do is,

it would have let them SSH into any server and run any command on the server without knowing the password, without being authenticated to the server. So this would have been like a world ending, potentially kind of an attack, right? It would have been probably the worst attack we've ever seen. I'm not exaggerating.

It could have been that bad, but we were lucky through a total accident. This backdoor dependency had made it into the beta builds of some popular Linux distros, but it hadn't made it all the way out to the stable version yet. And a developer who was testing out the beta versions of these Linux distros

noticed some weird behavior. He noticed that his SSH connection was taking half a second too long. And so he pulled the thread and traced it back to this backdoor dependency. And we were all saved because of this total accident. It's mind-blowing to me for a couple of reasons couple reasons like one obviously like wow there's so there's there's literally states out there countries that are that are trying to target open source now

clearly there's like a team behind this they probably didn't just work on this one dependency they were probably working on getting access to many other ones in parallel if you just look at the time between the emails they sent to the maintainer they were about a month between some of these emails so they were probably working on other maintainers and trying to get access during that time. So that's really scary. I also think it's pretty scary to see kind of the fact that it took an accident to find the attack. It makes me think like, how many have we not caught as a community? How many have we missed if this one was caught by a total accident? It was eye-opening to a lot of people and it made people realize that there really is a threat in the open source ecosystem. And it's not because most people are bad. It's the opposite.

Most people are good, but there are few bad actors out there taking advantage of the trust in the system. That's really where we come in. We're trying to give every company the tools to protect themselves from those types of attacks. And that's what we do at Socket. Okay, friends, go to socket.dev. Security dependencies. Socket is on the front lines of securing the open source ecosystem. They're a developer-first security platform that protects your code from both vulnerable and malicious dependencies. Install the GitHub app or book a demo. Again, socket.dev. That's S-O-C-K-E-T dot dev.

And by our friends over at super base here in the breaks, I'm here with Ant Wilson, CTO over at super base. So Ant, I know our listeners know a lot about super base, but who are you? So I'm the CTO at super base. And so I care a lot about the platform,

whether it comes to uptime security availability, but I'm also extremely passionate about bringing Superbase to more developers. Okay, so bringing Postgres to more developers. I'm a big fan of that. We love Postgres here at Changelog. A lot of developers feel like the main choice or a primary choice for them is Amazon Web Services, AWS, right? No one gets fired for is Amazon Web Services, AWS, right? No one gets fired for using Amazon

Web Services, but Superbase is build no weekends, scale to billions. What's your vantage point on this as CTO of Superbase? When I started in my career, AWS was kind of like new and shiny, and it was so cool that you could go to this website and spin up infrastructure, and then they give you all the tools to manage it. You can drop into the console. You can kind of do whatever you want and you pay for it on a usage basis. If you use a little bit, you get a little bit.

If you use a lot, you pay a lot. The expectations of developers have raised since then and I think will continue to be raised because I no longer want to manage my own infrastructure. I don't want to drop into the console every time I get an additional 10,000 users on my platform to tweak the knobs and make sure that the service is still up. Oh, by the way, I've now got to go and make adjustments to the API gateway to allow for a new geography or whatever it is. I don't want to do that stuff. I want to concentrate on building the cool stuff that i imagined the night before and i think just giving people the ability to focus on the cool

thing you want to build and not have to worry about the infrastructure anymore is kind of the promise of super base that will change in the future as well you know now you have to write your schemas like you shouldn't have to do that in the future. Again, just focus on the cool thing that you want to build. Well, Superbase is open source. You can self-host it if you want to. It is Postgres for life. It is open source for life. Authentication, instant APIs, edge functions, real-time subscriptions storage vector embeddings things for ai it's got it all and no servers managed by you just build your app build in a weekend scale to billions as you grow learn more about their recent launch week at superbase.com and get started. Once again, superbase.com. That's S-U-P-A-B-A-S-E.com.

All right, let's talk Deno 2. You said you guys kind of agonized over when you could call it a 2. This is always a hard problem, even for the folks who are trying to semver their projects, which is usually libraries, not so much runtimes. But hard problem, what's a major, what's a minor? Is this a patch? Of course, most majors in these cases are for marketing purposes, which I think is totally fine.

You gotta get attention on what you've been up to and you can't just simply release things all the time and people just don't pay attention. So usually a 2.0 comes with it, a whole bunch of stuff. This one certainly does. You want to iterate over a few of the high points and we'll talk about them? Yeah. So, uh, it, Deno does follow Sember and, and there are breaking changes in this, but, uh, Deno 2 is, is really trying to, uh, you know, I guess I'm calling it marketing and in some sense it just, just trying to, to give some weight to the changes that are coming in Deno.

So a lot of it's backwards compatible. There are some minor breaking changes, but those are essentially just small API things that aren't super important. The big changes are the module system. The fact that the ability to pull in NPM modules is really good now. The fact that the NPM, the ability to pull in NPM modules is like really good now. The fact that we support package JSON projects. So if you have like a package JSON with some

scripts in it and some dependencies, like you can actually run those right out, right in Deno. And the introduction of JSR, which is kind of this newfangled competitor to NPM. No, not a competitor in a way. It's a super set to NPM. It's a new package registry where you can share JavaScript and TypeScript code. And yeah, we are introducing some stability guarantees. Probably most people listening here don't care about that. But yeah, we're starting an LTS, a long term support release, giving some better stability guarantees on not changing APIs in the future. Not that we were changing them very often, but you know, having a branch that we backport security fixes to. So yeah, this this all kind of

comes together. And yeah, we want to let people know that that like things are things are pretty different than you know, the Deno one days where you can only import HEP specifiers, which by the way, you can still do in Deno. But it's not necessarily the recommended path for distributing code. We recommend you publish to NPM pull in packages there or publish to jsr which is uh the delightful alternative to that if you don't can't figure out how to uh compile your typescript to javascript and whether you should support esm or common js or or some other thing and if you want to be supporting multiple runtimes because jsr is is not just uh for node it is for Deno, Node, Bun, Cloudflare workers, et cetera, browsers. Very cool.

JSR is very interesting because the history of NPM is fraught with costs. It was a cost center, effectively. It was infrastructure for all of us web developers. And NPM Inc. or whatever, I think that's what it is npm inc became the entity that had to bear the burden of that cost of just hosting millions and millions and maybe trillions of downloads over the years and so jsr i assume also must cost some money to run how are you guys doing that how's it working uh i mean we just pay for it right now, the Dino company. It's designed to be simply hosted. It's designed to be cost effective. It's designed to be very cashable

and simple. You know, JSR is not a commercial project. It is also MIT licensed. I have no intention of ever turning this into a business. We, you know, the Dino company is running this right now, but I'm hoping to get this into a foundation and, you know, generally having this be a public service for JavaScript because NPM is just not evolving ever. Like it's just not changing post GitHub acquisition. And this is just really strange for the world's most popular programming language.

Like, are we really just going to stand by and let this be a static future forever? Like, how difficult is it to publish a JavaScript package these days? Like, you have to have a lot of knowledge. And that's in a language where things are just supposed to be trivially easy, right? Like if I want something that's really hard, like let me go to the Rust ecosystem

and at least I'll get like a lot of speed out of it. Like JavaScript should be simple. It should be, this is a scripting language. It's for the children, right? It should just be super, super easy to do stuff. And because of this module, you of the common JS ESM situation, because NPM is not changing, because Node changes very, very slowly,

and us old-timers in the JavaScript world maybe look past this because we're so familiar with all of the troubles that they don't even seem like, we don't even see them as troubles anymore. You realize that, like, actually, you know, writing a library and TypeScript and figuring out how to post it to NPM in a way that, like, lots of people can consume it is not actually super trivial.

Like, definitely does not tell you how to do that on the NPM website. And yeah, in JSR, this is super trivial. You just write your TypeScript, you post it directly, and suddenly you can use it in Node. You can use it anywhere. Like it is delightfully trivial. Is it the kind of thing where you would write a package and you would maybe put it on both registries in the meantime? Or does it matter?

Like if I was going to author something, maybe I'd already know how to do all the crazy NPM things you have to do. Is it, I just post them both? Do I post to JSR? How do you suggest? So there are quite a few people posting them to both just because JSR is new

and people are kind of uncertain about it. But I think that will dissipate with time. JSR actually has an NPM registry built into it. But I think that will dissipate with time. JSR actually has an NPM registry built into it. So npm.jsr.io is the NPM registry. And when you publish there, it builds an NPM package and speaks the NPM protocol. And so you can actually import JSR NPM packages in the NPM format directly in Node, for example, just by setting some stuff in your NPM RC file. So there is a little bit of, you know, like a one line sort of setup to be able to pull in JSR packages that are in a Node project directly from from JSR. uh yeah nevertheless people people are also often posting things to to npm and it's it's a feature that we're kind of dwelling on right now about whether we should

support it it'd be pretty easy to to like allow people to post to jsr and then auto post to npm just to just to kind of have an NPM first experience. You know, if that helps people, I think that might be worthwhile doing. But yeah, generally, you know, the broad strokes of everything I'm undertaking here is like, let's level up JavaScript. Let's just make this nicer.

Let's strive to make this nicer. And yeah, if you use JSR, either as a consumer or a publisher, you will be delighted, like, you know, auto generated documentation, like, why does JavaScript not have auto generated documentation, like, you know, with everybody writing stuff in TypeScript these days, like we have all the information available. And yet, you know, somehow NPM does not have this feature, like we need to make some progress here. And yet, you know, somehow NPM does not have this feature. Like we need to make some progress here. And clearly Microsoft is not doing that. Microsoft slash GitHub, I should say. Yeah, yeah, yeah. Yeah, totally. I agree with that. So as an author,

I totally understand why JSR would be cool, especially if I'm an author of a package and I don't have all of the NPM know-how. As an end user who just has a package JSON in my Deno app or something, does JSR help me or does it matter if I'm NPM installing JSR? I mean, auto-generated docs, for example, is something that's going to help you. We have something called the JSR score, which is stolen from Dart, actually, where we kind of rank packages. We give you a better score if you follow best practices.

So we don't force you to do all this rigmarole up front because sometimes you just want to publish something and don't want to do too much. But you kind of get this signal about what sort of best practices are people following? Are they adding doc strings to all of their exported modules? Do they have a readme? Do they have a license file? This sort of thing. It's generally much more searchable. You can search through symbols. You can, uh, it's, uh, allows you to pull in TypeScript types nicely. If those packages are

written in TypeScript, there's not like a definitively typed thing that you also need to know about. Yeah. It's, it's, it's generally a good experience, but I, yeah, I would say the, the real 10 X behavior is, is when you publish that and then it's like, Oh my God, I can't, can't believe it's so simple. it's like oh my god i can't believe it's so simple right you know rather i can't believe now i recognize how terrible npm publishing actually is that's awesome and jsr modules don't lock you into dino like you can use it in node you can use it in other things right that's right yeah you can you can mark in your package which runtimes are supported and that displays it on the package

page. And so there are modules posted to JSR that have nothing to do with Deno, right? Browser only or for Bun, for example, it is not Deno specific. That's awesome. So I'm here looking at a Node server file I have on my machine that has import Fastify, import Puppeteer, and import AWS SDK. At this point with Deno 2, I could just Deno run this sucker, you think? I'm going to say yes. It's always a little bit of an open question about whether... Little hesitation, but probably, right? Little hesitation because, gosh, there are a lot of built-in Node APIs

and they have a lot of funky behavior that is really difficult to... There's an endless list of compatibility bugs and there's always going to be a long tail of compatibility. But AWS, Puppeteer, and Fastify, I think we support all of those. So I think it should work. That's really exciting. Are you going to try it live? I don't have Deno 2 on this machine.

I still have Deno 1. I probably can't brew install. You can do Deno upgrade, and then Deno upgrade RC will get you the release candidate for Deno 2. This Deno was built without the upgrade feature. Please upgrade. Probably because I brew and install. You have homebrew, yeah.

Yeah. So you'd have to install from our curl script, and then you can do it. I will post later whether or not it works. Okay. We will not take this long of a diversion, unless you're super interested in it. My hands are sweaty, but yeah.

Okay, let's try it. How do I install Vue? Does dino.land and follow the... dino.com. You can grab that curl script, run it. There it is. Now, if I already have it installed via Vue, are we going to have any issues or is it going to be all good?

You might have to add something to your path, but it should be okay. All right, so I just got dino version 1.4.6.3. So now I run Deno upgrade. Deno space upgrade space RC. All right, so Deno run server. You can just do Deno task. Maybe you have some scripts in there in your package JSON.

Yeah, I just have just a start script. This is a pretty simple thing besides the fact that it has Puppeteer, which immediately makes it not simple. start node server.js well it's running so my i guess my task says node so is it running node now i think it might might actually switch that out with dino i'm i'm uh well that would be you do like ps and see if you have node processes or Deno processes? Yes. PS tree maybe to kind of see the sub-process of the Deno task process. I see the task, Deno task start. I don't see any sub-processes.

In PS tree? I don't have a PS tree command. Is that an argument to PS? No, no, that's a special command. You might have to brew install that. Or, I mean, you can just do it in PS, but you might have other node processes running. I just have the one.

I just have dino task start. And that's the only dino process? Oh no, auto-update homebrew. Stop, stop, stop. Yeah, exactly. Hold on, let me go this direction. Oh, I got a bunch of Node tasks running. Apparently, Adobe Creative Cloud is running Node. Maybe it just happened to be a match.

This is getting nasty. Let's try it this way. Can I do dino run server.js? Is dino run a thing? Yeah. Yeah, let's just try that because then we're guaranteed to use dino, right? You might have to give it a dash A

or dash dash allow net or something to... Right. Should I allow? I'm going to say allow all because I'm living dangerously. I'm allowing sys. I'm allowing read. I'm allowing write. I'm allowing run. I'm allowing

net. Yeah. Hey, it is serving on port 3000 it works congrats well our friends over at speakeasy have the complete platform for API developer experience

they can generate SDKs Terraform providers API testing docs and, and more. And they just released a new version of their Python SDK generation that's optimized for anyone building an AI API. Every Python SDK comes with Pydantic models for request and response objects, an HTTPX client for async and synchronous method calls and support for server sent events as well. Speakeasy is everything you need to give your Python users an amazing experience integrating with your API. Learn more at speakeasy.com slash Python. Again, speakeasy.com slash Python.

For me, that was relatively simple. I'm sure for you and your team, that was a huge lift. Super, super huge lift. Yeah, Deno does implement a huge number of the Node APIs at this point. And yeah, it was a very large lift. And also given from the principles in which Deno started, also kind of a philosophical lift as well. But yeah, we're here.

We've convinced ourselves this is what we need to do in order to level up JavaScript. This is how we can make people's lives simpler. And this ultimately is kind of a better experience for everybody, even if this means deep inside of Deno, we do implement common JS somewhere. Like we have to do that in order to interoperate with NPM modules. And, you know, it gets complicated deep inside. But hopefully for the user, it's a single executable that just does all of this stuff that uh you know hopefully is pretty understandable you know it has a dino lsp that like if you open up bs code we'll we'll

interact with that and give you linting and and uh code formatting and and all sorts of type checking obviously that's exciting i mean as a fellow idealist slash purist like part of me dies as you talk about this but part of me actually is also excited because I'm way more likely to use this. I think a lot of people are way more likely to use this. Have people responded? I know Deno 2 is just getting out there, but some of this NPM support has been there for a while now. I am an idealist, and it was hard for me to kind of come to terms with this. But yeah, like I said, I mean, we're building software for people.

And if people can't run it, then we're not achieving our goal of leveling up JavaScript. I think what excites me, though, is that we've actually built this, you know, in a pretty structured way. This is not just a monolithic app, but there's actually multiple layers. So you're using the Deno executable. That's kind of the highest layer, you know, what most people will interact with. But there's also different Rust libraries, lots of different Rust libraries, actually, that you can kind of plug into at different layers, depending on like which experience you want uh so people can actually build custom runtimes pretty easily with with rust with v8 using the lowest layer would be rusty v8

which is is our basically like zero overhead rust uh bindings to v8 and v8's apis are wildly complicated it's uh it is it is not an easy beast to drive. But you know, in Rust, you can do this all in a in a memory safe way. It's like very nice to you like the C++ API, but you need to know what you're doing like pretty seriously in order to drive it. In Rust, like you can kind of just hammer on the keyboard and write a V8 runtime. Because when it compiles, it's kind of going to work. Yeah, Rusty V8 is also going 1.0 next week, actually. And above that is DenoCore, which adds a little bit more infrastructure, adds the module system,

adds not the NPM stuff, but adds kind of basic ESM modules, adds a thing called ops, which is basically our binding layer to Rust, an easy way to like make async functions kind of bind into JavaScript, you know, essentially do this in a super optimal way. Above that, we have EXTs, which are like different, think of them as like native modules. So for example, one EXT, one extension set of modules is like the fetch API. And so maybe you just want Deno core plus the fetch API and nothing else. And you can build your own runtime using those two things. Obviously, all this stuff is MIT licensed. And so, you know, for different use cases, you know, obviously, you need to be programming in Rust, all this stuff is MIT licensed. And so, you know, for different use

cases, you know, obviously, you need to be programming in Rust, like this isn't necessarily approachable to everybody. But, you know, for some systems, like maybe you're building a serverless system where you really only want fetch, and you just want some JavaScript execution, while you can kind of plug into it at this lower layer. So, yeah, the high level Deno executable is opinionated, has a bunch of functionality in it. But, you know, we still have these lower layer things. And I think that's kind of the appropriate tradeoff, right? Because, you know, there's a smaller audience at those lower layers, but they're also more technical.

They're also able to, to kind of deal with this stuff. The highest level people just want to pull in the AWS SDK and they don't care at all about anything else. They're like, do you have that? Yes or no. Uh,

end of, end of story. And like, yeah, we, and Dino, we just need to pull that in. That's really cool that you've been able to architect it in such a way that is

extensible like that and allows people, I mean, talk about again, meeting people where they are. There are people that appreciate those lower levels and they can, you know, they can use that, those open source projects to their own benefit. And that's really cool. And it allows you to continue to take pride in it and to, you know, usher things forward while still, you know, supporting the things that you have to support in order to bring people along with you. You mentioned serverless computing. I think last time you were on the show, which I guess was two years ago now, we were talking about Winter CG and some of the efforts between you all

and Cloudflare to kind of formalize a spec around serverless runtimes. I haven't really kept up with that. Is that something that's continued to move forward? Is there progress there? Is it bearing fruit, this effort to create these specs? I mean, it is still a thing. I think people might imagine that it's more than it is. I mean, it's really kind of describing in minute detail

kind of how, say, fetch works in server environments. It's kind of hard to get agreement between all of the the server side uh vendors and on like what what kind of constitutes uh servers in in javascript um that uh is is a goal but but you know is is probably not uh in something immediate there's not going to be a spec for exactly how an HEP server is going to work in JavaScript. But nevertheless, we participate in it. Fair enough.

As you talked about these different layers, one of the more interesting features I think you have added, which for me as a person who's been in the open source world for a long time and cares about sustainability and talks about licenses,

real kind of wonky in these areas, DenoKV was very interesting to me because it's kind of like where A, it's open source, this is a key value store built right into Deno and has a potential, I guess, upgrade path to Deno, the service, Deno, the hosted stuff where that database can be hosted by you all for pay. But then also, you don't have to do that. And this is like one of

those areas, again, where I wouldn't call this, this is not open core, I don't think so it's a hosted service. But it's like that weird connection point of like, well, where does the runtime stop and the product begin? And I'm just curious your thoughts through that, because I'm sure you thought deeply about it as you guys designed it. Yeah, so just for clarity, like in the Deno open source project, the Deno KB APIs are backed by SQLite and you can kind of run a single instance

and kind of have that same functionality. And Deno Deploy, our commercial platform, when you run these edge functions that are running across the world, the DenoKV APIs are backed by FoundationDB. It's like kind of this big distributed database that's pretty sweet. The DenoKV APIs are not stabilized in Deno2. They continue to be experimental, in part because this is kind of an experimental business effort and and we're not quite sure if we want to go further down this route i actually want to decouple the kb apis from the dino runtime itself and have them be a module that you pull in you know you should

be be able to pull in uh jsr you know at dino slash kv and There's no real reason that it needs to be built directly into the runtime. That's just for ease of implementation, essentially. So I think the open core concerns or incentive concerns would be addressed by decoupling them. It also makes the engineering effort a bit easier, I guess. Yeah, yeah, yeah. That's interesting you say that because that was my initial reaction

when it first came out. I think we talked about it on the show and I was like, it's cool, it's interesting, it seems experimental. Would I use it? I don't know, it seems kind of strange that it's like a top level global inside of the runtime. Like, why is this not just a package?

It makes sense. You're saying, you know, technically it's probably easier for you guys, especially when you're experimenting with a new feature, just like, well, we're just going to drop it in right here because that's the easiest button, maybe not an easy button, but the easiest button and see how it works out.

So, I mean, that's fascinating that you've kind of thought, well, maybe it makes more sense just as a package versus a built-in thing. Yeah, and it is not safe. Just to clarify, it is not stabilized in Deno 2, so it's not something that we are necessarily supporting indefinitely. I got you. It likely will be moved.

But nevertheless, the Deno KV stuff is pretty awesome to you. I don't know if you played around with it at all. I haven't. Like our other around with it at all, but like our other stuff, it's just freaking delightful to have like a easy state store. But yeah, there's a lot of questions to think through with that because yeah, obviously a lot of people need a bit more of a complex database

than a KV store. And like real application code actually needs a relational database and what's interesting is that node recently added the experimental sqlite support and i thought was that maybe again you being their research arm maybe they're like wow putting a key value store in there we could just drop sqlite in there and you give you know more more power than a key value store but i don't know you I don't know if they were inspired by you or if it's not simultaneous invention. Yeah, I think there's a lot of ideas around here,

probably more inspired by Bun that did that. Oh, does Bun have a Direct SQLite embedded thing? Yeah. Gotcha. I think it's a little, yeah, there is a little bit questionable because, I mean, you can always pull this stuff into packages. And there's always the question of, like, where's the runtime concern and what belongs outside of it?

And it's always a difficult discussion. It's hard to have kind of an algorithm for deciding that. But, you know, if Node does stabilize that API because Deno does implement the Node built-in APIs, we will implement that. And of course, we have SQLite. We already use SQLite in there, so it'd be a pretty trivial matter to add that. Yeah, that's cool. I love the competition and the

spirit of innovation and the fact that all these ideas are going back and forth in different directions. I think the whole community really benefits when these things happen. That's what's exciting about JavaScript, right? It's just like, it's madness, it's chaos, but it's just kind of, yeah, there's so many people with different ideas and everybody's inventing new things all the time. I think it's really fun.

100%. Do you guys have any other experiments in the works? Anything you're working on that you're excited about testing out, whether it's monetization or otherwise, like cool new stuff that Dino's working on? We do. I feel like I shouldn't talk about it at this state. We have new commercial efforts underway that are under heavy development right now, but it's a little too soon to talk about it publicly.

Okay. What about non-commercial or the things that like in the open source side that are exciting to you? Maybe after the 2.0 gets finalized and you're working on what's next? Once 2.0 is stabilized, I think there are a lot of cleanups to do. You know, I think there is still kind of a long list of node compatibility to work on. I think making the LSP faster is something that we'll be looking at. I think we removed Deno bundle for 2.0 because we didn't have a great bundling story. But that bundling is obviously part of the JavaScript tool chain.

And we think that that's something that Deno ought to provide. It's just, you know, in general, bundling is a pretty hard problem to solve. Like it's not just simply bundle the script, like there's all sorts of things you need to consider. And there's just tooling that is purpose built for for that that is much better, like ESBuild, for example. So we are potentially, not totally decided yet, but potentially going to undertake having that in the actual tool chain and providing a really good experience there. So you are obviously in the code, in the decision-making process. You are still rocking your code editor on a daily basis, right?

Like you're still writing code. I review a lot of code. I write code sometimes. I write more example code to point out where our problems are. But yeah, Dino's like a 27-person company. And even at this scale, like I'm finding myself becoming more of a manager these days than an actual programmer, which is fine, I guess. I mean, are you fighting that off?

Are you embracing that? What's your stance on that? I mean, it's just what problem at what scale are you solving a problem? Are you working on a much larger problem? Because very often I can just ask some engineer, can you work on this for three days? And if I work on something for three days, that is going to block other things that I might be working on. And so, yeah, you're just working on problems at a larger scale. That said, I mean, I love programming, obviously.

It's like deeply satisfying. And I just don't understand why people work on crossword puzzles like work on software. It's the same thing, but much faster, much more fun. Someday, someday, maybe I won't be working on Deno anymore. Deno won't be growing anymore or whatever. Then, you know, I look forward to sitting down and coding on some small stuff. But yeah, right now the scale of Deno is such that it doesn't make too much sense for me to work on coding stuff day in and day out. Sure. Well,

you're at least in the weeds of the decision-making with the architecture and the direction of the project. So, I mean, it sounds like you are very well versed in where Dino is headed, not just generally speaking as a business or as open source project, but like in the technical details of the decision-making process, whether or not you're actually coding up the functions or not. Sure, more or less. Have you ever considered reorganizing the company a little bit?

Maybe bring on a CEO or somebody and then just stay in IC? Is that something that's attractive to you, or do you just think that you need to be at the helm? I've definitely thought about it because i i mean i'm not the you know i'm like a nerdy engineer i'm not necessarily the best salesperson and uh you know doing doing uh the ceo job i think you you have to be kind of a salesperson right you have to have to go out and close contracts and that sort of thing but i you know the focus in my life isn't to be the best programmer in the world. I'm just trying to build cool stuff.

And I think it's interesting to learn new skills. Doing Dino as a company has been pretty eye-opening because before that in my career I was an engineer only. And learning how to raise money, how to manage people, how to do sales, how to do products, like all of this stuff is, has its own interesting bits. And, you know, I think it's about solving the problem at the end of the day and you do what it takes to solve the problem. Yeah. Wear whatever hats are necessary. What surprised you in that arena in terms of

things you weren't necessarily good at or hadn't done previously? Is the sales process harder than you thought? Is it easier? What's been a surprise in this new role? I think the need to focus is the thing that I didn't understand very well going, going into this, because when, when you have a bunch of people, uh, working for you and you have a bunch of money to, to be, uh, spent, like you can go in all sorts of directions and like, that's all very conceivable. But I think the, there is, there is a real need to kind of focus all of that effort in one direction, like get, get on, add up all those vectors and, and kind of that effort in one direction, like get on, add up all those vectors and kind of make progress in one direction. So, uh, yeah, it's, it's, it's a learning experience.

I'm sure it is in that sense. How do you make those decisions? Like the focus of, no, we're going, we're not going to go right. We're going to go left. And we're all going to like, when it comes down to it, is it intuition? Is it data? Do you ask the people around you? Like, how do you make the call of this is what we're focusing on? Yeah. It's hard to, hard to answer in general, but, uh, ideally by with data, right. Ideally we like look at some data and we say, okay, obviously this is, this is the way to go, right? This, this method is faster than that method. Thus, obviously we do this. Um, or, you know, we, we took a survey and, you know, people prefer this to this. Um, but very, very often, like you don't have clear signals like that, or you just have, you know, some, some dirty signals or some

intuition. Yeah. You talk, talk to the people you trust, you, their opinions. I don't, you know, not back in no days, nor currently do I believe that projects should be run as a democracy. You know, I just took a poll today about something. And, you know, I value people's feedback, but, you know, people's opinions on stuff. But ultimately, you just got to think about it and weigh in all of, weigh all the evidence that you have and decide what is going to level up JavaScript, what is going to further the company, and try to decide that as best you can. Well, on the note of leveling up JavaScript, let's close on this, an open call, a letter to Oracle of all people, if you can consider Oracle a person. It definitely is not a person. About JavaScript, not the programming language, but the word JavaScript that represents

the programming language, which really is kind of belongs to the world at this point. However, the trademark, is it the word trademark is the word? Yes. The trademark belongs to Oracle. And if you go to javascript.tm, it says Oracle, it's time to free JavaScript. So this is an open letter, I think. Was this penned by you or just signed first by you? Tell us the story here. Was this your idea? This is a great idea. Yeah, this is my idea. I actually wrote a previous open letter to Oracle, I think

two years ago, on my personal blog, which obviously did not get a response. You know, when we were talking about is Oracle a person or not, it made me think of a quote from Brian Cantrell, my former boss at Joyent, now CTO of Oxide. Don't anthropomorphize the lawnmower. The lawnmower is going to just spin its blade and cut grass.

And he was referring to Oracle in that way. Oracle should not be anthropomorphized. Yeah, it might surprise people to know that JavaScript is a trademark. It came through a partnership that Netscape did with Sun back in the day for this newfangled scripting thing in their web browser. And they called it JavaScript. And the partnership with Sun was somewhat dubious because JavaScript has nothing to do with Java, but they, they ended up calling it JavaScript and Sun owned the trademark as a result. And Oracle acquired Sun, I think 2007 or so.

And as a result, Oracle owns the, owns the JavaScript trademark and they like dutiful lawyers do renew it every year yet uh oracle really has no you know they do not have a product called javascript uh you know they have several products that use javascript like like everybody does but they are not a major player in JavaScript development, right? The major players being kind of Google with V8 and Apple with JSC, Mozilla, of course, but nevertheless own this trademark. And because of this, the standard for JavaScript, the like spec for JavaScript is called ECMAScript because they have to avoid this name.

And there is not actually a JavaScript conference. You cannot have a JavaScript conference because Oracle will sue you. You have to avoid this name. And there is not actually a JavaScript conference. You cannot have a JavaScript conference because Oracle will sue you. You have to have like JSConf. And it just kind of generally creates this confusion where like the world's most popular programming language is somehow called a name that like nobody can use. And I think it is really not reflective of what trademark.

It's not in the spirit of trademark law. Trademark law, I'm perfectly fine. I have trademarked for Deno, but I do not want people to call things Deno. But JavaScript is just this vestige of this acquisition and this weird partnership back in the day. And Oracle, whoever renews it at Oracle, some lawyer somewhere just does this because that's what they do with all of their trademarks. And what I'm trying to do with this open ladder is create some public pressure, create a public, you know, let people know how annoying this is in the community. And gosh, you know, my letter two years ago just was like, Oracle, you could get some goodwill here by just releasing this trademark into the

public domain. Obviously, they have not done that. And recently, I've discovered that there's actually a process at the patent office, the USPTO, to challenge trademarks and that the USPTO is actually cracking down on trademark non-use. And there is a legal definition of what it means to abandon a trademark. And this letter explains why Oracle exactly has meets the test, like they have abandoned the JavaScript trademark, as defined in you in the US code. And so I am gathering support for challenging this trademark officially with with the US patent office. Very nice. Well, this is very well written. You go through it and you describe specifically how they have abandoned this trademark through non-use. And the call to action at the bottom says, If you agree with us, you are encouraged to sign this open letter below.

Your support will help raise awareness and add weight to this cause. As of the time of us recording, 9,924. It was three, but I signed it just before we hopped on the call. Very easy, just with your GitHub profile and assign that sucker. Have lended their name to this open letter, including folks like Brendan Eich, creator of JavaScript, Rich Harris, creator of Svelte, Isaac Schluter, creator of NPM, Firas Aboukadij, CEO of Socket, some big names.

Of course, you're on at the top there. So people who are very invested in JavaScript have signed this thing. So to our listener, if you are also so inclined to get behind Ryan's open letter, go sign that. And what's the next step after this? You're actually going to start the legal process? Are you raising money? Do you have enough money? Are there pro bono JavaScript lawyers out there who might represent you?

Yeah, we are looking for legal help. So if anybody listening is an IP lawyer and is willing to contribute some time to help us put together this petition to cancel the JavaScript trademark, that would be very welcome. I think the email is lawyers at javascript.tm. Yeah, we'll start undertaking this process once I get Dino 2 out. So in a couple of weeks or here, we'll try to do this. And yeah, I mean, this is just generally trying to make the world's default programming language better. It's not necessarily a product. It's, you know, there's nothing nothing for sale here. Obviously, it's just trying to rectify the

situation. I have no intention of renaming the Dino company to the JavaScript company or anything. I just, you know, don't like this, this weird situation where, you know, I can't say that Dino is a JavaScript runtime. Like that's just silly. That is not what trademarks were intended for. One hundred percent, Drew. Well, that URL is javascript.tm. We will drop it in the show notes for easy clicking through and lending your name if you feel so inclined. Ryan, thank you so much for sitting down with me, all the hard work you've been doing on this project over the last seven years, probably at least seven more years ahead of you. I mean, it sounds like you're in it for the long haul.

As a web worker and as a web denizen, I appreciate you trying to make JavaScript and the web a better place. Just keep leveling it up and we appreciate you. Thanks so much. So I have a little secret for you. This conversation was originally recorded for JS Party. In fact, we are shipping it to the JS Party feed as well. So if you listen to both pods or subscribe to our master feed and you see it twice, that is not a mistake. We just

thought both audiences would get a lot out of this one. If you don't listen to JS Party, but you enjoy the changelog and want to hear more of me interviewing folks, chatting about web development, playing silly games, stuff like that, maybe give JS Party a listen. Even if you don't write JavaScript, you can probably get a lot out of that show. I know I do. Oh, and this is it, the last week in September, which means it's your last chance to get some sweet, sweet ChangeLog stickers for $0. All it costs you is one thoughtful five-star review or blog post. We do accept blog posts. Just send proof of your review to stickers at changelog.com alongside your mailing address and I'll ship you the goods anywhere in the world. This is your last

chance for a while, so let's do this. Or you could get some stickers from us IRL at All Things Open 2024. Yes, Adam and I will be in Raleigh once again, hanging out in the hallway track, recording conversations, giving out high fives, and more. We even have some free passes to give to our audience. Introduce yourself in our shiny new Zulip chat, and we'll hook you up with a free pass. Link to join our Zulip is in your show notes. Thanks once again to our partners at Fly.io, to our Beatfreakin' residents, The Goat, Breakmaster Cylinder, to our friends at Sentry, use code CHANGELOG, save $100, and to you for listening. We love that you choose to spend time with us each week. That is all for now, but we'll talk to you again on Changelog and Friends with special guest Nick Nisi on Friday. Thank you. Game on.