Leveling up JavaScript with Deno 2 (Interview)

28:03Security 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.dev. And by our friends over at Superbase here in the breaks, I'm here with Ant Wilson, CTO over at Superbase. So Ant, I know our listeners know a lot about Superbase, but who are you? So I'm the CTO at Superbase. 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.

28:50Okay, 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 superbase is build no weekend 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 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.

29:54Oh, 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.

30:30Well, 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 on 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.

31:11all right let's talk dino two you said you guys kind of agonized over when you could call it a two this is always a hard problem even for the folks who are trying to sember their projects which is usually libraries not so much runtimes but hard problem what's a 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 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.

31:45This one certainly does. You want to iterate over a few of the high points and we'll talk about them. Yeah. So Dino does follow Semver and there are breaking changes in this, but Dino 2 is really trying to, you know, 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 ability to pull in NPM modules is really good now. The fact that we support package JSON projects.

32:29So 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 Dino. And the introduction of JSR, which is kind of this newfangled competitor to NPM. No, not a competitor in a way. It's a superset 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.

33:12Not that we were changing them very often, but 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 things are pretty different than the Deno one days where you can only import HGP 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.

33:55And if you want to be supporting multiple runtimes, because JSR is not just for Node. It is for Dino, Node, Bunn, Cloudflare workers, et cetera, browsers. Very cool. JSR is very interesting because the history of NPM is fraught with cost. 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?

34:40How is it working? 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 cacheable and simple. JSR is not a commercial project. It is also MIT licensed. I have no intention of ever turning this into a business. The Dino company is running this right now, but I'm hoping to get this into a foundation and 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.

35:27Are 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. 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 know, because of the common JS ESM situation because NPM is not changing, because Node changes very, very slowly.

36:13And 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 actually writing a library in 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.

36:57Is 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 to JSR? How do you suggest? So there are quite a few people posting them to both just because JSR is new and, you know, people are kind of uncertain about it. But, you know, I think that 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.

37:37And 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 a one-line sort of setup to be able to pull in JSR packages in a Node project directly from JSR. But nevertheless, people are also often posting things to NPM. And it's a feature that we're kind of dwelling on right now about whether we should support it. It would be pretty easy to allow people to post to JSR and then auto post to NPM just to kind of have an NPM first experience. If that helps people, I think that might be worthwhile doing.

38:30But yeah, generally, 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 clearly, Microsoft is not doing that.

39:10Microsoft slash GitHub, I should say. Yeah, yeah, yeah. Yeah, totally. No, 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 Dino 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 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.

39:56So 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. 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.

40:36Yeah, it's generally a good experience. But yeah, I would say the real 10x behavior is when you publish that. And then it's like, oh my God, I can't believe it's so simple. Or I, you know, rather I can't, 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 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 Dino, right? Browser only or for BUN, for example.

41:13It is not Dino 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 Dino 2, I could just Dino 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.

41:58but aws puppeteer and fastify i think we support all of those so i think it should work that's really exciting oh are you going to try it live i was thinking i'm trying well i don't have dino two on this machine i still have dino one can i just uh i probably can't brew install you can do dino upgrade and then dino upgrade rc will get you the the release candidate for for dino too this dino was built without the upgrade feature please upgrade that probably because i brew installed you have you have homebrew yeah yeah so you'd have to install from our curl script and then you can uh all right you can do it i will uh 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 uh yeah uh okay let's try it how do i install uh via your just you know.land and follow the Dino.com can grab that curl script, run it.

42:52There it is. Now, if I already have it installed VMbrew, 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 it should be okay. All right, so I just got Dino version 1.4, 6.3. So now I run Dino upgrade. Dino space upgrade space RC. All right, so Dino run server. 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.

43:31So I guess my task says node. So is it running node now? I think it might actually switch that out with Dino. Well, that would be. Can you do like PS and see if you have node processes or Dino processes? Yes. The ps3 maybe to kind of see the subprocess of the denotask process. I see the task, denotask start. I don't see any subprocesses. In ps3? I don't have a ps3 command. Is that an argument to ps? No, no, that's a special command. You might have to brew install that. Brew install. 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 denotask start.

44:13That's literally. and that's the only dino process oh no auto updating 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 uh let's try it this way can i do uh dino run server.js is dino run a thing uh 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 just dash dash allow net or something to. Right. Should I allow? I'm going to say allow all because I'm living dangerously.

44:54I'm allowing SIS. 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.

45:15Well, 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.

45:59Again, speakeasy.com slash Python.

46:07For 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 Dino started, also kind of a philosophical lift as well. But yeah, we're here. You know, 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, you know, deep inside of Dino, we do implement CommonJS somewhere.

46:49Like 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 you know hopefully is pretty understandable you know it has a dino lsp that like if you open up vs code will will interact with that and give you linting and 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.

47:29I think a lot of people are way more likely to use this. Has, have people responded? I know Dino too, is just getting out there, but some of this NPM support has been there for a, for a while now. Yeah. I mean, I, I am, I am an idealist and it was hard to meet for me to kind of come to terms with this, but like, yeah, like, like I said, I mean, we're, we're building software for people. Uh, and if, if people can't run it, then we're not achieving our, 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.

48:07So 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, lots of different Rust libraries, actually, that you can kind of plug into at different layers, depending on like 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.

