Kevin Whinnery is the Head of Developer Relations at Deno. They dive deep into the world of Deno, exploring its evolution, functionality, and differences from its predecessor, Node.js. They discuss the challenges Deno has faced in establishing compatibility with the NPM ecosystem, its out-of-the-box TypeScript support, built-in tools, and its use in edge computing. With insights into Deno's standard library, TypeScript implementation, and plans for improving compatibility with popular meta frameworks, this episode is a must-listen for developers looking to stay ahead in the ever-evolving world of JavaScript. Get ready to uncover the latest developments in Deno and its impact on the development landscape!

Picks

Charles Max Wood [00:00:06]:
Hey. Welcome to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards.

Steve Edwards [00:00:13]:
Since AJ's not here, I'll do him. Yo yo yo from very cold and rainy Portland, which is not out of the ordinary for this time of year.

Charles Max Wood [00:00:23]:
Dan Shapiro?

Dan Shappir [00:00:24]:
Hey from Tel Aviv, where it's still well, actually, Far Saba, which is also in Israel, where, it's still light outside, which explains why I'm in Far Saba, because I'm still at the office as you might be able to tell from my background if you're watching the the stream or the recorded video. It's, you know, it's daylight savings in the US and not yet in Israel, which makes it even earlier for me. So so yeah.

Steve Edwards [00:00:48]:
I must say that is very distinctive white wall and and white whiteboard there with nothing written on it. It stands out.

Dan Shappir [00:00:55]:
Yeah. Somebody cleaned out the whiteboard, which is a good thing because it means that there are no trade secrets.

Steve Edwards [00:01:00]:
Right.

Charles Max Wood [00:01:03]:
Awesome. I'm Charles Max Wood from top end Devs. And I just want to say hi to all 37 people watching us on X or Twitter, whatever you're calling it. And we have a special guest this week. That's Kevin Winery. Kevin, do you wanna say hello and introduce yourself?

Kevin Whinnery  [00:01:18]:
Yeah. That'd be great. How's it going, folks? I'm Kevin. I'm, part of the Deno team, and, I'm coming to you from, Minneapolis, which is not cold actually as it usually is. It's actually unseasonably warm, for March in Minneapolis, but, we'll take it. We can get a little bit more time outside without a cup.

Charles Max Wood [00:01:35]:
Awesome. Alright. Well, we brought you on to talk a bit about Dino. And I have to say, I was a little surprised to find that we haven't had an episode where we talked specifically about Deno. I think we've talked about isn't there a web framework or something that we talked about? We we mentioned Fresh.

Dan Shappir [00:01:54]:
I think we mentioned Fresh, and we said that we wanted to bring somebody to talk about Fresh, but I don't think we actually had an episode about Fresh either. So maybe we'll take that this opportunity to also talk about Fresh.

Kevin Whinnery  [00:02:07]:
Yeah. For sure. I was happy to tell you about Fresh.

Charles Max Wood [00:02:10]:
I might have been confused with I know we did an episode on bun, so that may be

Dan Shappir [00:02:15]:
Yeah. Where it was a great episode, by the way, even though I didn't participate.

Charles Max Wood [00:02:21]:
Despite the fact that there was no

Steve Edwards [00:02:23]:
Despite the fact. Yes.

Dan Shappir [00:02:24]:
Despite the fact. Yeah. It was, just AJ and, what's what's the name of the guy who's doing bun? Forget I I forgot his name.

Kevin Whinnery  [00:02:34]:
Probably Jared, I would imagine.

Dan Shappir [00:02:36]:
Jared. Yeah. It was Jared himself.

Charles Max Wood [00:02:37]:
It was Jared. I'm pretty sure.

Dan Shappir [00:02:38]:
It was a great episode. Yeah.

Charles Max Wood [00:02:40]:
Jared's I

Dan Shappir [00:02:41]:
highly recommend it. Yes. They the and AJ took the the opportunity to really dive into the nitty gritty details of, what it means to build an engine.

Charles Max Wood [00:02:52]:
That's kinda how he operates, but it makes the episodes fun. So it works. Let's let's jump in though and quickly introduce Dino. I know that probably most of our listeners have some idea what it is, but we always have new people. And by new people, I mean like new to programming or new to JavaScript who may not know. So let's let's give them a baseline and we'll move up from there.

Kevin Whinnery  [00:03:15]:
Yeah. Sounds great. So, so Deno is a JavaScript runtime, similar to, Node. Js or, or BUN. And it was originally created by Ryan Dahl who was the author of Node. Js about 10 or going on 15 years ago, now. And I had sort of came out of, wanting to address some problems and some issues that, Ryan had with Node. Js originally and some things that kind of he feel felt could have been done slightly better, slightly differently in the JavaScript runtime kind of built in the the modern era.

Kevin Whinnery  [00:03:51]:
So, Deno, is has support for, TypeScript natively. So instead of just, JavaScript code, you can use TypeScript code without, any third party tools or or a build step. And for those that are brand new, TypeScript is a compiled JavaScript language, which is strongly typed kind of similar to a Java or a c sharp. And it can help, by kind of surfacing compile time errors and provide type checking and, kind of makes the editing experience a little bit more on Rails and JavaScript where you could have a predictable interface that has great IDE support and things like that. Deno also, tries very hard to be as browser like a programming environment as possible. One thing about Node. Js that, as it was originally created, a lot of the web standard APIs that we enjoy in the browser today didn't exist. So there wasn't really a module system for creating reusable code.

Kevin Whinnery  [00:04:48]:
So Node. Js had common JS which is a, you know, older module format, that has since been superseded by ECMAScript, modules. There were, you know, no file system APIs. There was no built in HTTP request API, like the the fetch API that we have in the browser today. So Deno, wherever possible, tries to implement browser APIs to expose functionality instead of inventing kind of new APIs, whenever possible. And, another, thing with the Node ecosystem as it exists today is a lot of the tooling that you need to be productive, like a winter, a formatter, a test runner, lots of these different tools that where, you know, in a node project you're usually installing, you know, a dozen or more, dependencies before you even get started. A lot of those things have kind of been rolled into the DNOW runtime itself. So there is a formatter built in, a linter built in.

Kevin Whinnery  [00:05:40]:
There's even itself. So there's a formatter built in, a linter built in. There's even utility to, compile your DNOW program into a cross platform, executable. So a lot of the sort of key developer tools that you'll you'll tend to need in every project are included out of the box in Deno. Another thing that, Deno, does that is unique to JavaScript runtimes is providing kind of granular, controls over the execution environment of your code. So, by default, your code doesn't actually have access to the file system or the system environment, or the network. You as the developer kind of have to opt in to letting your code have access to those things. So say you're running in a secure CI environment and you don't want, you know, your code and any, you know, dependencies that you're bringing in, to have access to environment variables, say, you can execute your code with the least number of, you know, privileges possible within the underlying, execution environment.

Kevin Whinnery  [00:06:39]:
So that runtime security by default is also something that's, unique to Deno. So, yeah, it's a JavaScript runtime. It's built on Rust in Tokyo. It's quite fast, especially, sort of in comparison to similar, like, HTTP handling operations that, exist in Node. And, yeah. We hope, provides just a really nice developer experience that's a little more, you know, batteries included than something that you might have in Node today.

Dan Shappir [00:07:06]:
I have to ask because you just mentioned that. What is Tokyo? I'm I'm familiar with Rust, obviously, but I'm not familiar with Tokyo. What is that?

Kevin Whinnery  [00:07:14]:
Tokyo is a Rust library for doing asynchronous IO operations. So in Node, they have, libuv, which kind of provides a similar set of functionality. And Tokyo is, is the library to do, to provide a similar, set of functionality in Rust.

