The Changelog: Software Development, Open Source
Leveling up JavaScript with Deno 2 (Interview)
Thu, 26 Sep 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 dino 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? 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 doll 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 dino
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, like you're kind of a internet celebrity now.
Day after day, it continually surprises me. It's just, you know, like every year, like this is how big Node will be, right? And then, you know, the... Next year, it gets bigger and bigger. It's a privilege to have worked on this.
Well, well-deserved. And of course, not just yourself, hundreds, scores of people working on Node over the years. And of course, Dino, you are primary on Dino, but a team over there as well. And gosh, I said not too recently because you've been working on Dino a long time now. Hasn't it been like six or seven years?
Yeah, it's been a while. I think we started this in 2017. 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 and 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? Yeah.
Sure. I mean, there are things that I said in that original talk that Deno 2 actually goes back on. So, for example, introducing the process global variable is, I think, one of the things I regretted about Node. Turns out, like, yeah, I think the...
we're just kind of hitting reality with, with, you know, how, how big the NPM ecosystem is and just realizing that, and this is, this is kind of a big part of, 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 basically implement the Node built-in APIs. And although we look at this very carefully and still have a core philosophy of leveling up 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 a
There's work that has been done to be able to import NPM packages and be able to run Node projects out of the box. At this point with Deno 2, it's pretty great. You can basically drop into most Node projects, let's say modern Node projects, if they're using ESM, not if they're using CommonJS, and use Deno with them.
So you initially started with a clean cut from NPM as well with your own URL based imports. And 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 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 uh 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 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. Like you have to kind of ditch a little bit of the pure idealism of the fresh start, right?
Yeah. Uh, very, very difficult, uh, decision to be made after, after like wringing our hands over, over long periods of time. Yeah. I mean, the original idea with the Deno module system is, uh, let's follow the ESM spec. Exactly. Let's follow exactly what browsers do. And, uh, browsers allow you to have, uh, HGPS imports in there and, uh, 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 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, uh, SDK, right. Like you're, there's just some things that you are not going to rewrite. And, uh, 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 that like it's NPM colon express. Yet, you know, in order to pull in NPM packages, it's much more complicated than the HEP specifiers. I mean, the beauty of the original DenoVision was like, oh, this dead simple resolution scheme that like 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 like that works to some scale. But, you know, we're interested in making software for lots of people. And, you know, I'm not satisfied working on software. 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.
And in order to allow those people to really level up JavaScript, 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 can't, you have to meet people where they are, you know, 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 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 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 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 like 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 infrastructure 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, you know, 13 years trying to make all of that stuff happen. You know, I think the failure mode of Deno might be that it ultimately ends up being an R&D effort because, you know, Node these days like looks at what we do and says, oh, okay, actually, that's a good idea. Let's kind of pull it.
pull this in like the native TypeScript support. But I am bullish on what we're doing. I think it is very useful to have dino.exe that you can hand to not just deep JavaScript developers that know what Prettier is and know how to configure, how to get started with the project, but can hand it to some random Java developer or somebody coming from PHP or whatever. Just allow them to get started
very easily. And I think this idea of striving for simplicity is 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 necessarily. 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 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 use, use the same APIs that are in the browser to use ES modules, right? Like they're, they're,
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. 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, cleared them one. And so there's academia right there. And then you go to industry.
RedMonk 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 jobs for 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.
I mean, GitHub top languages on GitHub as of the 2023 survey, which, um, I'm familiar with, I tweeted something about it is JavaScript. Number one, TypeScript is number three and Python's number two. So it's like, yeah, no, it's massive is, is absolutely 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. It's 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, yeah, 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, building software like Node or Deno 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 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, too, 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 open source projects that like, you know, Oh God, like what, what, what's kind of the motivation behind this?
Are they going to, you know, do something sneaky here? I, you know, I think, These are the same problem. Like we need to get paid to write software. We're writing, we're building open source public domain software. MIT license is very, very free, right? Like people can fork it, they can sell it, they can do anything with it.
I think the important thing is to be honest and not change licenses out from under people. I think that is unacceptable. But beyond that, being able to build some software, release it for free, and then use that software in other situations for commercial purposes perfectly aligns the incentives. And I am fortunate enough to be in a position 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. You're 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 excised as the CEO and the next guy comes in and says, well, we're re-licensing to Fair Source or something else.
Well, it is MIT licensed. So you can go start a company and you can fork Deno and then you can release it under, you know, you can 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 re-licensed
What we've built so far is MIT licensed and will be that way. And no, there's no legal system in which this is dictated other than my own integrity, right? 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 future is going to go against everything I've said in the past. It's just, there's, 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 way.
poor way where you're, you're basically, you know, stealing from the open source users to, to, uh, not stealing, of course, these people are developing it, but you know, the, the incentives are just kind of the, 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 know, enterprise version of Deno with like special enterprise features. We sell hosting services, right? 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 we're all figuring it out. But, you know, I think it's it's really misplaced to, you know, look at somebody who is or anybody who is like putting out public free public domain stuff and say you are doing something wrong, like 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 really want to set up Dino as a company to not be in a position where it needs to be relicensed in the event that like I am somehow not part of the company. That's an inconceivable proposition 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 gonna be criticized if you go right. And that's just kind of how it works.
Okay, we're here in the breaks. I'm here with Firas Bukidji, founder and CEO of Socket.dev. So Firas, you put out this fire post recently on X. And I'm going to 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, fake personas, that were contacting this poor maintainer. And, 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 a bunch of kind of negative messages, but also by being helpful and by sending good positive pull requests.
It's 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 reasons. One, obviously, wow, there's literally states out there, countries that are trying to target open source now. Clearly, there's 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 maintainer's 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 super base 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 using amazon web services but suit base is build no weekend scale to billions what's your vantage point on this as cto of super base
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 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 Superbase. 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 it in a weekend, scale to billions as you grow.
Learn more about their recent launch week at superbase.com slash launch week or go to superbase.com and get started. Once again, superbase.com. That's S-U-P-A-B-A-S-E dot 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...
uh, marketing purposes, which I think is totally fine. You got to 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, Deno does follow Sember, and there are breaking changes in this, but Deno 2 is really trying to, I guess I'm calling it marketing in some sense, just trying 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 MPM, the ability to pull in MPM 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 MPM.
No, not a competitor in a way. It's a superset to MPM. 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 all kind of comes together. And, yeah, we want to let people know that, like, 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 the delightful alternative to that if you can't figure out how to compile your TypeScript to JavaScript and whether you should support ESM or CommonJS or some other thing.
And if you want to be supporting multiple runtimes, because JSR is not just 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 that the Dino company it's designed to be simply hosted. Uh, it's, it's designed to be cost effective. It's designed to be very cashable and, and simple, you know, JSR is not, is not a commercial project. It is also MIT licensed. It, I have no intention of, of ever turning this into a business.
We, you know, the Dino company is, is running this right now, but, um, I'm, I'm hoping to get this into a foundation and, uh, generally having this be a public service for JavaScript because NPM is just not evolving ever. It's just not changing post GitHub acquisition. And this is just really strange for the world's most popular programming language.
Are we really just going to stand by and let this be a static future forever? How difficult is it to publish a JavaScript package these days? You have to have a lot of knowledge. That's in a language where things are just supposed to be trivially easy. If I want something that's really hard, let me go to the Rust ecosystem and at least I'll get a lot of speed out of it.
JavaScript should be simple. This is a scripting language. It's for the children. It should just be super easy to do stuff. Because of this module, because of the CommonJS 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 we don't even see them as troubles anymore. You realize that actually writing a library in TypeScript and figuring out how to post it to NPM in a way that...
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 for 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 a JSR? How does it, 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. 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 like 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 like a one line sort of setup to be able to pull in JSR packages that in, in a node project directly from, from JSR. But, 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, uh,
uh in npm first uh experience um you know if that helps people i think that's that might be worthwhile doing but yeah generally you know the the the broad strokes of 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 uh yeah if you use 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 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, like why... does JSR help me or does it matter if I'm NPM installing JSR?
I mean, auto-generated docs, for example, is, is something that's, that's going to help you. We have something called the JSR score, which is stolen from, from Dart actually, where we kind of rank packages. We give you a better score if you follow best practices. So
you know, we don't force you to, to do all this rigmarole upfront because, you know, sometimes you just want to publish something and don't, don't want to do too much, but, uh, you, you kind of get this signal about like how, what, what sort of best practices are, are people following? Like, are they, are they adding doc strings to all of their exported modules?
Are, are they, do they have a readme? Do they have a license file? This, this sort of thing, you know, it's, it's generally much more searchable. You can search through symbols. You can, uh, It 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 generally a good experience. But yeah, I would say the real 10x behavior is when you publish, then it's like, oh my God, I can't believe it's so simple. Or rather, now I recognize how terrible NPM publishing actually is.
That's awesome. And JSR modules don't lock you into Deno. Like you can use it in Node, you can use it in other things, right?
That's right. Yeah, 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... A little hesitation, but probably, right? A 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.
Uh-oh. Are you going to try it live?
I was thinking about trying it. Well, I don't have Deno 2 on this machine. I still have Deno 1. Can I just, 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. That probably because I brew installed it.
Oh, you have homebrew. 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. We will not take this long of a diversion, unless you're super interested in it.
My hands are sweaty, but yeah.
Uh, okay. Let's try it. How do I install a VO year? Just, you know, dot land and follow the.
You know, dot com can, uh, grab that curl script, run it. There it is.
Now, if I already have it installed via brew, are we going to have any issues or it's going to be all good?
You might have to add something to your path, but, uh, should, should be, should be okay.
All right. So I just got Dino version one, not four, six dot three. So now I run Dino upgrade.
Dino space upgrade space RC. Okay.
right so dino run server uh you you can just do dino 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 task 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 actually switch that out with Deno. Well, that would be... Can 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? Yes.
I don't have a ps3 command. Is that argument to ps?
No, no, that's a special command. You might have to brew install that. Brew install. 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. 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 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 and 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, Dino 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 that this ultimately is kind of a better experience for everybody, even if this means, you know, 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 hopefully is pretty understandable. It has a Deno LSP that if you open up VS Code, we'll interact with that and give you linting and code formatting 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. Some of this NPM support has been there for a while now.
Yeah, I mean, 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 goals.
our goal of of leveling up javascript i think what uh excites me though is that we've actually built this you know in a pretty structured way this is not just a a monolithic app but there's actually multiple layers out so you're using the dino executable that's kind of the highest layer you know what most people will interact with but there's also different rust libraries uh lots of different rust libraries actually that
you can kind of plug into different layers depending on which experience you want. So people can actually build custom runtimes pretty easily with Rust, with V8, using the lowest layer would be Rusty V8, which is our basically like zero overhead Rust bindings to V8. And V8's APIs are... wildly complicated. It is not an easy beast to drive. But in Rust, you can do this all in a memory-safe way.
It's very nice to you. The C++ API, you need to know what you're doing pretty seriously in order to drive it. In Rust, like you can kind of just hammer on the keyboard and write a V8 runtime just because like whatever, 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. It adds a thing called ops, which is basically our binding layer to Rust, an easy way to make async functions kind of bind into JavaScript, essentially do this in a super optimal way. Above that, we have EXTs, which are different.
Think of them as native modules. So, for example, one extension set of modules is like the Fetch API. And so maybe you just want DenoCore 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.
Like this isn't necessarily approachable to everybody. Sure. But for some systems, like maybe you're building a serverless system where you really only want fetch and you just want some JavaScript execution, well, you can kind of plug into it at this lower layer. Yeah, the high-level Deno executable is opinionated, has a bunch of functionality in it, but we still have these lower layer things.
And I think that's kind of the appropriate trade-off, right? Because there's a smaller audience at those lower layers, but they're also more technical. They're also able 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? End of story.
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 use those open source projects to their own benefit.
And that's really cool and allows you to continue to take pride in it and to usher things forward while still supporting the things that you have to support in order to bring people forward. 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, you know, 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. Yeah. It's kind of hard to get agreement between all of the server-side vendors on what constitutes servers in JavaScript. That is a goal, but it's probably not 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. Yeah.
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, you know, 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, you know, 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
dino deploy our our commercial platform uh when you when you run you know these edge functions that are running across the world uh the the dino kv apis are backed by foundation db it's like kind of this this big distributed database that's pretty sweet the dino kv apis are not stabilized in dino 2 uh we we 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 KV APIs from the Deno runtime itself and have them be a module that you pull in. You should be able to pull in JSR at Deno slash KV. 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 or incentive concerns are would be addressed by by kind of decoupling them it also makes the engineering effort a bit easier i guess 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, and it is, it is not safe. Yeah. Just to clarify, it is not stabilized in Dino too. So it's not something that we are necessarily supporting indefinitely. I guess it likely will be moved. But, you know, nevertheless, the DenoKV stuff is pretty awesome to you.
I don't know if you played 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 to
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'd give more power than a key value store. But I don't know if they were inspired by you or if not simultaneous invention.
Yeah, I think there's a lot of ideas around here, probably more inspired by Bun that did that.
Oh, does Bunn 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. Yeah.
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. So much. I love the competition and the spirit of innovation and like the fact that all these ideas are going back and forth and different directions. I think the whole community really benefits when these things happen.
That's what's exciting about JavaScript, right? It's, it's just like, it's it's, it's madness. It's chaos. But, but it's, it's just kind of yeah, there's, there's so many people with different ideas and everybody's inventing new things all the time. I think it's, 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, you know, 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 like 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. 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, in general, bundling is a pretty hard problem to solve. It's not just simply bundle the script. There's all sorts of things you need to consider, and there's just tooling that is purpose-built for that that is much better, like ESBuild, for example.
So we are, you know, potentially not not not totally decided yet, but but potentially going to undertake having that in in the actual tool chain and providing like a really good experience there.
So you are obviously in the code in the decision making process, like 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, 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 it? What's your stance on it?
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? Uh, if I work on something for three days, that is, is going to block other things that, that I might be working on. And so, yeah, you're just, just working on problems at a larger scale.
That said, I mean, I, I love programming, obviously it's, it's like deeply satisfying and, and, uh, you know, I just don't understand why people work on crossword puzzles, like work on software. It's, it's, it's the same thing, but much faster, much, much more fun.
Um, yeah. Yeah.
Someday, maybe I won't be working on Deno anymore. Deno won't be growing anymore or whatever. Then 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 Deno 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. Yeah.
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 mean, I'm not the, you know, I'm like a nerdy engineer. I'm not necessarily the best salesperson. And, you know, doing the CEO job, I think you have to be kind of a salesperson, right? You 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 Deno 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 product. All of this stuff has its own interesting bits.
And 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 into this. Because when you have a bunch of people 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 on, add up all those factors and, 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 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 answer in general, but ideally with data, ideally we look at some data and we say, OK, obviously this is the way to go. This method is faster than that method, thus obviously we do this. Or we took a survey and people prefer this to this. But very, very often you don't have clear signals like that or you just have some dirty signals or some intuition. Yeah.
You talk, talk to the people you trust, you, you take their opinions. Um, I don't, you know, not back in no days, nor currently do I believe that a project should be run as a democracy. You know, I, I'm, I'm just took a poll, uh, today about something. And, uh, uh, you know, I, I, I, I value people's feedback, but, um, you know, people's opinions on stuff, but, uh, ultimately, uh,
You just got to think about it and weigh in 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? Yes, the trademark belongs to Oracle. 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 Java, is Oracle... 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, you know, 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 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 JavaScript trademark and they, like dutiful lawyers do, renew it every year.
Yet Oracle really has no, you know, they do have a product called JavaScript. You know, they have several products that use JavaScript like everybody does, but they are not a major player in JavaScript development, right? The major players being JavaScript. Google with V8 and Apple with JSC, Mozilla, of course, but nevertheless own this trademark.
And because of this, the standard for JavaScript, the 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 have like JSConf.
And it just kind of generally creates this confusion where like the world's most popular programming language, right? is somehow called a name that 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... This vestige of this acquisition and this weird partnership back in the day. And Oracle, you know, 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...
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 And this letter explains why Oracle exactly meets this, like they have abandoned the JavaScript trademark as defined in the U.S. code.
And so I am gathering support for challenging this trademark officially with the U.S. 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. I signed 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 Aboukadej, CEO of Socket, some big names. Of course, you're on at the top there.
So people 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 are there pro bono javascript lawyers out there that who might represent you yeah we're we 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. We'll start undertaking this process once I get Deno 2 out. In a couple of weeks or here, we'll try to do this. This is just generally trying to make the world's default programming language better.
It's not necessarily a product. It's There's nothing for sale here, obviously. It's just trying to rectify the situation. I have no intention of renaming the Deno company to the JavaScript company or anything. I just don't like this weird situation where I can't say that Deno is a JavaScript runtime. That's just silly. That is not what trademarks were intended for.
100% 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 Beat Freakin' residents, The Goat, Breakmaster Cylinder, to our friends at Sentry, use code CHANGELOG, save 100 bucks, 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.