Hey, welcome to another episode of JavaScript Jabber. This week on our panel we have Steve Edwards and tell you Jay'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. Dang peer hey from Tel Aviv where it's still well actually fal Saba, which is also in Israel. It's still light outside, which explains why I'm in Farsabah because I'm still at the office.
As you might be able to tell from my background if you're watching 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, I must say that is a very distinctive white wall and whiteboard there with nothing written on it. It stands out. Yeah, somebody cleaned out the whiteboard, which is a good thing because it means that there
are no trade secret right awesome. I'm Charles max Wood from Top End Devs and I just want to say hi to all thirty seven people watching us on x or Twitter, whatever you're calling it. And we have a special guest this week that it's Kevin Winnery Kevin, do you want to say hello and introduce yourself. Yeah, that'd be great. How's it going, folks. I'm Kevin. I'm a part of the Dino 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 cod awesome. All right, 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 Dino. I think we've talked about isn't there
a web framework or something that we talked about. We mentioned Fresh. 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. Yeah, for sure, Fresh. I might have been confused with I know we did an episode on Bun, so that may be. Yeah. It was a great episode, by the way, even though I didn't participate,
despite the fact that there was no effect, despite the fact. Yeah, it was just uh a j And what's what's the name of the guy who's doing BUN forget? I forgot his name. Probably Jared, I would imagine Jared. Yeah it was Jared. Yeah it was Jared. I'm pretty sure it was a great episode. Yeah, Jared, I'm highly recommend it. Yes, they AJ took the opportunity to really dive into the nitty gritty details of what it means to build an engine. That's kind of how he operates.
But it makes the episodes fun, so it works. Let's let's jump in though, and quickly introduce. 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 give them a baseline and we'll move up from
there. Yeah sounds great. So Dino as a JavaScript run time similar to no JS or BUN and it was originally created by Ryan Dahl, who was the author of no JS about ten going on fifteen years ago now, and it sort of came out of wanting to address some problems and some issues that Ryan had with no JS originally and some things that kind of felt could have been done slightly better, so differently in the JavaScript run time, kind of
built in the modern era. So Dino has support for Typescript natively, so instead of just JavaScript code, you can use typescript code without any third party tools or a build step, and for those that are brand new, Typescript is a compile the 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 in JavaScript, where you could have a predictable interface that has great ide support and things like that. Dino also tries very hard to be as browser like a programming environment as possible. One thing about no 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. So no js had common js, which is a older module format that has since been superseded by ecmscript modules. There were, you know, no file system. There is no built in HGP request API like the fetch API that we have in the browser today. So Dono wherever possible tries to implement browser APIs to expose functionality instead of inventing
kind of new APIs whenever possible. And another thing with the NOE ecosystem as it exists today is a lot of the tooling that you need to be productive, like a linter, a format, or a test runner, lots of these different tools that where you know, in a note 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 Dino run time itself, so there's a format or built in, a linter built in. There's
even utility to compile your denote 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 Dino. Another thing that DONA does that is unique to jobscript grun times 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 into 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 variable, say you can execute your code with
the least number of privileges possible within the underlying execution environment. So that run time security by default is also something that's unique to Deno. So, yeah, it's a jobscript run time. It's built on Rust in Tokyo. It's quite fast, especially sort of in comparison to similar like HGP handling operations that exist in Note 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. I have to ask because you just mentioned that, what is Tokyo. I'm familiar with Rust obviously, but I'm not familiar with Tokyo. What is that? Tokyo is a RUSS 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 and rust interesting. Uh, and so listening to your description, I think it might be best summed up as Dino is Node done right. I mean, 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 the context that we have today, Dino is kind of the attempt at doing that. I don't know if i'd call it that indicates that Node was done wrong.
I think it's maybe a better description, say, node is done with what was available at the time, and now there's a lot of other things available and better way to do things, so let's use those. Yeahs is a long time in tech, you know, lots of things to learn. Yeah, 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 by the time you have a better understanding of what it is that you actually want to do 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 vackseats. Yeah. Absolutely like the successive node and NPM just has like enshrined a lot of those patterns that
we kind of take for granted in doing super side jobscript today. Yeah, and common jass is one of those examples, right, Like there wasn't a Web standard module API in you know twenty you know what it was, It would have been like twenty ten twenty when like node was still originally being created, and so common jass 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, created new technology that didn't exist in those days. By the way, I think the no go for it, I was going to say, I think the no vaccines is really the
best way of putting it where. Yeah, it's not that node couldn't innovate in the ways that Dino 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 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 Angler did way back in the day, right, moving from one to two, except they just kept the name and confused a bunch of
people and it cost some issues for them. But yeah, it's 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. I think another great example of that is the use of promises and the sync of weight. If you look at the nod APIs, you know most of them were created, at least the fundamental ones were created before promises were a thing, and certainly
before the JavaScript language had built in a sinker weight. So it uses different patterns, uses patterns like calledbacks and stuff like that. And with Dino, I believe much of the APIs, especially because it is trying to use modern web APIs whenever possible, a lot of these APIs are promise based fetch yeah, yeah, I mean, and since like note of course, like 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 available? The UH and ECMAScript language features that do appear in node and they and they will filter their way into UH, you know, into note over time too, will usually show up in DINO first, like for for example, like top level async a weight is something that you can do in DINO, which I think is behind a flag and Node. I'd have
to actually double check. I'm not sure if it's available with a flag or in some other context. But yeah, so like these for of bleeding edge Ecmoscript language features will tend to make their way into Deno a little a little faster as well. Now, one of the things that NOE or Dino sorry created when it came about, By the way, just if everybody, if our listeners aren't didn't notice, aren't aware, Dino is literally spelled backwards, right, that's the point of the name. Yes, that that is kind
of where it came from. It's actually like if you were to sort the characters in note on that is how you get do you oh cool? So one of the things that you also introduced in Dino, as I recall, is like a quote unquote standard library, a collection of JavaScript or typescript utility functions 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 Dino into the JavaScript community at large. I would have loved to see a lot of this functionality just generally available everywhere. Yeah. So the Yeah, the Deno Standard Library, at least until recently, was largely mostly usable in Dino. There are ways to use it outside of the context of Dino. With the event of JSR, which is a registry, I don't know if we'll get into it, you know, in this sort of conversation.
Uh, the standard library has been published on JSR now as well, and since JSR modules can be used in any runtime environment, the Deno 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 lot of that stuff kind of has been freed from a Dino
specific packaging. That's excellent. I really hope that something like that library can become more than a quote unquote standard library and actual standard library for JavaScript slash, acmascript, slash s typescript, that would be awesome. It just provides a lot of useful functionality that a lot of people end up recreating themselves on
as a one off basis. Yeah, yeah, for sure. Hopefully that will start to make its way out a little bit as the you know, as people start you know, adopting adopting JSR for other purposes to you. Now, you mentioned that one of the reasons that Dino 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 had the ability to do a fresh start. 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 codebase.
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 applications and whatnot, and in many ways they kind of depend on all this like not necessarily specified behavior that's built into node, not necessarily documented, you know, like they depend on the bugs. So the question is you kind of I find uside correctly, you kind of need to compete with that.
I mean, sure, if I'm starting a new project from scratch, then maybe I pick Dino, But then maybe I'm risking the fact that the package that I really want to use is not available for Dino. So how do I contend with that? Yeah, it's it's definitely been like the major
challenge at the core of like how Dino has evolved. I would say like over the last five years is like the gravitational pull of the NPM ecosystem is pretty strong, and there's just a lot of tooling and libraries that exists that exist there that are kind of non optional in server side JavaScript development today.
So a lot of work on the Dino team these days goes into our node compatibility layer, where, yes, with Dino's design, we do want to maintain an environment where we do use ECMAScript modules only, and we don't you know, support common ass uh you know as a like outside of this compatibility layer, and we do want to favor you know, Web Standard APIs whenever possible. But the fact that 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, uh, the node compatibility layer in Youno 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 Dino, it is slightly different because the way in which you'd depend on a package, you know, could be a little different in Dino than it was in Node.
But we've also like implemented a lot of compatibility features. Like you know, by default in Dino, when you import a JavaScript file, you have to include the extension of that file. And that's for a couple of reasons. Number, 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, if you leave off the file extension, then the run time 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, and there's a lot of sort
of overhead that comes along with that. Dino provides a mode that is cheekily probably named sloppy imports, which is like an option that you can pass into the run time 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 noe js and run it
in Dino without really having to change much of anything. And the big push for us for Dono two point zero for this year is like getting to the point where we feel like the most vast majority of the most important Node packages just work in Dino, and I don't know if we'll ever Like our goal isn't explicit to get to like being a drop in replacement for node necessarily, but we want next js to work on Dino, Like we want, you know, all the web frameworks that you would want to use from the noe
ecosystem to work really well on Dino as well. So that's probably our biggest like engineering objective like over the next several months is just continuing to improve like 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. The note ecosystem is just kind of 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 want to provide through. You know that 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, then all of a sudden your favorite game stopped working, you would blame Microsoft, not the game, not the game creator. Yeah. I was gonna say, I had to run tie Fighter in Windows ninety five compatibility mode for a long time until you know, I found
like a more modern or that I could use otherwise. So, but I do have to ask, I mean, if you're putting in all this effort, and it's 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 of using Dino over Node, especially if I do assume that I want to be using you know, all this functionality that exists and not write everything from scratch. 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 Testerlinter format or all of those 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 Dino. So like if an express server that you wrote a Node is just going to be probably a little bit faster in Dino than it is in Uh than it is running on Node. And kind of 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. But uh a uh, I just actually saw a post like over the weekend about you know, there's a hdpre framework called oak, which is like a middleware framework sort of inspired by Coha, and the author tested it across you know, BUN and Node and Dino, uh to kind of see what the performance characteristics were and know and Dino and Bun were you know, about the same Bun was actually ran
ran HDP requests slightly fast. There is like a maybe ten percent 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 DNA as well, 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. Yeah, I mean there's there's certainly challenges with that, But I mean, the the shim APIs that we've created for like the underlying HDDP node core APIs utilize the same sort of opter earthly they get to benefit from the same optimizations we've made in Dino to make HDP requests handling fast. So those
shim api do tend to perform uh pretty well. So like we uh 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 uh you know pages in that framework. Uh, those Node APIs actually run slightly faster on Dino 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 performant, not necessarily because do you know, for you know, is intrinsically always faster than uh Node. It's just that, you know, and it's not like, you know, Node couldn't be this fast potentially see as certainly uh, you know, just as fast as Rust or c C plus plus or whatever. But yeah, it's just the uh, A lot of work has gone into optimizing
the HDP interfaces. 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 note 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 you wanted to ask something about the built in Typescript support that you mentioned before. So I actually posted a link in our chat to a great quote from Matteo Colina, who is really deep in the node world, by the way, is one of the maintainers I think of note and he wrote some tweet recently which was really am using Anie opening to an extent, which is typescript does not exist. There is 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 the different values that you put in your ts config file can significantly impact the functionality the behavior of typescript, or put another way, kind of 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 DNO deal with that? I mean, is it using the same ts config as typescript as TSC or something else. How does that work? I mean, there's a sort of a 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 Dino is that you know, there is a set of behavior that's sort
of codified and how Typescript runs on Dino. 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 Dino, but the Typescript environment is relatively predictable versus in in node, where you do have like kind of full configurability of how the uh TSK or like how TSC works at the end of the day.
So yeah, but like the point stands that, you know, if you have access to all those compiler options, it makes it very difficult to write touch script code that you know can very can predictably run with every set of compiler options. So am I stuck then with how you did it then?
To a degree? Right, Like, so there are certain things that are configurable, there are certain things that are not so there's probably features of like ts config that would work in a node environment that are impossible in Dino just because we don't support those those options. So it is a constraint that exists
for sure. By the way, not supporting some ts configure options is actually a good thing, because I've literally seen projects that were configured in such a way that interface definitions weren't each actually even being used, and the developers didn't
even notice. So like there were incorrect types and literally types with errors in them, and the projects seemed to compile fine because everything that was using like an unrecognized the imports didn't actually work, and anything that used an interface that wasn't specified defaulted to any instead. So they basically had everything as any, but they thought they were writing typescript but actually had everything as any, which
is like the worst of all possible worlds. Yeah, so all the overhead of using TSC with none of the actual compile time safety, Yeah, that seems exactly exactly. So 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 environment. I mean, let's
put it differently. With Typescript, I see two main benefits. One is, while I'm writing the code in the development environment in let's say VS code, it does all the type checking for me, squiggly lines, the completion stuff like that, and and and highlights files that has have errors in them
and so forth. The other advantage is is the actually 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 configure settings, then the built step will actually fail if I try to build something bad, so because I'm ignoring squiggly lines and VS code for some reason. So my question is, you know, with with dno, you don't need that built step or you don't have that built 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? Actually? So there is still a build step that happens. Like so there's a UST based sort of equivalent of TSC which we would use sort of at run time to generate the jobscript code because like
Dino runs JavaScript code in VA similar to how Node does. So we still do need to transpile typescript before it's able to run in that environment, because VA doesn't natively understand typescript, So there is a sort of build build step that happens as a result of running your code on you know, 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 controlled typescript, and you can you know, in the case of uh, you know JSR, you can publish typescript directly to the registry. Other typescript developers don't have to rely on your transpile 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 transporlation as a part of that ends up being ends up being kind of nice in a lot of a lot of different contexts. So it's basically reducing friction in the development process. Yeah, yeah, kind of friction, kind of the overhead of that transportation process. Like you do, you kind of don't have to consider it within your
workflow. So side note, really quick, Am I the only one that thinks of vegetable juice when I hear V eight? There was a time I think I've gotten yeah? Or yeah, I think you know I should have had a V eight commercials for those who are too young to remember that anyway, Yeah, but it's time. Sift is not the only thing that you built. 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? Yeah? Sure, so yeah, so Dino has like a test command that's built in. If you run like Dino help after you install Youno, you can get a sense of like what all these command line tools are. But yeah, it was really about, like there's a lot
of decisions that you make when you're bootstrapping a node project. They 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 or 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. But also I just think that, you know, accepting a set of defaults tends to be
kind of nice. One thing that I've really noticed is as I've gone between different Dino 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 one 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 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 Rubion 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. Like rails projects can be very you know, diverse in a lot of other ways, but like some of that similarity is helpful in terms of like the other tools that are built in. I mentioned Dino compile, which you know, you can point at a type script source code file and it generates a binary that can be run cross platform. So like 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 Dino to create Tea, which is kind
of his sort of next generation version of that package manager. And he used Dino for this reason actually because he wanted to write typescript, wasn't necessarily interested in you know, having that transportation step, and the ability of Dino to package up a cross platform executable was convenient there as well. So Dino compiles
super useful. Certainly a few other nicely. So there's a Dino doc which is also a built in utility and you can point it at a typescript file or a dot D dot t S file and you'll kind of introspect those files and generate HTML documentation for your you know, for your type script 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. By the way, does your typescript implementation also support jastock I yes, it does, so, yeah, that's that's kind of where it's pulling a lot of that. It'll pull documentation content from jas dot comments if they if they exist, and a lot and it can guess a lot just from type information as well.
AJ will be happy. So I'm old enough to remember 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 will implement it as separate executables or and ran as distinct userland 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 Dino with the one command line switch does one thing, with a different command line switch does some other thing. What's the motivation? What's the advantage of bundling all this functionality, you know, some of which could
definitely be like distinct and standalone. 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. I think like it's kind of you know, you're deciding where and when to manage complexity within your project. Like if you are using uh, you know, some kind of utility
and 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 uh, you know, the Unix philosophy is definitely one of the reasons that that like operating system has been so popular and continues to be, uh like one of the best options for especially like technical you know, sort of technical use cases or like
running code on servers that sort of thing. But the uh, the price that you pay in like application programming tool like uh, you know, something that's a little higher level, like a DNO 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 dot Jason that has twelve dependencies in it, none of which are actually have anything to do with the functionality or a 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's a
price that comes with that as well. There's certainly flexibility. But when you consider the trade offs of like, Okay, now I have you know, this this dependency on jest and it depends on this other thing. And now when I run you know, in PAM 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, et cetera. 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 non trivial, including them as part of the platform tends to be a trade off that that helps.
So if I'm using Dino, then I likely won't install prettier and es lint and ts s lint and stuff like that, or just use whatever is built in. Yep, that is the intent that you wouldn't necessarily have to bring those tools in unless you're using Dino in the context of an existing Node project, in which case you might still you know, have those tools around. But yeah, and a Dino project, the expectation is you won't need to have those things. Cool. I'm kind of curious. I'm going to
change gears on a little bit. How did you get into Dino, right? What's your story here? Yes, so, I've been you know, a no Jazz user since like I think the first code I wrote was for zero point eight of Node, and at that time I was working at a company called Twilio, which is like an API provider like messaging, telephany stuff like that, and Node was pretty new and I was like, oh, Twillia, we should have totally have like a client library for this node thing.
I think, I think this, I think it has legs. I think it's going to go somewhere. So I wrote like an HGP 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 a program every kind of thing, like from servers to front end robots, everything in between. So using JavaScript is kind of the lingua franc 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 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 having even having like written any code like there. There was certainly a certain amount of discontent with how much complexity it kind
of crept into the ecosystem. So the prospect of having this this set of decisions that are kind of trivial made for me was was pretty compelling, and so so like the lure of Dino 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 Dino it 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 Dno again, because like if I have to configure you know, TS configure web pack for these purposes again, I'll probably be a little a little sad. Or what a minute, you mentioned web pack. Uh, maybe you mentioned it before and I kind of missed it. But does that mean that Dino also has a built in bundler? So there was there is a was a built in bundler that was
deprecated in uh, you know, a previous version of Dino. It's something that we're kind of looking at again, but like, yes, build works pretty well in the Dino ecosystem, like for that purpose, So it hasn't been like super high priority. But the webpack as like a way of running like built 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 notes, So like compiling like s CSS say, like as a part of you know, those
projects. So a lot of those tools I find I need to use less in uh in Dino, which show kind of oh go for a truck. Sorry, I was gonna pushed us back to the story just a little bit. Yeah, So it wasn't any one particular project. It was just kind of your workflow that pushed you toward Dino. 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 Dino. How did that come
about? Was it just your involvement in the project or was there something else? Did you know someone I've been sort of around the project for some amount of time, but they decided they wanted to like have a formal Devreux program and I actually wasn't aware of it, but somebody from the team reached out to me and it was like, Hey, we're looking at doing a devre program. Is this something you'd be interested in? I was like, uh, yeah, yeah, I totally would be interested because I had been pretty
stoked about the technology for a while. So it kind of came through some outreach from the company at the time. Okay, cool, if I'm pulling us back a little bit towards the technology side. Uh, 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 won't you might not be using node or on its own, you might be using it with the next
GS or an ASTRO or you know whatever. And so my question is, how does Dino 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 GS, how you know what? How does you
know fit into that installation process? So there's kind of a spectrum of how well do you know works with a lot of the meta frameworks in the NOE ecosystem, but even just within if you're just talking about like first party like Dino frameworks, you will probably be using some kind of meta framework along with Dino. Fresh is kind of the first party one that the Dino team maintains, which is sort of designed to run on edge servers and implements like an
island architecture similar similar to ASTRO. And there's a lot of other frameworks I'm doing it in that in that way, but the assumption is that you know, zero 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 just before you move on to the to another one. Y correct me if I'm wrong. I think that Fresh
is kind of built on on pre Act, right it is. Yeah, So actually one of the maintainers of pre Act, Marvin Hagemeister, is a member of the Dono team now and as kind of primary maintainer of Fresh as well. So yeah, great, definitely core technology there. Yeah, and then if for other I mean, there's certainly other meta frameworks that you can use in Dino. The other like notable one i'd point out is Hono,
which is maintained by the cloud Flare team. Actually is sort of like the spiritual successor I would say to like Express and Sinatra from the Ruby world, 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 two of the best options that exist just that work natively in Dino, but from the no ecosystem that that's like one of the big challenges that we're trying to address with Dino two is getting more of those meta frameworks to work really
well in in Dino. Some of the work pretty well today. So like if you worked a lot of the frameworks that use VET as a build to in under the covers, so like Astro would be one of them, speltcarts, yeah, noxt would be would be another. Those frameworks tend to work pretty well in Dino because VET works quite well for the most part in in Dino. 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 which allow you know, server side rendering in different environments like in cloud, fliter workers or a node or whatever it would happen to be. And there is a Dino Astro adapter which is a little bit out of repair,
and that's largely largely my fault. I haven't had a chance to update the adapter, but the Node adapter for Astro works works great, and you can use that today. There's a spel Kit adapter for Node that works great in Dino today. There's also like a community maintained spell Kit adapter that is natively Dino that works really well. Next is in a kind of a similar position. So a lot of those those types of frameworks do work really well.
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 one to one in such a way where like next is a good experience specifically, but that is an obsession that currently exists on the Dino team is to figure out how to make a next run really well as well. So certainly a goal. Yeah, that's kind of important. I mean, not putting
down any of the other frameworks, but just numbers wise. Next, yes is more or less like as big as all the other meta frameworks come buying, So so yeah, definitely not lost on the crew here at Dino for sure is the necessity to have an 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 two point zero launch on is like how well we're we feel that we support those crucial metaphrameworks from note say, it's the next big thing, right Dan well played, Steve well played. Yeah, and especially given that that works next anyway. Yeah, and especially given that I work at the company called Next Insurance that has nothing to
do except that you actually except that we actually do use it. Uh, you know. But anyway, the time for the next question yet, I mean, I think we're starting we're starting 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. Yeah. One thing that I want to to kind of ask you about before 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 does that how do you differ with in node in that regard? Do you differ from node? What are the advantages of running Dino in that scenario. What of the advantages of the edge in general, So go for it. Yeah, sure, I can try
to yeah, unpack that a little bit. So the one thing that is useful about how DINO works is a lot of the core functionality and Dino 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 vight 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 JavaScript 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 UH solution, a jabscript environment can UH and can manage a pool of vight isolates similar to like a browser tab in your in your browser,
which are very sort of cheap and easy to create and UH and tear down. So the cold start times for those isolates can be really uh, really nice in a lot of scenarios. And the fact that you know can run really well in a lightweight, UH JavaScript environment like that one is one of the advantages that sort of makes it work well in that scenario. So Denote is being used in uh sort of edge edge functions in a few different contexts.
So like if you use Netlify edge functions that actually runs on Dino and Dino's cloud infrastructure sort of behind the scenes. UH. For a long time, super Bases edge functions also ran on our cloud infrastructure. They've since like taken Dino and created their own edge infrastructure based on Dino that they're building on as well, which is awesome they've done. They've been doing some really cool
work there with the open source run time. So yeah, so there's I think it's the relationship between like Dino 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 I think like the the advantage generally of doing you know,
processing on the server on the edge is uh is latency. So if you can do compute tasks and 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 UH that is maybe optimally done on the edge, like whether it's like manipulating headers for an HDP 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 UH 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. Yeah, you can do that maybe all closer to
where your users are. 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 your solution or implementation. 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 uh, you know, one of the architectural concerns that you have to pick through. Now, one more question that I have is this. So it's it's Dido dot com,
which means that you're an actual company. You're not just an open source project, right, So what's how do you plan to be like, you know, to make money to be to make sure that the project survives because and the company doesn't go under, Like what's what's the what's the value proposition in terms of you know, generating generating funds. Yeah, so it's, uh, the place where we found success so far is around like that edge
computing infrastructure. So the one of the paid offerings that do you know 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 Tulio, and Tulio has this thing called Tulio 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 tech 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 Dino has a platform for very quickly building that out kind of based on this edge computing infrastructure that we created for Dino 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 that I think, like the cloud infrastructure is where a lot of the like
revenue growth is going to be in the future. But like the open source run time 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. And we think like those two things being successful as open source projects will be a headwind for some of like the cloud based stuff that we think will support the
company. So just to make understand. Yeah, just to make sure that I understand in a sense, you're kind of competing with cloud further, cloud Flare workers, like providing an alternative to their solution. Yeah, the so the edge hosting infrastructure is kind of in the similar 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 cloud Flare has a like an enterprise
offering in that realm. I don't know if it's self serviced yet, but 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 Dino and cloud Flare are kind of the two ways you can do edge compute these days, like workers and deploy are kind of the only game in time in town, so like versal edge functions,
say, like us as workers under the hood today. So yeah, so it is kind of similar to that that solution cool, yeah, yeah, very cool. Yep. If you could tell us here within like two minutes, because I do have a hard stop at ten thirty mountain time, two seconds or two minutes what's coming next in Dino. Yeah, So, as I kind of have alluded to, like, no compatibility is a huge
focus for the team right now. So increasing the amount of the note ecosystem that runs with no configuration within Dino is kind of the biggest engineering goal in front of us for the Dino run time itself. The other other bits that are coming out are you know, continued you know, improvement of integration with JSR and tooling around my publishing to the JSR registry and making JSR like work really well across every run time from you know BUN to d NO to NOD
to cloud flare, workers and browsers and everything in between. So I think no compatibility and JSR are going to be the continued uh you know focus for us. Awesome, all right, well, let's go ahead and do our picks and then we'll wrap up. Uh Steve, what are your picks? Oh, We're going to start with the high point first, Okay, Uh, so real quick before I get to the real high point, uh,
blog posts. Interesting when I saw on acher 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 company that surveyed the Lundu Journal l U N d U k E and surveyed seventy two hundred IT professionals and computer nerds, and they asked all kinds of questions about what they use,
and then tried to associate tabs users versus spaces users with other things such as which text editors do they use, what os is do they use, what web browsers do they use? And is there an in correlation with age and politics and so on and so forth. It's really sort of entertaining. So I found it quite interesting. I just put a link in our chat about the white Space programming language. Are you familiar with it? Well, I know what like. White Space is an actual programming language that just uses
white space characters for programming. So it uses all the instructions are coded as space is, you know, spaces, tabs, new lines, 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 two programs in the same source file and you know it might be interesting if Dino had built
in support for the white space programming language. They'll get right on that, right, Yeah, yeah, exactly, we'll file that away as a high priority issue for sure. Yeah, I'm going to guess that with if you're writing with white spaces, you always have to use the dart background, right for sure? Right, okay, And now for the dad jokes of the week. So you know, in the 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 I was, I was interviewing and we were talking about money, and he said, well, what does a competitive salary even mean? I said, well, it just means that your salaries can be against your bills. Ye mm, now this day, these days, it's not it's it's not as amusing. Let's put it as it was, right, the bills are winning. Do you know that alligators can live up to live to be up to seventy years old. That's
why there's a very an increased chance that they will see you later. All Right, I like that one. That was a good one. Actually you later, alligator? Yeah, And then uh, 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? M hm m hm m hm. Uh is the s or the C silent in scent? Mm hmm? And then finally the same and similar? Are they the same or are they
similar? It's it's like that old saying that in theory, theory and practice are the same thing, but in practice they aren't, right exactly, those are my picks of the week. All right, you want to put that link in to that article in the comments, and that way we can I will find that. Yes, all right, Dan, what are your picks? Not a lot of picks? This time? We've started watching a new TV series on Netflix. It's a really new one. It's called The Gentleman.
It's an action comedy television series created by Guy Ritchie. And you know, with Guy Ritchie, it's it can be hit or missed, but when it's a hit, it's a hit. So he created this kind of spin off from his ninth from his twenty nineteen film that had the same name, So it's kind of the same sort of settings and characters, and so far we're enjoying it quite a lot too. We really only watch on the one, the first episode, but so far, so good. Uh. It's
like this uh, this guy that turns out that he's a duke. He inherited 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 that 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's and you know, if you've seen Guy Guy Richie's movies, you know, you know kind of the setting and how the characters, the sort of characters that you encounter there, and you know, so it's so far, so good. We are really enjoying it so far. And I guess, oh, one more thing is we are I'm kind of clearing up my my own like personal library yet at home, like actual books.
Like we've gone to the point that we had like three 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 want to keep in which one you know you'll give away to a library or whatever.
And I'm thinking of maybe, like I think, like a few years back, I did one of some of my picks, who are about these old science fiction and fantasy books that people 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. So if people, if if you guys or listeners are interested in some excellent, you know, sci fi books or fantasy books that you probably haven't heard of before, then let
me know and I'll do that. And those are my picks for today. Awesome, all right, 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. A couple of weeks ago, I went to a board game convention with a friend of mine and we played a game called Apery. Now, if you're familiar with the term apiary, it is about bees.
Now, these aren't just any bees. 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 building around the space that your spaceship is on to be able to do more stuff. Now, this has a board game weight of two point ninety six, so it's a little bit on the complicated end of games. 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 people 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 four power, when you bring it back, it hibernates and goes back
to one power. And so there's a mechanic where you're playing with putting the bees out, and only level four bees can do specific work, and so 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 of 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 it's a B game. So yeah, so I'm gonna pick Apary. 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 uh
was it six I think it was eight. They had eight hot games you could go try out and so and this was one of them, and it was one of the harder games to get on. Uh. The other one was The White Castle, and I'll probably pick that next week. But yeah, I really really enjoyed it. Challengers was another one of those games that I picked last time. So anyway, APR is my board game pick. I also and this is a pick that I may see if I can get
somebody on the podcasts 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. Speaker 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, right. I was like, look, it has to link to our website or nothing. And so I still kind of want to 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 co hosts 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 are definite payoffs for this. But I need
to fix that one thing. And so I tried using Mechanized because I mostly work in Ruby. But the problem is is that their page is client side rendered and Mechanized doesn't plain ice with those, so it's using react or something.
I didn't really look too hard to figure that out, but Puppeteer in JavaScript does, and so I've been fiddling with that a bit and figuring out how to Basically, I need it to download the RSS feed and then which is just an XML file right, have it parse out the location and then navigate the website because they don't have an API to stick 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 Puppeteers. Pretty cool, Kevin, what are your picks? Nice? So from the category of Netflix shows, I've been watching A House of Ninja's recently, which is about a family of ninjas who kind of gave up their shnobi 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 an important show with subtitles. It is dubbed, but the dove is pretty bad, so I would recommend going. I
never watched the dubbed things. If I can help it. No, Yeah, 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.
The king loved it, and you know, she stored all of the old stuff from the 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 grasshouses shouldn't stow thrones. Oh OK, so good, thank you. I always love it when the guests
bring the jokes. So good. Yeah, all right, I'm sure people want to great, great, grateful, But yeah, people want to connect with you. Where do they find you on the Internet. I'm at Kevin winnery on Twitter or just k winnery on GitHub. Would love it if you would hang out on the Dino discord as well. It's discord dot gg slash Dino, so feel free to join us there. But yeah, those are probably the big ones. Awesome, all right, we're up here, so
we really just need to bring Kevin over again to talk about JSR. That's uh I think so. Yeah, I would love to chat about that more. Yeah, please do it, all right, folks, still, next time, max out m hm