Dan Shappir [00:07:31]:
Interesting. And, so, listening to your description, I think it can might be best summed up as, Deno is node done right.

Kevin Whinnery  [00:07:43]:
Would that be interesting? Certainly, it's was kind of, envisioned in that way of, like, you know, if if we were to recreate Node and kind of with with the context that we have today, Deno is kind of the attempt at doing that.

Dan Shappir [00:07:57]:
I don't know

Steve Edwards [00:07:57]:
if I'd call it that indicates that node was done wrong. I think it's maybe a a better description to say node is done with what was available at the time, and now there's a lot of other things available and better ways to do things. So let's use those.

Kevin Whinnery  [00:08:11]:
Yeah. 15 minutes is a long time in tech. You know?

Charles Max Wood [00:08:13]:
Lots of

Kevin Whinnery  [00:08:13]:
things to learn.

Dan Shappir [00:08:14]:
Yep. And it's not just that. I mean, Node kind of paved the way. So a lot of things, you know, were created in an ad hoc kind of a way, and, you know, you don't always have all the context and all the information. And and by the time you have a better understanding of what it is that you actually want to do or or the way that it should be done, People are already using whatever you've created. And much like the web itself, there are no backsies. Yeah.

Kevin Whinnery  [00:08:45]:
Absolutely. Like, the the success of Node and NPM, just has, like, enshrined a lot of those patterns that we kind of take for granted in doing server side JavaScript today. Yeah. And Common JS is one of those examples. Right? Like, there wasn't a web standard module API, in, you know, 20, you know, what it was. It would have been, like, 2010, 20, when, like, Node was still originally being created. And, so Common JS was one of the ideas that was floating around that they implemented. And, yeah, it's just we've kind of standardized in certain directions or, like, we've learned things or, you know, create a new technology that didn't exist in those days.

Charles Max Wood [00:09:23]:
By the way I think the Node backsees is

Dan Shappir [00:09:26]:
Oh, go for it.

Charles Max Wood [00:09:27]:
I was gonna say, I think the Node backsees is really the best way of putting it where, Yeah. It's not that Node couldn't innovate in the ways that Deno is. It's more that, yeah, they had all of this stuff that, you know, had kind of been built onto it over time that people relied on. And, yeah, I mean, we see this in, in all kinds of stuff, including the ECMAScript standard. Right? They don't they don't kill stuff off, at least not very often. And so, you know, you have these people that rely on this stuff, and, yeah, you can't pull it back. And so the only way to move forward kind of like what Angular did way back in the day. Right? Moving from 1 to 2, Except they just kept the name and confused a bunch of people and it caused some issues for them.

Charles Max Wood [00:10:10]:
But, yeah, the same idea where it's okay, we need to move forward in these ways, but we can't do it without breaking compatibility in the background.

Dan Shappir [00:10:19]:
I think another great example of that is the use of promises and the single wait. If you look at the node APIs, you know, most of them were created, the at least the fundamental ones were created before promises were a thing, and, certainly, before the the JavaScript language had built in a single wait. So it it it uses different patterns. It uses patterns like callbacks and and stuff like that. And, with with Deno, I believe, much of the APIs, especially because it is trying to use modern web APIs whenever possible, Lot of these APIs are are promise based like like fetch.

Kevin Whinnery  [00:11:02]:
Yeah. Yeah. I mean, and since, like, Node, of course, a lot of the core APIs also provide a promise based interface that's sort of been grafted over the top of the, callback based interfaces. But yeah. I mean a lot of those, you know, the the web standard APIs like fetch are, you know, available. The and ECMAScript, language features that, do appear in Node and they and they will filter their way into, you know, into Node over time too will usually show up in Deno first. Like, for example for example, like, top level async await is something that you can do in Deno, which I think is behind a flag in node. I'd have to actually double check.

Kevin Whinnery  [00:11:43]:
I'm not sure if it's available with a flag or in some other context. But, yeah. So, like, these, for bleeding edge, what, ECMAScript language features, will tend to make their way into Deno a little, a little faster as well.

Dan Shappir [00:11:58]:
Now, one of the things that, node or Deno, sorry, created when it came about by the way, just if anybody if our listeners aren't didn't notice, aren't aware, Deno is literally node spelled backwards. Right? That's the the the point of the name.

Kevin Whinnery  [00:12:17]:
Yes. That is that is kind of where it came from. It's actually like if you were to sort the characters in node, that is how you get, Dino.

Dan Shappir [00:12:25]:
Oh, cool. So, one of the things that you also introduced in Deno, as I recall, is, like, a quote unquote standard library. Collection of, JavaScript or TypeScript utility functions and and objects and classes and whatnot that, can be used in the code. And if one of the things, by the way, that I find kind of unfortunate is that it seems that this, standard library did not make its way out of Deno into, the JavaScript community at large? I would have loved to see a lot of this functionality just generally available everywhere.

Kevin Whinnery  [00:13:05]:
Yeah. So the yeah. The Deno Standard Library, at least, until recently, was largely mostly usable in Deno. There there are ways to use it outside of the context of Deno. With the advent of JSR, which is a registry, I don't know if we'll get into it, you know, in this sort of conversation. The standard library has been published on JSR now as well. And since JSR, modules can be used in any runtime environment, the adenos standard library is now, you know, kind of available in node or, you know, in your ES build code for that you create for the browser, or in BUN. So a a lot of that stuff kind of has been freed from, Adena specific packaging.

Dan Shappir [00:13:47]:
That's excellent. I really hope that something like that library can become more than a quote unquote standard library, an actual standard library for JavaScript slash ECMAScript slash typescript. That would be awesome. It it just provides a lot of useful functionality that a lot of people end up recreating themselves on a, as a one off basis.

Kevin Whinnery  [00:14:11]:
Yeah. Yeah. For sure. Hopefully, that'll start to make its way out a little bit, as the, you know, as people start, you know, adapting or adopting JSR for, other

Dan Shappir [00:14:22]:
purposes too. Now you mentioned that one of the reasons that Deno can do all this stuff and kind of, you know, introduced all these innovations is the fact that unlike Node that has to contend with all the legacy, packages and legacy code and legacy functionality. You you had the ability to do a fresh start. I I guess in many ways, Ryan kind of decided to do, Dino because he understood that he can't do everything that he wants to do on the existing, node, code base. So my question then is, like, one of the primary reasons that people use node is because of this compatibility that it has with all these existing modules and and applications and whatnot. And and in many ways, they kind of depend on all this, like, not necessarily specified behavior that's built into node. Yeah. And not necessarily documented, you know, like, they depend on the bugs.

Dan Shappir [00:15:31]:
So the question is, oh, you you kind of if I understand correctly, you kinda need to compete with that. I mean, sure. If I'm starting a new project from scratch, then maybe I pick Deno. But then maybe I'm risking the fact that the package that I really want to use is not available for Deno. So how do I contend with that?

Kevin Whinnery  [00:15:51]:
Yeah. It's it's definitely been, like, the major challenge at the core of, like, how Deno has evolved, I would say, like, over the last, 5 years is, like, the the gravitational pull of, the NPM ecosystem is pretty strong. And there's just a lot of tooling and libraries that exist that exist there that, are kind of non optional in server side, JavaScript development today. So a lot of work on the Deno team these days goes into, our node compatibility layer where, yes, with Deno's design, we do want to maintain an environment where we do use ECMAScript modules only, and we don't, you know, support CommonJS, you know, as a, like, outside of this compatibility layer. And we do wanna favor, you know, web standard APIs whenever whenever possible. But the fact like, the sort of reality is that, a lot of the Node ecosystem is necessary if you want to be, if you would like to be productive in server side JavaScript today. So, the node compatibility layer in Deno allows you to use just about any package that exists in NPM. Like we have, shim APIs available for most of Node core, which then enables a lot of the NPM ecosystem to function on, on Deno.

