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