48:52It's like very nice to you. Like the C++ API, 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 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 Dino Core, which is adds a little bit more infrastructure adds the module system adds not the npm stuff but 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 uh you know essentially do this um in a super optimal way above that we have exts which are like different think of them as like native modules.

49:47So for example, one ext, one extension set of modules is like the fetch API. And so maybe you just want Dino core plus the fetch API and nothing else. Then 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. 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.

50:26So, yeah, the high-level Dino 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, you know, 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 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.

51:07I 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 it 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 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.

51:38I 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 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.

52:29But nevertheless, we participate in it. But 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. Dino KV 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 Dino and has a potential, I guess, upgrade path to Dino the service, you know, do you know the hosted stuff where that database can be hosted by you all for pay?

53:08But 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 in the product begin? And I'm just curious your thoughts through that, because I'm sure you've thought deeply about it as you guys designed it. Yeah. So just for clarity, like in, in the Dino open source project, the Dino 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 commercial platform, when you run these edge functions that are running across the world, the Dino KB APIs are backed by FoundationDB.

53:51It's like kind of this big distributed database that's pretty sweet. The Dino KB APIs are not stabilized in Dino 2. They continue to be experimental, in part because this is kind of an experimental business effort. 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 Dino runtime itself and have them be a module that you pull in. You should be able to pull in JSR at Dino slash KV. There's no real reason that it needs to be built directly into the runtime. time. That's just, uh, yeah, for ease of implementation essentially. So I, you know, I think the open core concerns or, or, uh, incentive concerns are, would be addressed by, by kind of decoupling them.

54:41Uh, 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.

55:13Maybe 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 – yeah, just to clarify, it is not stabilized in Dino 2, so it's not something that we are necessarily supporting indefinitely. I guess, yeah. It likely will be moved. But, you know, nevertheless, the Dino 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 stuff, it's just freaking delightful to have like an easy state store.

55:53But, 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 more power than a key value store. But I don't know if there's, if they were inspired by you or if it's not simultaneous invention.

56:29Yeah, 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 if Node does stabilize that API because Dino does implement the Node built-in APIs, we will implement that. And of course we have SQLite.

57:08We 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 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?

57:44Anything 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 date. We have, 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.

58:21I 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 Dino 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 Dino 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 that that is much better, like ESBuild, for example.

59:05So 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? 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. Okay. 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.

59:54I 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 much larger problem? Because like very often I can just ask some engineer, like, can you 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 just working on problems at a larger scale. That said, I mean, I love programming. Obviously, it's deeply satisfying. And I just don't understand why people work on crossword puzzles like work on software.

1:00:35It's the same thing, but much faster, much more fun. Someday, maybe I won't be working on Dino anymore. Dino 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 Dino 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 an 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.

1:01:27Sure, more or less. Have you ever considered like reorganizing the company a little bit, maybe bringing on a CEO or somebody and then just, you know, just stay in IC? Is that something that's attractive to you or 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 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 like the best programmer in the world.

1:02:08Like I'm just trying to build cool stuff. And I think it's interesting to learn new skills, like doing Dino as a company has, has been, um, pretty eyeopening because before that in my career, I was, you know, an engineer only and, uh, learning, you know, how, 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?

1:02:49Is 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 while going into this. Because when you have a bunch of people working for you and you have a bunch of money to be spent, you can go in all sorts of directions. And that's all very conceivable. But I think there is a real need to focus all of that effort in one direction, add up all those vectors and make progress in one direction. So yeah, it's a learning experience. I'm sure it is. In that sense, how do you make those decisions?

1:03:37Like 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 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 ideally, by with data, right? Ideally, we 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. Or, you know, we took a survey and, you know, people prefer this to this. 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.

1:04:18Yeah, you talk, talk to the people you trust, you take 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 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.

1:05:05An 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. Is this your idea? This is a great idea.

1:05:48Yeah, 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 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.

1:06:43And 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 not 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 Google with V8 and Apple with JSC, Mozilla, of course.

1:07:31But 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 is somehow using a call they name that like nobody nobody can use. And I think it is really not reflective of what trademark it's not in the spirit of trademark law. It's trademark law is I'm perfectly fine.

1:08:11I have trademarked for Dino, but like I do not want people to call things Dino. 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 lander is create some public pressure, let people know how annoying this is in the community. And gosh, 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.

1:08:57And 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 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. that you go through it and you describe specifically how they have abandoned this trademark through non-use.

1:09:48And 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 to sign that sucker. have lended their name to this open letter, including folks like Brendan Ike, creator of JavaScript, Rich Harris, creator of Svelte, Isaac Schluter, creator of NPM, Ferasa Bukadijay, CEO of Socket, some big names. Of course, you're on at the top there.

1:10:27So 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 are there pro bono javascript lawyers out there that who might represent you yeah we're we are looking for legal help so if anybody listening is an ip lawyer and uh is willing to contribute some time to help us uh put together this petition to cancel the JavaScript trademark. That would be very welcome.

1:11:08I 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 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 for sale. here obviously that it's just uh trying to to rectify the situation i 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 silly that is not what trademarks were intended for 100 true well that url is javascript.tm we We'll drop it in the show notes for easy clicking through and lending your name if you feel so inclined.

1:12:04Ryan, 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.

1:12:28So 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.

1:13:06I 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 zero dollars. 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.

1:13:49We 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 Change Login Friends with special guest Nick Neesey on Friday.

1:14:51y 'all