Kevin Whinnery  [00:17:10]:
It is slightly different because the way in which you'd depend on a package, you know, could be a little different in deno than it was in node. But we've also, like, implemented a lot of compatibility features like, you know, by default in Deno, when you import a JavaScript file, you have to include the extension of that file. And, that's for a couple of reasons. Number 1, like, in the browser, if you're importing a file, like, you always include the extension of the file. So that's kind of where that design pattern came from. It's also slightly more efficient because, you know, instead if you leave off the, file extension, then, the runtime has to do a bunch of checking to see, like, are you actually trying to import a TSX file, a TS file, like a JS file? Like, there's a lot of sort of overhead that comes along with that. But, Deno, provides a mode, that is cheekily probably named, sloppy imports, which is like an option that you can pass into the runtime, which is tolerant of more node style imports that leave off the extension. And with a combination of some of these, compatibility features, you can take a lot of code that was originally written for Node.

Kevin Whinnery  [00:18:21]:
Js and run it in Deno without really having to change much of anything. And, the big push for us for Deno 2.0 for this year is, like, getting to the point where we feel like the vast majority of the most important node packages, just work in, in Deno. And I don't know if we'll ever like, our our goal isn't explicitly to get to, like, being a drop in replacement for node necessarily, but we want Next. Js to work on Deno. Like, we want, you know, all the web frameworks that you would want to use from the Node ecosystem to work really well on Deno as well. So, that's probably our our biggest, like, engineering, objective, like, over the next several months is just continuing to improve, like, the, the set of, compatibility features that we have for some of those undocumented features. Like, you know, when you npm install a module to node modules, you know, the NPM clients have certain behavior as far as like how those modules are unpacked, which then other modules depend on. Like, I think, like, if you install Tailwind, it expects, like, post CSS or something to be to be have been already installed, and it actually introspects the contents of the node modules folder to do, some things to use that, dependency.

Kevin Whinnery  [00:19:39]:
So the node ecosystem is just kinda full of these little, nooks and crannies and, like, strange behaviors that have been built on top of that we're, you know, trying to find the best way as possible to, like, support those, while still providing, like, the DX that we wanna provide through Gmail.

Dan Shappir [00:19:57]:
You know what this kind of reminds me of? It kind of reminds me of, the Windows world. A lot of our listeners might be too young to remember that, but for a long time, when Windows was, like, the primary platform for which software was being written. Windows, itself had all these bugs going from version to version, and they literally had to, you know, when they created a new version of Windows, maybe even using a different technology, they often had to actually emulate buggy behavior just in order to make sure that, older software continued to run because, you know, if if you upgraded your Windows and all of a sudden your favorite game stopped working, you would blame Microsoft, not the game not the game creator.

Kevin Whinnery  [00:20:41]:
Yeah. I was gonna say I had to run, TIE Fighter in Windows 95 compatibility mode for a long time, until, you know, I found, like, a more modern core to it, that I could use otherwise.

Dan Shappir [00:20:54]:
So but I do have to ask. I mean, if you're putting in all this effort, and it seems like a huge amount of effort, into emulating node on top of Dino, as it were, to an extent, then, like, why do I want to go with emulation? Why shouldn't I just pick the original? What's the main benefit for me as a back end JavaScript developer or a full stack JavaScript developer using Deno over node, especially if if I do assume that I want to be using, you know, all this functionality that exists and not write everything from scratch?

Kevin Whinnery  [00:21:35]:
Yeah. So, I mean, I think there's a couple of reasons. The, first one is probably just reducing, kind of the startup costs and complexity of your project where, like, you do have TypeScript built in by default. You have the tester, linter, formatter, all of those, like, tools available out of the box. So the developer experience of, like, not having to manage those things and being able to keep your code a little leaner, and not have quite so many third party dependencies, is potentially somewhat attractive. Also, like a lot of the libraries that you use in Node today probably are just like a little bit faster on Deno. So like if an Express server that you wrote in Node is just gonna be probably a little bit faster in Deno than it is in, than it is running on Node. And kind of I there's a lot of, you know, contextual things there for like which, you know, packages and what set of maybe middlewares you're using.

Kevin Whinnery  [00:22:32]:
But a a I just actually saw a post, like, over the weekend about, you know, there's a, HTTP framework called Oak, which is like a middleware framework sort of inspired by, Koa. And, the author tested it across, you know, BUN and Node and Deno, to kind of see what, the performance characteristics were. And, no and Deno and Bun were, you know, about the same. The Bun was actually ran ran HTTP requests slightly faster. As like a maybe 10% increase in overall throughput. But both were like twice as fast as node. So I think there's kind of some things that you get for free, by switching to, switching to d now as well.

Dan Shappir [00:23:12]:
And you were able to keep or maintain this, performance benefit even when adding the backward compatibility with node? I mean, that would seem to be the challenge. I would imagine that with node, improving performance in a lot of places kind of runs smack dab into the problem of maintaining backward compatibility.

Kevin Whinnery  [00:23:36]:
Yeah. I mean, there's, there's certainly challenges with that. But, I mean, the the shim API sort of created for, like, the underlying HTTP, you know, node core APIs, utilize the same sort of, opt or they they get to benefit from the same optimizations we've made in Deno to make HTTP request handling fast. So, those shim APIs do tend to perform pretty well. So like we, you know, have been doing some testing with web frameworks like, Astro, say, and just using the, sort of node, adapter for Astro, which which enables, like, server side rendering of, you know, pages in that framework, those node APIs actually run slightly faster on Deno, for server side rendering than they do in in node. And I think it's just because of, you know, the underlying infrastructure being, you know, slight like, being slightly more performing. Not necessarily because Deno for, you know, is intrinsically always faster than, node. It's just that, you know, and it's not like, you know, node couldn't be this fast potentially.

Kevin Whinnery  [00:24:47]:
C is certainly, you know, just as fast as Rust or c c plus plus or whatever. But, yeah, it's just the, a lot of work has gone into, optimizing the HTTP, interfaces. Do you know?

Dan Shappir [00:25:00]:
I think it's also, legitimate, I would say, for, the performance improvements to be let's put it differently. It's okay for the shims to run slower if the code that doesn't need the shims can run faster. If you understand what I'm trying to say. So as long as I don't need some weird node functionality for backward compatibility, the standard stuff, if that runs faster, I'm happy with that even if the shims themselves, like, pay a certain price. But, I, you wanted to ask something about the built in TypeScript, support that you mentioned before. So I actually posted the link in our chat to a great quote from, Matteo Colina, who's really deep in the node world, by the way. He's one of the maintainers, I think, of Node. And he wrote some, a tweet recently, which was really amusing and eye opening to an extent, which is TypeScript does not exist.

Dan Shappir [00:26:04]:
There's a multiverse of TypeScript implementations depending on the permutation of the configs. And he added also to that, this kind of weirdness are the key reasons why I'm still skeptical about the TypeScript. Now I'm not skeptical about TypeScript, but I definitely appreciate what he said. The fact that, you know, the the different values that you put in your TS config file, can significantly impact the functionality the behavior of TypeScript. Or put another way, kinda means that TypeScript is less than, of a language standard and more of a utility that you can configure, in a sense. So my question is, how does Deno deal with that? I mean, is it using the same TS config as TypeScript or is is is TSC or something else? How how does that work?

Kevin Whinnery  [00:27:02]:
I mean, there's a sort of a I I think, like, what Matteo is saying is correct. Right? Like, the, like, the configurability of TypeScript does introduce a lot of different permutations of how TypeScript can behave. One, I think, benefit in the context of Deno is that, you know, there is a set of behavior that's sort of codified in how TypeScript runs on, Deno. So there isn't sort of an unlimited amount of configurability for, like, compiler options and stuff like that. There is certainly is some and there are some, you know, of those configure out configuration options that do still, work in Deno. But the TypeScript environment is relatively predictable versus in, in node where you do have, like, kind of full configurability of how the, TSC or, like, how TSC works at the end of the day. So, yeah. But, like, the the, point stands that, you know, if you have access to all those compiler options, it makes it very difficult to write TypeScript code that, you know, can very can predictably run, with every set of compiler options.

Charles Max Wood [00:28:10]:
So am I stuck then with how you did it then?

Kevin Whinnery  [00:28:14]:
To a degree. Right? Like, so there there are certain things that are configurable. There are certain things that are not. So there's probably features of, like tsconfig that would work in a node environment that are impossible in Deno, just because we don't support those those options. So it is a constraint that exists for sure.

Dan Shappir [00:28:36]:
By the way, not supporting some TS config options is actually a good thing because I've literally seen projects that were configured in such a way that, interface definitions weren't weren't each actually even being used, and the developers didn't even notice. So, like, there were incorrect types and and literally types with with errors in them. And the project seemed to compile fine because any everything that was using, like, an unrecogn the imports didn't actually work, and anything that used an an, an interface that wasn't specified defaulted to any instead. So they basically had everything as any, but they were they thought they were writing TypeScript, but actually had everything as any, which is, like, the worst of all possible worlds.

Kevin Whinnery  [00:29:24]:
Yeah. So all all the overhead of using TSC with none of the actual compile time safety. Yeah. That seems exactly.

Dan Shappir [00:29:33]:
Exactly. So if if you're prevented from being able to do that, I would definitely count that as a good thing. But what is the actual benefit of having the TypeScript functionality built into the into the environment? I mean or or let's put it differently. With TypeScript, I see 2 main benefits. 1 is while I'm writing the code in the development environment, in, let's say, Versus Code, it does all the type checking for me, the squiggly lines, the completion, stuff like that. And and and highlights files that has error have errors in them and so forth. The other advantage is is the actual the actual compilation step to an extent because if I have errors in my, you know, type errors in my code and not a too funky TS config, settings, then the build step will actually fail if I try to, build something bad. So because I'm ignoring squiggly lines in Versus Code for some reason.

Dan Shappir [00:30:37]:
So my question is, you know, with with Deno, you don't need that build step or you don't have that build step. So am I maybe kind of even losing some benefits of TypeScript by working this way? And, alternatively, what are the advantages of working this way?

Kevin Whinnery  [00:30:56]:
Actually, so there is still a build step that happens. Like, so there's a Rust based, sort of, equivalent of TSC, which we would use, sort of at runtime to generate, the JavaScript code. Because, like, Geno runs, JavaScript code in v eight, similar to how, Node does. So we still do need to transpile, TypeScript before it's able to run-in that environment, because v eight doesn't natively understand, TypeScript. So there is a, sort of build build step that happens, as a result of running your code on DNOW. It's just that it is, opaque in that, like, to you as a developer, it doesn't seem like you need to handle that, even though it is happening for you behind the scenes. I think the advantage of having TypeScript built in largely comes from how you get to manage your source code. So, you know you can you know version control TypeScript and you can, you know in the case of you know, JSR, you can publish TypeScript directly to the registry.

Kevin Whinnery  [00:32:01]:
Other TypeScript developers don't have to rely on your transpiled code. They could actually import TypeScript source code that you have written into their project, should they should they need to. So being able to just actually manage your your code base as TypeScript without, having to think about transpilation as a part of that, ends up being ends up being kinda nice in a lot of, a lot of different contexts.

Dan Shappir [00:32:25]:
So it's basically reducing friction in the development process?

Kevin Whinnery  [00:32:29]:
Yeah. Yeah. Kind of friction, kind of the overhead of that transpiration process. Like, you do you kind of don't have to consider it, within your workflow.

Steve Edwards [00:32:38]:
So side note really quick. Am I the only one that thinks of vegetable juice when I hear v 8?

Kevin Whinnery  [00:32:44]:
There was a time. I think I've gotten I should've had a v eight about

Charles Max Wood [00:32:47]:
nice cars.

Steve Edwards [00:32:48]:
You. Yeah. Or, yeah, I've Oh, I think car too. You know, I should've had a v eight commercials for those who are too young to remember that. Anyway

Dan Shappir [00:32:56]:
Yeah. But it's, TypeScript is not the only thing that you built in. I think you mentioned it that you've also got, like, a testing framework built in. You've got a linter built in. Can you elaborate about these a little bit?

Kevin Whinnery  [00:33:09]:
Yeah. Sure. So, yeah, so Deno has, like, a a a test command that's built in. If you run, like, Deno help after you install Deno, you can get a sense of, like, what all these, command line tools are. But, yeah, it was really about, like, there there's a lot of decisions that you make when you're bootstrapping a node project that aren't really that important, like, which test framework you use. Possibly not that important, which linter you use and what your linter settings are, what your format or settings are. Probably also not important. Like, you can kind of bike shed on these things if that's, if that is your preference.

Kevin Whinnery  [00:33:45]:
But, also, I just think that, you know, accepting a set of defaults, tends to be kind of nice. One one thing that I've really noticed is as I've gone between different Deno projects, because the testing framework is the same, because the winter settings are the same, and the formatter settings are the same, like, it's much less jarring to kind of go from 1 Deno project to the next because, like, the lay of the land is pretty similar. So, like, having this, sort of similarity, is useful to you as a developer because it takes, like, kind of trivial decisions, you know, out of your hands. I'm like, I mean, you certainly could use other test frameworks if you want, but, you know, you don't necessarily have to make those decisions, and it helps you kind of go from one project to the next. I used to use, Ruby on Rails for a long time, and that was one thing that was kind of nice about a lot of those projects was, I knew the models were in this folder. And, like, a lot of those conventions kind of helped me, like, navigate those projects even if I was relatively new to them. I like, Rails projects can be very, you know, diverse in a lot of other ways. But, like, some of that similarities is helpful.

Kevin Whinnery  [00:34:52]:
In terms of, like, the other tools that are built in, I mentioned, Deno compile, which, you know, you can point at a TypeScript source code file. And it generates a binary that can be run, cross platform. So I guess it's a good way to kind of compartmentalize like a web server, say, into just a binary that you can run on, you know, an arbitrary server somewhere. Or if you're making a command line utility, it's a really easy way to create, like, a cross platform command line utility. So, t, which is the, package manager, that is was replacing Homebrew or, like, the original author of Homebrew used, Deno to create key, which is kind of his sort of next generation version of that package manager. And, he used Deno for this reason, actually because he wanted to write TypeScript. Wasn't necessarily interested in, you know, having that, transpilation step and, the ability of Deno to package up a cross platform, executable was convenient there as well. So, deno compile, super useful.

Kevin Whinnery  [00:35:56]:
Certainly, a few other nice so there's a deno doc, which is also a built in utility, and you can point it at a TypeScript file, or a, dotd.ts file. And it'll kind of introspect those files and generate HTML documentation for your, you know, for your TypeScript source or from your type, configuration. So yeah. So there ends up being kind of a lot in the box, which is, which is pretty nice.

Dan Shappir [00:36:22]:
By the way, does your TypeScript implementation also support JSDoc?

Kevin Whinnery  [00:36:28]:
Yes. It does. So, yeah, it that's that's kind of where it's pulling a lot of that. It'll pull documentation content from JS dot comments if they, if they exist. It'll and it can guess a lot just from, type information as well.

Dan Shappir [00:36:41]:
AJ would be happy. So I I'm old enough to remember the the Unix days that the whole point was one of the big selling points was that a lot of those, built commands that are were built into other operating systems in the UNIX world were implemented as as separate, executables or or and ran as as distinct user land processes and weren't really built into Unix itself. But now it seems like with you and with Bun, that everything is kind of being built into the main to that single executable. Like, Deno, with the one command line switch does one thing, with a different command line switch does some other thing. What's the the motivation? What's the advantage of of bundling all this functionality? You know, some of which could definitely be, like, distinct and stand alone. I mean, like the test runner. Now, like, why what's the benefit of having it built into that same executable and not being split off into a separate executable file?

Kevin Whinnery  [00:37:49]:
I think, like, it it's kind of, you know, you're deciding where and when to manage complexity within your project. Like, if you are using, you know, some kind of utility in user land, the complexity that comes along with that is keeping that dependency up to date and, whatever plumbing needs to happen to kind of pipe the input and output from, like, one utility into the next. And, you know, the UNIX philosophy is definitely, one of the reasons that that, like, operating system has been so popular and continues to be, like, one of the best options for especially, like, technical, you sort of, technical use cases or, like, running code, on servers, that sort of thing. But the, the price that you pay in, like, a application programming tool, like, you something that's a little higher level like a Deno or a Node or a BUN is that, you know, the things that you will tend to need over and over again you have to sort of reinvent, every single time you create a new project. And the overhead of, you know, the startup costs and maintaining, you know, a package. Json that has, 12 dependencies in it, none of which are actually have anything to do with the functionality or project. It's just like the tooling that you need to actually build your code, test your code, lint your code, that sort of thing. There there's a price that comes with that as well.

Kevin Whinnery  [00:39:22]:
There's certainly flexibility. But, when you consider the trade offs of, like, okay. I now I have, you know, this this, dependency on jest, and it depends on this other thing. And now when I run, you know, npm install, I get these these conflicts that I have to, kind of work my way through and then I have to update upgrade this dependency, etcetera. So, like, taking dependencies out of the mix, reduces the, like, maintenance complexity in a pretty, meaningful way, that I think is kind of worth the trade off in at least in this instance. But, you know, there's certainly arguments to be made the other way that, you know, a lot of these utilities certainly could be, user land tools and Evolve separately. But because they're kind of core to any application that's nontrivial, including them as part of the platform, tends to be a trade off that, that helps.

Dan Shappir [00:40:18]:
So if I'm using Deno, then I likely won't install Prettier and ESLint and TS, ESLint, and stuff like that? I'll just use whatever is built in?

Kevin Whinnery  [00:40:29]:
Yep. That that is the intent that you wouldn't necessarily have to bring those tools in, unless you're using Deno in the context of an existing node project, in which case you might still, you know, have those tools around. But, yeah, in a Deno project, the expectation is you won't need to have

Dan Shappir [00:40:47]:
those things. Cool.

Charles Max Wood [00:40:49]:
I'm I'm kinda curious. I'm gonna change gears on a little bit. How did you get into Deno? Right? What what's your story here?

Kevin Whinnery  [00:40:59]:
Yeah. So I've been, you know, a Node. Js user since, like, I think the first code I wrote was for 0.8 of, Node. And at that time, I was working at a company called Twilio, which is like an API provider Uh-huh. For, like, messaging, telephony, stuff like that. And, node was pretty new. And I was like, oh, Twilio. We should totally have, like, a client library for this Node thing.

Kevin Whinnery  [00:41:22]:
I think I think this I think it has legs. I think it's gonna go somewhere. So I I wrote, like, a htp client wrapper for, like, the Twilio API, in Node back in those days. And, the thing and I kind of, fell in love with it because, like, finally, this my investment in, JavaScript, I could now use JavaScript to program every kind of thing, like from servers to front end or robots, everything in between. So, using JavaScript as kind of the lingua franca of web development has kind of kept me involved in server side JavaScript for a long time. But I think like like a lot of Node users, like, over time, you started to get the, the feeling that Node had jumped the shark a little bit where it's just like I look at a standard Node project and I look at all these configuration files that I have without ever even having, like, written any code. Like, there there is certainly a certain amount of discontent with, how much complexity it kind of crept into the ecosystem. So, the prospect of having the this this set of, decisions that are kind of trivial, made for me was was pretty compelling.

Kevin Whinnery  [00:42:32]:
And so so like I the the lure of Deno as a technology kind of started from there of like having this sense that, you know, complexity had been creeping into node and, the experience of using Deno, was something where, like, once I used it once, I was like, okay. Like, I'll probably be a little grumpy. Like, if I have to use Node without Deno again because, like, if I have to configure, you know, tsconfig or webpack for these purposes again, I'll probably be a little little sad.

Dan Shappir [00:43:00]:
Or wait a minute. You mentioned webpack. Maybe you mentioned it before and I kinda missed it. But does that mean that Deno also has a built in bundler?

Kevin Whinnery  [00:43:09]:
So there there is a was a built in bundler that was deprecated in, you know, a previous version of Deno. It's something that we're kind of looking at again, but, like, ES build works pretty well in the Deno ecosystem, like, for that purpose. So it hasn't been, like, super high priority. But the webpack as like a way of running, like build like transpiling server side code even was something that I had to contend with at least in my, you know, projects that we're using Node. So, like compiling like SCSS say like as a part of, you know, those projects. So a lot of those, tools, I find I need to use less in, in Deno.

Dan Shappir [00:43:56]:
Which So can go for it, Chuck. Sorry.

Charles Max Wood [00:43:59]:
I was gonna push us back to the story just a little bit. So it wasn't any one particular project. It was just kind of, your workflow that pushed you toward Deno, it sounds like. I guess my other question is, and I'm always curious about this is right now, you're actually working for the organization that gives us Deno. How did that come about? Was it just your involvement in the project, or was there something else? Did you know someone?

Kevin Whinnery  [00:44:26]:
I've been sort of around the project for some amount of time, but they, decided they wanted to, like, have a formal DevRel, program. Okay. And I actually wasn't aware of it. But, somebody from the team reached out to me and was like, hey. We're looking at doing a DevRel program. Is this something you'd be interested in? I was like, Yeah. Yeah. I totally would be interested, because I had been pretty stoked about the the technology for a while.

Kevin Whinnery  [00:44:52]:
So it kind of came, through, some outreach from the company at the time.

Charles Max Wood [00:44:57]:
Okay. Cool.

Dan Shappir [00:44:59]:
If I'm pulling us back a little bit towards the technology side, it seems that more and more, node in the context of, full stack applications, will be running in the context of some sort of meta framework. Like, it it won't be you might not be using Node on its own. You might be using it with an JS or an Astro or, you know, whatever. And so my question is, how does Deno fit into this kind of, brave new world of meta frameworks that are full stack. Does it just work out of the box? Like, when I when I install Next. Js, How, you know, what how does Deno fit into that installation process?

Kevin Whinnery  [00:45:54]:
So the there's kind of a a spectrum of how well Deno works with a lot of the meta frameworks in the node ecosystem. But, even just within if you're just talking about, like, first party, like, Deno frameworks, you will probably be using some kind of meta framework along with Deno. Fresh is kind of the first party one that the Deno team maintains, which is sort of designed to run on edge servers and implements like an island architecture similar similar to Astro and other there's a lot of other frameworks doing it in that in that way. But the assumption is that, you know, 0 JavaScript is sent to the client by default and we push more rendering to the to the server. So, certainly, that's one of the options. Another, meta framework that works really well in By the

Dan Shappir [00:46:44]:
way, just before you move on to the to another one Yeah. Correct me if I'm wrong. I think that Fresh is kind of built on on Preact. Right?

Kevin Whinnery  [00:46:53]:
It is. Yeah. So, actually, one of the, maintainers of Preact, Marvin Hagemaster, is a member of the Deno team now, and is the primary maintainer of Fresh as well. So, yeah, Preact definitely core technology there. Yeah. And then if, for other I mean, there's certainly other meta frameworks that you can use, in Deno. The other, like, notable one I'd point out is, Hono, which is, maintained by, the Cloudflare team, actually. It's sort of like the spiritual successor, I would say, to, like, Express and Sinatra from the Ruby world.

Kevin Whinnery  [00:47:28]:
Where I've found Hono to scale up like pretty nicely. So it can start from like single file web servers And, you know, it actually scales up to reasonably complex use cases pretty well. So, Hono and, and Fresh are probably 2 of the best options that exist just that work natively in Deno. But from the node ecosystem, that that's, like, one of the big challenges that we're trying to address with Deno 2 is getting more of those meta frameworks to work really well in, in Deno. Some of them work pretty well today. So, like, if you worked a lot of the frameworks that use Vite as a build toolchain, under the covers. So, like, Astro would be one of them, SvelteKit. Yeah.

Kevin Whinnery  [00:48:12]:
Noxt would be would be another. Those frameworks tend to work pretty well in Deno because Vite, works, quite well for the most part in, in Deno. So a lot of those build steps, work mostly out of the box. Like, there's some edge cases depending on, like, which parts of the ecosystem you're trying to leverage. There might be plugins that may or may not work. But, yeah, like the the node adapter. So Astro has this concept of adapters you know, server side rendering in different environments, like in CloudFlutter workers or Node or or whatever it would happen to be. And, there is a Deno Astro adapter, which, is a little bit out of repair.

Kevin Whinnery  [00:48:55]:
Right? And that's largely largely my fault. I haven't had a chance to update the adapter yet. But the node adapter for Astro works works great, and you can use that today. There's a SvelteKit adapter for Node that works great in Deno today. There's also, like, a community maintained SvelteKit adapter that is natively deno. That works really well. Nuxt is in a kind of a similar position. So a lot of those, those types of frameworks do work really well.

Kevin Whinnery  [00:49:24]:
Next. Js is kind of a different beast though, and it kind of leverages a lot of behavior in node that we have not been able to model, like, 1 to 1 in such a way where, like, next is a good experience, specifically. But, that is, an obsession, that currently exists on the Deno team is to figure out how to make our next, run really well as well. So, certainly That's good. A goal.

Dan Shappir [00:49:48]:
Yeah. That's kind of important. I mean, not, putting down any of the other frameworks, but just numbers wise, Next. Js is more or less, like, as big as all the other meta frameworks combined. So so yeah.

Kevin Whinnery  [00:50:02]:
Yeah. No. Definitely not lost on the crew, here at, Deno for sure. It is the necessity to have a acceptable experience there. So, I think we'll get there, but that that is, like, a big, project for us right now and something that we're kind of gating our 2 point o launch on is, like, how well we're we feel that we support those crucial meta frameworks from Node.

Steve Edwards [00:50:25]:
I guess you can say it's the next big thing. Right, Dan?

Kevin Whinnery  [00:50:29]:
We're good. I'm ready to make a sound board. Well played, Steve. Well played.

Dan Shappir [00:50:33]:
Yeah. And especially given that I work what's

Charles Max Wood [00:50:36]:
next. But anyway Yeah.

Dan Shappir [00:50:37]:
And and especially given that that I work at the company called Next Insurance that has nothing to do with Nextjet except that we actually except that we actually do use it in, for you know? But anyway Is

Kevin Whinnery  [00:50:50]:
it time for the next question yet? I mean

Dan Shappir [00:50:53]:
Yeah. I I think we're starting we're we're starting to to approach the end of our show, and it seems like we're not really going to be able to cover JSR this time. So we probably will need to invite you over again to talk about it. The one thing that I want to to kind of ask you about before we we wrap up is something that you kind of alluded to multiple times during the conversation, and that's the edge computing story. I think there is, like, this is one of your strengths, I believe, the ability to run on the edge. How how does that how do you differ with in node in that regard? Do you differ from node? What are the advantages of of running Deno in that scenario? What are the advantages of the edge in general? So go for it. Yeah.

Kevin Whinnery  [00:51:39]:
Sure. We can try to, yeah, unpack that a little bit. So the one one thing that is useful about, how Deno works is a lot of the core functionality in Deno is based on, like, web standard APIs that are available in the browser. And that becomes important because when you're running JavaScript, on the server on the Edge, you are running it in a V eight isolate which you want to be able to sort of spin up and tear down very quickly. And that's kind of one of the primary advantages of running on the edge is that instead of, you know, a virtual machine that needs to be sort of spun up and spun down like with a with a Lambda say or like some or like another container hosting solution. A JavaScript environment can, it can manage a pool of v eight isolates similar to, like, a browser tab in your in your browser, which are very sort of cheap and easy to create and, and tear down. So the cold start times for those, isolates can be really, really nice, in a lot of scenarios. And the fact that Deno can run really well in a lightweight, JavaScript environment like that one, is one of the advantages that sort of makes it work well in that scenario.

Kevin Whinnery  [00:52:59]:
So, denode is being used in, sort of edge edge functions in a few different contexts. So, like, if you use Netlify Edge Functions, that actually runs, on Deno and Deno's cloud infrastructure sort of behind the scenes. For a long time, Supabase's edge functions also ran on our cloud infrastructure. They've since, like, taken Deno and created their own, edge infrastructure based on Deno, that they're building on as well, which is awesome. They've got they've been doing some really cool work there with the open source runtime. So yeah. So there's I think it's the relationship between, like, Deno being able to run really well in a browser like environment and the fact that you need to be able to run those lightweight v eight isolates on the edge, maybe makes it ideally suited for, those environments. And then yeah.

Kevin Whinnery  [00:53:52]:
I think, like, the the advantage generally of doing, you know, processing on the server on the edge is is latency. So if you can do compute tasks, and on, you know, servers that are geographically close to your users, That's gonna result in, you know, faster round trips. There can be like data residency requirements that can be satisfied potentially through where your code executes. There's other like types of functionality that can be that is maybe optimally done on the edge. Like, whether it's, like manipulating headers for an HTTP request or, like, doing image processing. There there's scenarios in which, you know, being able to execute that logic close to users is is important. Or if you are doing, have like an application architecture that leans heavily on server side rendering, doing that server side rendering on edge servers, can be can be beneficial as well. So not every request to generate dynamic HTML has to go to, like, a data center in Virginia.

Kevin Whinnery  [00:55:00]:
You can do that, maybe a little closer to where your users are.

Dan Shappir [00:55:04]:
The one thing that you really need to be careful about is the latency of your access to the data. Because if you're running compute on the edge but your data is still back at the data center, you might actually end up hurting performance rather than improving it because you use significant you may significantly increase the latency of data access. So you really need to think about that aspect of of your solution or implementation.

Kevin Whinnery  [00:55:33]:
Yeah. For sure. I think it's, you're starting to see, like, more, database vendors, and those types of services popping up where they're sort of natively designed to be access from edge servers, which is which is cool. But it is certainly, you know, one of the architectural concerns that you have to think through.

Dan Shappir [00:55:52]:
Now one more question that I have is this. So it's it's dito.com, which means that you're an actual company. You're not just an open source project. Right? Mhmm. So what's how do you plan to be, like, you know, to make money? To be, to make sure that the project survives be and the company doesn't go under? Like, what's what's the what's the value proposition in terms of of, you know, generating generating funds?

Kevin Whinnery  [00:56:25]:
Yeah. So it's, the place where we found success so far is around, like, that edge computing infrastructure. So the, one of the paid offerings that, Dino, the company has today is something called, sub hosting, which is a way to, like, sort of take, untrusted code and execute it within, like, a cloud environment. So, like, I used to work at Twilio and Twilio has this thing called Twilio functions, which is, like, you can give Twilio a chunk of JavaScript code and it'll run that JavaScript code whenever you get an incoming text message or phone call or whatever. And there's actually a lot of SaaS platforms or developer tool platforms that want to offer this functionality where we'll execute some code for you when this integration event or this other event happens, somewhere in our system. And, Deno has a platform for, very quickly building that out kind of based on this edge computing infrastructure that we created for, Deno Deploy, which is a, like an edge function, hosting platform, which is, sort of generally available to anyone, to you know, you can run full web applications on it or specifically, you know, edge functions. So the I think, like, the cloud infrastructure is where a a lot of the, like, revenue growth is gonna be in the future. And but, like, the open source runtime and also, JSR, which we'll talk about next time, are both, like, free and open source and will be that way sort of indefinitely.

Kevin Whinnery  [00:57:57]:
And we think, like, those two things being successful as open source projects will be a headwind for some of, like, the the cloud based stuff that we think will, support the the company.

Dan Shappir [00:58:09]:
So just to to make sure that I understand yeah. Just to make sure that I understand, in a sense, you're kind of competing with cloud Cloudflare Workers, like, providing an alternative to their solution?

Kevin Whinnery  [00:58:25]:
Yeah. The so the, edge hosting infrastructure is in the similar space to workers. The sub hosting, API that I talked about for running on trusted code, also is kind of in the same space. Like, Cloudflare has a, like, an enterprise offering in that realm. I don't know if it's self-service yet, but there there there's, like, a workers for enterprise or workers for platforms or something, I think it's called, that does a similar, thing. So that's probably the nearest competitive solution. And I think, like, the like, Deno and Cloudflare are kind of the 2 ways you can do edge compute, these days. Like, workers and Deno deploy are kind of the only game in time in town.

Kevin Whinnery  [00:59:06]:
So, like, Vercel Edge functions say, like, uses workers under the hood, today. So, yeah. So it is kind of similar to that that solution. Cool. Yeah. Yeah. Very cool.

Charles Max Wood [00:59:20]:
Yep. If you could tell us here within, like, 2 minutes because I I do have a hard stop at 10:30 mountain time. 2 second or 2 minutes. What's coming next in, Deno?

Kevin Whinnery  [00:59:34]:
Yeah. So, as I kind of have alluded to, like, node compatibility is a huge focus for the team right now. So increasing the amount of the node ecosystem that runs with node configuration, within Deno is kind of the biggest engineering goal in front of us for the Deno runtime itself. The other other bits that are coming out are you know continued improvement of integration with JSR and tooling around publishing to the JSR registry and making JSR work really well across every runtime from BUN to Deno to Node to Cloudflare Workers and Browsers and Everything in Between. So the Node compatibility and JSR are gonna be the continued, you know, focus for

Charles Max Wood [01:00:24]:
us. Awesome. Alright. Well, let's go ahead and do our picks, and then we'll wrap up. Steve, what are your picks?

Steve Edwards [01:00:32]:
Oh, we're gonna start with the high point first. Okay. So real quick, before I get to the real high point, blog post interesting when I saw on Hacker News today, interesting when I saw on Hacker News today, regarding the classic and long running debate of tabs versus spaces. And, the title of the blog post is new data shows tabs are more popular than spaces, but spaces users are happier. And and so what it is is there's a a company that surveyed the Lunduke Journal, l u n d u k e, and surveyed 72 100 IT professionals and computer nerds. And they asked all kinds of questions about what they use and then tried to associate tabs user versus spaCy's users with other things such as which text editors do they use, what OSs do they use, what web browsers do they use, and is there any correlation with age and politics and so on and so forth? It's really sort of entertaining. So I found it, quite interesting.

Dan Shappir [01:01:38]:
I just put a link in our chat about the white space programming language. Are you familiar with it?

Steve Edwards [01:01:44]:
Well, I know what You mean Python? Are you talking about? Yeah.

Dan Shappir [01:01:47]:
White space is an actual programming language that just uses white space characters for programming. So it uses all the instructions are coded as as, you know, spaces, tabs, new lines, and stuff like that. And, the advantage is that you can write your code within the file of some other programming languages code. So you can have, like, 2 programs in the same source file. And, you know, it might be interesting if Deno had built in support for the white space programming language.

Steve Edwards [01:02:21]:
Oh, man. They'll get right on that. Right?

Kevin Whinnery  [01:02:23]:
Yeah. Yeah. Exactly. We'll, file that away, as a high priority issue for sure.

Steve Edwards [01:02:28]:
Yeah. I'm gonna guess that with if you're writing with white spaces, you always

Dan Shappir [01:02:33]:
have to use a dark background. Right? Not for sure. Right.

Steve Edwards [01:02:37]:
Okay. And now for the the dad jokes of the week. So, you know, in past years, I've done, you know, a lot of interviewing of job candidates, and I was and it's usually me asking the questions, but this recent guy was I was interviewing and we were talking about money and and he said, well, what does a competitive salary even mean? I said, well, it just means that your salary is competing against your bills.

Dan Shappir [01:03:06]:
Now this day these days, it's not it's it's not as amusing, let's put it this way, as it was, let's say, 2 years ago.

Steve Edwards [01:03:13]:
Right. The bills are winning. Do you know that alligators can live up to live to be up to 70 years old? That's why there's a very an increased chance that they will see you later.

Kevin Whinnery  [01:03:27]:
Alright. I like that one. That was a good one, actually.

Steve Edwards [01:03:29]:
See you later, Alligator. Yeah. And then, some deep thoughts for the day if any and anybody remembers Jack Handy from Saturday Night Live. So what happens if you get scared to death twice? Is the s or the c silent in scent? And then finally, the same and similar. Are they the same, or are they similar?

Dan Shappir [01:03:57]:
It's it's like that old saying that, in theory, theory and practice are the same thing, but in practice, they aren't.

Steve Edwards [01:04:04]:
Right. Exactly. Those are my picks of the week.

Charles Max Wood [01:04:09]:
Alright. You wanna put that link in the to that article in the comments? And that way we can,

Steve Edwards [01:04:15]:
have a look at it. Yes.

Charles Max Wood [01:04:17]:
Alright. Dan, what are your picks?

Dan Shappir [01:04:20]:
Not a lot of picks this time. We started watching a new, TV series on, Netflix. It's a really new one. It's called The Gentlemen. It's an action comedy television series created by Guy Ritchie. And, you know, with Guy Ritchie, it's, it can be hit or miss, but when it's a hit, it's a hit. So he he created, this kind of, spin off from his, 9th, from his 2019 film that had the same name. So it's kind of, the same sort of settings and characters.

Dan Shappir [01:04:55]:
And so far, we're enjoying it quite a lot. We really only watched 1 the 1 the first episode, but so far so good. It's like this, this guy that turns out that he's a duke inherited, is, the the title and the state from his dad. And it turns out that, it's actually the state that his dad actually rented out the state to the mob to, to pack weed there. They they have, like, this huge weed factory on there, and he now has to deal with all these, mob characters and whatnot. And, you know, it'll it it's and, you know, if you've seen guy guy Ritchie's movies, you know you know, kind of the the setting and how the characters the sort of characters that you encounter there. And, you know, so so far so good. We we we are really enjoying it so far.

Dan Shappir [01:05:51]:
And I guess oh, one more thing is, we are I'm kind of clearing up my my my own, like, personal library at at home, like, actual books. Like, we've gotten to the point that we had, like, 3 rows of books in the libraries, one behind the other, and it was kind of, you know things are starting to fall off the shelves. So I'm really getting rid of, various books that I don't need anymore. And it's interesting to go, like, to go through the books and decide what which ones you wanna keep and which one, you know, you you let, you give away to a library or whatever. And, I'm thinking of maybe, like, I think, like, a few years back, I did, I I one of some of my picks were about, these old, science fiction and fantasy books that people do and, don't remember anymore. Some of them are really excellent. Now that I'm seeing those books again, maybe I'll revisit that as well. I'm just not prepared yet.

Dan Shappir [01:06:50]:
So if people or if if you guys or listeners are interested in, in some excellent, you know, sci fi books or fantasy books that you've probably haven't heard of before, then let me know when I'll do that. And those are my picks for today.

Charles Max Wood [01:07:08]:
Awesome. Alright. I'm gonna jump in with picks now. Y'all know that I do board games as part of my picks. So I'll start out with that. Couple weeks ago, I went to a board game convention with a friend of mine, and, we played a game called apiary. Now if you're familiar with the term apiary, it is about bees. Now these aren't just any bees.

Charles Max Wood [01:07:30]:
These are space bees, which is kind of fun. And, so the space bees are out there trying to, build and explore. And so what you wind up doing is you're you're, building around the space that your spaceship is on, to be able to do more stuff. Now, this has a board game weight of 2.96, So it's a little bit on the complicated end of games. It it was a lot of fun, and there were some things that I really liked about it. One of them is, is it kind of has that worker placement element that you see in a lot of other games where you have the little meeple that you put out, except this one is actually a bee. And, whenever you bring the bee worker back, it actually increases in power. And then once it gets to 4 power, when you bring it back, it hibernates and goes back to 1 power.

Charles Max Wood [01:08:26]:
And so there's a mechanic where you're playing with, putting the bees out and only level 4 bees can do specific, work. And so, you're, you're kind of balancing between building up your ship and the capabilities and bonuses you get from that and, getting the bees back so that you can do other things. You can also bump other bees off of spaces, which, again, sends them back to your hive and, you know, levels them up. And so you're you're trying to weigh out how much advantage you give to other players when you do that. It's a lot of fun. A lot a lot of fun. And you you build out the different spaces with different, types of hex squares, or hex spaces, which also makes sense since it's a b game. So yeah.

Charles Max Wood [01:09:13]:
So I'm gonna pick apiary. It came out last year. It was one of the hottest games. It was one of the hardest games, to get on and play at the at the board game convention. Because they had, was it 6? I think it was 8. They had 8 hot games you could go try out. And so and this was one of them, and and it was one of the harder games to get on. The other one was the White Castle, and I'll probably pick that next week.

Charles Max Wood [01:09:42]:
But, yeah, I really, really enjoyed it. Challengers was another one of those games that I picked last time. So anyway, APA is my board game pick. I also and this is a a pick that I may see if I can get somebody on the podcast to talk about, but, I found that I needed to automate some stuff off of a website. Essentially, just to give a little bit of context, Spreaker offered us a deal if we moved our all of our podcasts over there. But the problem is, is that when when they imported the, RSS feed, what wound up happening was they, they set up their own pages for each of our episodes. And then instead of leaving the link to our website, they linked to theirs. And I told them that that was a no go.

Charles Max Wood [01:10:34]:
Right? I was like, look, it hasn't linked to our website or nothing. And so I still kinda wanna move over because they have a lot better tools for putting the podcast sponsorships in and, you know, they have a lot better number tools. And I can add all of the all of my cohosts on all the shows as collaborators on the podcast so they can go look up the numbers on their own and things like that. So there there are definite payoffs for this, but I need to fix that one thing. And, so I tried using mechanize because I mostly work in Ruby. But the problem is is that their page is client side rendered and mechanize doesn't play nice with those. So it's using React or something. I didn't really look too hard to figure that out.

Charles Max Wood [01:11:17]:
But puppeteer in JavaScript does. And so I've I've been, fiddling with that a bit and, figuring out how to basically, I need it to, download the RSS feed and then, you wish is just an XML file. Right? Have it parse out the, the location and then navigate the website because they don't have an API to stick that, that URL in. And if I get that figured out, then I can migrate the shows over. So unless they find me a solution before then. But anyway, so I'm gonna pick puppeteer. It's pretty cool. Kevin, what are your picks?

Kevin Whinnery  [01:11:55]:
Nice. So, from the, category of Netflix shows, I've been watching House of Ninjas recently, which is about, a family of ninjas, who kind of gave up their shinobi lifestyle, are trying to live as a normal family in Japan, but end up getting kind of sucked back into the world of, you know, ninja intrigue, which, it's a imported show with, subtitles. It is dubbed, but the dub is pretty bad. So I would, recommend going

Dan Shappir [01:12:24]:
with the I never watched the the dub things if I can help it.

Kevin Whinnery  [01:12:29]:
No. Yeah. The the dove is not great. But, the dad jokes from earlier reminded me of a story about a king once who loved grass. He loved the smell of grass, everything about it. So he summoned his royal builder to, his castle and said, I want you to rebuild my castle in grass. And the builder was very skeptical, but she said, okay, I'll rebuild your castle in grass. So she created this massive castle, all made out of grass.

Kevin Whinnery  [01:12:55]:
The king loved it. And, you know, she stored all of the old stuff from the prior prior castle, like, up above the main throne room. But the first day that the king was holding court in his grass, castle, he was actually crushed by his previous throne which fell through the grass ceiling because grass is not very good at bearing weight. And the moral of the story, of course, is that people in grass houses shouldn't stow

Dan Shappir [01:13:24]:
thrones. Okay. So good.

Steve Edwards [01:13:27]:
Thank you. I always love it when the guests bring the jokes. It's so good.

Charles Max Wood [01:13:31]:
Yep. Alright. Yeah. I'm sure

Kevin Whinnery  [01:13:33]:
that people wanna be as great grateful, but Yeah.

Charles Max Wood [01:13:36]:
If people wanna connect with you, where do they find you on the Internet?

Kevin Whinnery  [01:13:40]:
I'm at Kevin Winery on Twitter, or just kwinery on GitHub. Would love it if you would hang out at on the Deno Discord as well. It's, discord.gg/deno. So feel free to join us there. But, yeah, those those are probably the big ones.

Charles Max Wood [01:13:55]:
Awesome. Alright. We'll wrap it up here.

Dan Shappir [01:13:58]:
So we really just need to bring Kevin over again to talk about JSR. That's Yep.

Kevin Whinnery  [01:14:04]:
I think so. Yeah. We'd love to chat about that more.

Charles Max Wood [01:14:07]:
Yep. Please do it. Alright, folks. Till next time, Max out.