Simplifying Development with Deno - JSJ 625

WEBVTT
1
00:00:06.320 --> 00:00:10.759
Hey, welcome to another episode of
JavaScript Jabber. This week on our panel
2
00:00:10.800 --> 00:00:15.119
we have Steve Edwards and tell you
Jay's not here. I'll do him.
3
00:00:15.400 --> 00:00:20.879
Yo yo yo from very cold and
rainy Portland, which is not out of
4
00:00:20.879 --> 00:00:26.359
the ordinary for this time of year. Dang peer hey from Tel Aviv where
5
00:00:26.399 --> 00:00:30.280
it's still well actually fal Saba,
which is also in Israel. It's still
6
00:00:30.359 --> 00:00:34.320
light outside, which explains why I'm
in Farsabah because I'm still at the office.
7
00:00:34.359 --> 00:00:37.079
As you might be able to tell
from my background if you're watching the
8
00:00:37.920 --> 00:00:42.560
stream or the recorded video, it's
you know, it's daylight savings in the
9
00:00:42.679 --> 00:00:45.600
US and not yet in Israel,
which makes it even earlier for me.
10
00:00:46.320 --> 00:00:50.479
So so yeah, I must say
that is a very distinctive white wall and
11
00:00:50.920 --> 00:00:55.880
whiteboard there with nothing written on it. It stands out. Yeah, somebody
12
00:00:55.920 --> 00:00:58.880
cleaned out the whiteboard, which is
a good thing because it means that there
13
00:00:58.880 --> 00:01:06.680
are no trade secret right awesome.
I'm Charles max Wood from Top End Devs
14
00:01:06.719 --> 00:01:08.840
and I just want to say hi
to all thirty seven people watching us on
15
00:01:10.200 --> 00:01:14.000
x or Twitter, whatever you're calling
it. And we have a special guest
16
00:01:14.000 --> 00:01:15.560
this week that it's Kevin Winnery Kevin, do you want to say hello and
17
00:01:15.599 --> 00:01:19.599
introduce yourself. Yeah, that'd be
great. How's it going, folks.
18
00:01:19.680 --> 00:01:23.439
I'm Kevin. I'm a part of
the Dino team, and I'm coming to
19
00:01:23.519 --> 00:01:26.760
you from Minneapolis, which is not
cold actually as it usually is. It's
20
00:01:26.799 --> 00:01:30.680
actually unseasonably warm for March in Minneapolis, but we'll take it. We can
21
00:01:30.680 --> 00:01:37.280
get a little bit more time outside
without a cod awesome. All right,
22
00:01:37.319 --> 00:01:41.079
Well, we brought you on to
talk a bit about Dino, and I
23
00:01:41.159 --> 00:01:44.599
have to say I was a little
surprised to find that we haven't had an
24
00:01:44.640 --> 00:01:49.319
episode where we talked specifically about Dino. I think we've talked about isn't there
25
00:01:49.319 --> 00:01:55.000
a web framework or something that we
talked about. We mentioned Fresh. I
26
00:01:55.079 --> 00:01:59.359
think we mentioned Fresh, and we
said that we wanted to bring somebody to
27
00:01:59.400 --> 00:02:02.400
talk about Fresh. But I don't
think we actually had an episode about Fresh
28
00:02:02.439 --> 00:02:07.519
either, So maybe we'll take that
this opportunity to also talk about Fresh.
29
00:02:07.959 --> 00:02:12.360
Yeah, for sure, Fresh.
I might have been confused with I know
30
00:02:12.400 --> 00:02:15.439
we did an episode on Bun,
so that may be. Yeah. It
31
00:02:15.479 --> 00:02:19.680
was a great episode, by the
way, even though I didn't participate,
32
00:02:22.000 --> 00:02:24.800
despite the fact that there was no
effect, despite the fact. Yeah,
33
00:02:24.840 --> 00:02:30.520
it was just uh a j And
what's what's the name of the guy who's
34
00:02:30.599 --> 00:02:36.000
doing BUN forget? I forgot his
name. Probably Jared, I would imagine
35
00:02:36.080 --> 00:02:38.919
Jared. Yeah it was Jared.
Yeah it was Jared. I'm pretty sure
36
00:02:38.039 --> 00:02:42.120
it was a great episode. Yeah, Jared, I'm highly recommend it.
37
00:02:42.199 --> 00:02:49.400
Yes, they AJ took the opportunity
to really dive into the nitty gritty details
38
00:02:49.479 --> 00:02:53.680
of what it means to build an
engine. That's kind of how he operates.
39
00:02:53.719 --> 00:02:58.199
But it makes the episodes fun,
so it works. Let's let's jump
40
00:02:58.199 --> 00:03:02.000
in though, and quickly introduce.
I know that probably most of our listeners
41
00:03:02.240 --> 00:03:07.000
have some idea what it is,
but we always have new people. And
42
00:03:07.039 --> 00:03:09.800
by new people, I mean like
new to programming or new to JavaScript who
43
00:03:09.840 --> 00:03:14.439
may not know. So let's give
them a baseline and we'll move up from
44
00:03:14.479 --> 00:03:19.919
there. Yeah sounds great. So
Dino as a JavaScript run time similar to
45
00:03:20.520 --> 00:03:27.240
no JS or BUN and it was
originally created by Ryan Dahl, who was
46
00:03:27.280 --> 00:03:32.759
the author of no JS about ten
going on fifteen years ago now, and
47
00:03:34.199 --> 00:03:38.280
it sort of came out of wanting
to address some problems and some issues that
48
00:03:38.840 --> 00:03:44.719
Ryan had with no JS originally and
some things that kind of felt could have
49
00:03:44.759 --> 00:03:47.879
been done slightly better, so differently
in the JavaScript run time, kind of
50
00:03:47.919 --> 00:03:55.759
built in the modern era. So
Dino has support for Typescript natively, so
51
00:03:55.800 --> 00:04:01.199
instead of just JavaScript code, you
can use typescript code without any third party
52
00:04:01.199 --> 00:04:05.400
tools or a build step, and
for those that are brand new, Typescript
53
00:04:05.479 --> 00:04:10.520
is a compile the JavaScript language which
is strongly typed, kind of similar to
54
00:04:10.599 --> 00:04:14.360
a Java or a c sharp,
and it can help by kind of surfacing
55
00:04:14.400 --> 00:04:18.879
compile time errors and provide type checking
and kind of makes the editing experience a
56
00:04:18.879 --> 00:04:24.720
little bit more on rails in JavaScript, where you could have a predictable interface
57
00:04:25.079 --> 00:04:30.120
that has great ide support and things
like that. Dino also tries very hard
58
00:04:30.160 --> 00:04:35.120
to be as browser like a programming
environment as possible. One thing about no
59
00:04:35.240 --> 00:04:40.560
JS that, as it was originally
created, a lot of the Web standard
60
00:04:40.680 --> 00:04:45.160
APIs that we enjoy in the browser
today didn't exist, so there wasn't really
61
00:04:45.199 --> 00:04:49.759
a module system for creating reusable code. So no js had common js,
62
00:04:49.800 --> 00:04:57.920
which is a older module format that
has since been superseded by ecmscript modules.
63
00:04:58.480 --> 00:05:00.279
There were, you know, no
file system. There is no built in
64
00:05:00.519 --> 00:05:04.519
HGP request API like the fetch API
that we have in the browser today.
65
00:05:04.839 --> 00:05:12.560
So Dono wherever possible tries to implement
browser APIs to expose functionality instead of inventing
66
00:05:12.639 --> 00:05:18.240
kind of new APIs whenever possible.
And another thing with the NOE ecosystem as
67
00:05:18.240 --> 00:05:21.759
it exists today is a lot of
the tooling that you need to be productive,
68
00:05:23.480 --> 00:05:28.160
like a linter, a format,
or a test runner, lots of
69
00:05:28.199 --> 00:05:31.439
these different tools that where you know, in a note project you're usually installing
70
00:05:31.720 --> 00:05:35.839
you know, a dozen or more
dependencies before you even get started, a
71
00:05:35.920 --> 00:05:41.040
lot of those things have kind of
been rolled into the Dino run time itself,
72
00:05:41.120 --> 00:05:44.319
so there's a format or built in, a linter built in. There's
73
00:05:44.360 --> 00:05:50.360
even utility to compile your denote program
into a cross platform executable. So a
74
00:05:50.360 --> 00:05:54.680
lot of the sort of key developer
tools that you'll you'll tend to need in
75
00:05:54.720 --> 00:05:59.879
every project are included out of the
box in Dino. Another thing that DONA
76
00:06:00.480 --> 00:06:04.839
does that is unique to jobscript grun
times is providing kind of granular controls over
77
00:06:04.959 --> 00:06:10.560
the execution environment of your code.
So by default, your code doesn't actually
78
00:06:10.560 --> 00:06:15.199
have access to the file system,
or the system environment or the network you
79
00:06:15.279 --> 00:06:18.639
as the developer kind of have to
opt into letting your code have access to
80
00:06:18.680 --> 00:06:23.759
those things. So say you're running
in a secure CI environment and you don't
81
00:06:23.800 --> 00:06:27.439
want you know, your code and
any you know, dependencies that you're bringing
82
00:06:27.480 --> 00:06:32.120
in to have access to environment variable, say you can execute your code with
83
00:06:32.319 --> 00:06:40.759
the least number of privileges possible within
the underlying execution environment. So that run
84
00:06:40.839 --> 00:06:45.600
time security by default is also something
that's unique to Deno. So, yeah,
85
00:06:45.600 --> 00:06:47.480
it's a jobscript run time. It's
built on Rust in Tokyo. It's
86
00:06:47.560 --> 00:06:54.959
quite fast, especially sort of in
comparison to similar like HGP handling operations that
87
00:06:55.639 --> 00:07:00.600
exist in Note And yeah, we
hope provides just a really nice developer experience
88
00:07:00.720 --> 00:07:03.199
that's a little more you know,
batteries included than something that you might have
89
00:07:03.319 --> 00:07:09.000
in Node today. I have to
ask because you just mentioned that, what
90
00:07:09.160 --> 00:07:13.360
is Tokyo. I'm familiar with Rust
obviously, but I'm not familiar with Tokyo.
91
00:07:13.399 --> 00:07:18.639
What is that? Tokyo is a
RUSS library for doing asynchronous IO operations.
92
00:07:19.120 --> 00:07:25.000
So in Node they have libuv which
kind of provides a similar set of
93
00:07:25.040 --> 00:07:29.920
functionality, and Tokyo is is the
library to do to provide a similar set
94
00:07:29.959 --> 00:07:35.560
of functionality and rust interesting. Uh, and so listening to your description,
95
00:07:35.879 --> 00:07:42.000
I think it might be best summed
up as Dino is Node done right.
96
00:07:44.160 --> 00:07:47.399
I mean, certainly it's was kind
of envisioned in that way of like,
97
00:07:48.000 --> 00:07:53.720
you know, if if we were
to recreate node and kind of with the
98
00:07:53.759 --> 00:07:57.319
context that we have today, Dino
is kind of the attempt at doing that.
99
00:07:57.720 --> 00:08:00.319
I don't know if i'd call it
that indicates that Node was done wrong.
100
00:08:00.399 --> 00:08:03.959
I think it's maybe a better description, say, node is done with
101
00:08:05.120 --> 00:08:07.480
what was available at the time,
and now there's a lot of other things
102
00:08:07.519 --> 00:08:11.040
available and better way to do things, so let's use those. Yeahs is
103
00:08:11.040 --> 00:08:13.439
a long time in tech, you
know, lots of things to learn.
104
00:08:13.560 --> 00:08:18.439
Yeah, And it's not just that, I mean Node kind of paved the
105
00:08:18.480 --> 00:08:22.560
way. So a lot of things, you know, were created in an
106
00:08:22.639 --> 00:08:26.959
ad hoc kind of a way,
and you know, you don't always have
107
00:08:28.120 --> 00:08:31.320
all the context and all the information, and by the time you have a
108
00:08:31.360 --> 00:08:35.600
better understanding of what it is that
you actually want to do or the way
109
00:08:35.639 --> 00:08:41.600
that it should be done, people
are already using whatever you've created, and
110
00:08:41.759 --> 00:08:46.279
much like the web itself, there
are no vackseats. Yeah. Absolutely like
111
00:08:46.879 --> 00:08:52.480
the successive node and NPM just has
like enshrined a lot of those patterns that
112
00:08:52.519 --> 00:08:56.519
we kind of take for granted in
doing super side jobscript today. Yeah,
113
00:08:56.519 --> 00:08:58.279
and common jass is one of those
examples, right, Like there wasn't a
114
00:08:58.320 --> 00:09:03.840
Web standard module API in you know
twenty you know what it was, It
115
00:09:03.840 --> 00:09:07.879
would have been like twenty ten twenty
when like node was still originally being created,
116
00:09:09.480 --> 00:09:11.879
and so common jass was one of
the ideas that was floating around that
117
00:09:11.919 --> 00:09:16.960
they implemented. And yeah, it's
just we've kind of standardized in certain directions
118
00:09:18.120 --> 00:09:20.799
or like we've learned things or you
know, created new technology that didn't exist
119
00:09:20.799 --> 00:09:26.120
in those days. By the way, I think the no go for it,
120
00:09:26.240 --> 00:09:28.960
I was going to say, I
think the no vaccines is really the
121
00:09:30.000 --> 00:09:35.000
best way of putting it where.
Yeah, it's not that node couldn't innovate
122
00:09:35.039 --> 00:09:37.720
in the ways that Dino is.
It's more that, yeah, they had
123
00:09:37.759 --> 00:09:41.240
all of this stuff that you know, had kind of been built onto it
124
00:09:41.279 --> 00:09:46.879
over time that people relied on.
And yeah, I mean we see this
125
00:09:46.919 --> 00:09:52.080
in all kinds of stuff, including
the ECMAScript standard. Right, they don't
126
00:09:52.480 --> 00:09:56.480
they don't kill stuff off, at
least not very often, and so you
127
00:09:56.480 --> 00:09:58.240
know, you have these people that
rely on this stuff, and yeah,
128
00:09:58.240 --> 00:10:01.320
you can't pull it back, and
so the only way to move forward kind
129
00:10:01.320 --> 00:10:05.000
of like what Angler did way back
in the day, right, moving from
130
00:10:05.000 --> 00:10:09.399
one to two, except they just
kept the name and confused a bunch of
131
00:10:09.399 --> 00:10:11.919
people and it cost some issues for
them. But yeah, it's the same
132
00:10:11.960 --> 00:10:15.159
idea where it's Okay, we need
to move forward in these ways, but
133
00:10:15.240 --> 00:10:20.559
we can't do it without breaking compatibility
in the background. I think another great
134
00:10:20.600 --> 00:10:24.799
example of that is the use of
promises and the sync of weight. If
135
00:10:24.840 --> 00:10:28.720
you look at the nod APIs,
you know most of them were created,
136
00:10:30.240 --> 00:10:35.159
at least the fundamental ones were created
before promises were a thing, and certainly
137
00:10:35.200 --> 00:10:41.759
before the JavaScript language had built in
a sinker weight. So it uses different
138
00:10:41.799 --> 00:10:48.799
patterns, uses patterns like calledbacks and
stuff like that. And with Dino,
139
00:10:48.919 --> 00:10:54.039
I believe much of the APIs,
especially because it is trying to use modern
140
00:10:54.120 --> 00:11:01.879
web APIs whenever possible, a lot
of these APIs are promise based fetch yeah,
141
00:11:01.960 --> 00:11:05.519
yeah, I mean, and since
like note of course, like a
142
00:11:05.519 --> 00:11:09.360
lot of the core APIs also provide
a promise based interface that's sort of been
143
00:11:09.399 --> 00:11:13.600
grafted over the top of the callback
based interfaces. But yeah, I mean
144
00:11:13.720 --> 00:11:18.919
a lot of those, you know, the the Web standard APIs like fetch
145
00:11:18.519 --> 00:11:26.279
are you available? The UH and
ECMAScript language features that do appear in node
146
00:11:26.320 --> 00:11:28.879
and they and they will filter their
way into UH, you know, into
147
00:11:28.919 --> 00:11:33.120
note over time too, will usually
show up in DINO first, like for
148
00:11:33.600 --> 00:11:37.000
for example, like top level async
a weight is something that you can do
149
00:11:37.159 --> 00:11:41.600
in DINO, which I think is
behind a flag and Node. I'd have
150
00:11:41.639 --> 00:11:46.919
to actually double check. I'm not
sure if it's available with a flag or
151
00:11:46.960 --> 00:11:50.559
in some other context. But yeah, so like these for of bleeding edge
152
00:11:50.759 --> 00:11:56.159
Ecmoscript language features will tend to make
their way into Deno a little a little
153
00:11:56.159 --> 00:12:03.919
faster as well. Now, one
of the things that NOE or Dino sorry
154
00:12:03.000 --> 00:12:07.799
created when it came about, By
the way, just if everybody, if
155
00:12:07.919 --> 00:12:13.960
our listeners aren't didn't notice, aren't
aware, Dino is literally spelled backwards,
156
00:12:13.039 --> 00:12:18.919
right, that's the point of the
name. Yes, that that is kind
157
00:12:18.960 --> 00:12:20.679
of where it came from. It's
actually like if you were to sort the
158
00:12:20.759 --> 00:12:28.080
characters in note on that is how
you get do you oh cool? So
159
00:12:28.159 --> 00:12:31.159
one of the things that you also
introduced in Dino, as I recall,
160
00:12:31.320 --> 00:12:39.559
is like a quote unquote standard library, a collection of JavaScript or typescript utility
161
00:12:39.639 --> 00:12:46.000
functions and objects and classes and whatnot
that can be used in the code and
162
00:12:46.200 --> 00:12:48.480
if. One of the things,
by the way, that I find kind
163
00:12:48.480 --> 00:12:54.919
of unfortunate is that it seems that
this standard library did not make its way
164
00:12:54.000 --> 00:13:00.840
out of Dino into the JavaScript community
at large. I would have loved to
165
00:13:00.879 --> 00:13:05.960
see a lot of this functionality just
generally available everywhere. Yeah. So the
166
00:13:05.440 --> 00:13:13.000
Yeah, the Deno Standard Library,
at least until recently, was largely mostly
167
00:13:13.080 --> 00:13:16.600
usable in Dino. There are ways
to use it outside of the context of
168
00:13:16.639 --> 00:13:20.759
Dino. With the event of JSR, which is a registry, I don't
169
00:13:20.799 --> 00:13:24.000
know if we'll get into it,
you know, in this sort of conversation.
170
00:13:24.480 --> 00:13:28.639
Uh, the standard library has been
published on JSR now as well,
171
00:13:28.679 --> 00:13:33.720
and since JSR modules can be used
in any runtime environment, the Deno standard
172
00:13:33.759 --> 00:13:37.679
Library is now you know, kind
of available in Node or you know,
173
00:13:37.720 --> 00:13:41.720
in your es build code for that
you create for the browser, or in
174
00:13:41.799 --> 00:13:45.480
bun so a lot of that stuff
kind of has been freed from a Dino
175
00:13:45.559 --> 00:13:50.480
specific packaging. That's excellent. I
really hope that something like that library can
176
00:13:50.559 --> 00:13:58.000
become more than a quote unquote standard
library and actual standard library for JavaScript slash,
177
00:13:58.039 --> 00:14:03.240
acmascript, slash s typescript, that
would be awesome. It just provides
178
00:14:03.279 --> 00:14:07.519
a lot of useful functionality that a
lot of people end up recreating themselves on
179
00:14:07.600 --> 00:14:13.320
as a one off basis. Yeah, yeah, for sure. Hopefully that
180
00:14:13.360 --> 00:14:16.000
will start to make its way out
a little bit as the you know,
181
00:14:16.039 --> 00:14:20.960
as people start you know, adopting
adopting JSR for other purposes to you.
182
00:14:22.320 --> 00:14:26.399
Now, you mentioned that one of
the reasons that Dino can do all this
183
00:14:26.480 --> 00:14:31.600
stuff and kind of you know,
introduced all these innovations is the fact that,
184
00:14:31.919 --> 00:14:39.120
unlike Node that has to contend with
all the legacy packages and legacy code
185
00:14:39.159 --> 00:14:45.679
and legacy functionality, you had the
ability to do a fresh start. I
186
00:14:45.720 --> 00:14:50.759
guess in many ways, Ryan kind
of decided to do Dino because he understood
187
00:14:50.759 --> 00:14:58.840
that he can't do everything that he
wants to do on the existing Node codebase.
188
00:15:00.919 --> 00:15:05.480
So my question then, is like
one of the primary reasons that people
189
00:15:05.679 --> 00:15:13.080
use Node is because of this compatibility
that it has with all these existing modules
190
00:15:13.159 --> 00:15:20.480
and applications and whatnot, and in
many ways they kind of depend on all
191
00:15:20.600 --> 00:15:28.960
this like not necessarily specified behavior that's
built into node, not necessarily documented,
192
00:15:28.080 --> 00:15:33.320
you know, like they depend on
the bugs. So the question is you
193
00:15:33.919 --> 00:15:37.759
kind of I find uside correctly,
you kind of need to compete with that.
194
00:15:37.840 --> 00:15:39.519
I mean, sure, if I'm
starting a new project from scratch,
195
00:15:39.600 --> 00:15:43.600
then maybe I pick Dino, But
then maybe I'm risking the fact that the
196
00:15:43.639 --> 00:15:48.399
package that I really want to use
is not available for Dino. So how
197
00:15:48.440 --> 00:15:54.399
do I contend with that? Yeah, it's it's definitely been like the major
198
00:15:54.519 --> 00:15:56.919
challenge at the core of like how
Dino has evolved. I would say like
199
00:15:56.960 --> 00:16:03.440
over the last five years is like
the gravitational pull of the NPM ecosystem is
200
00:16:03.600 --> 00:16:07.759
pretty strong, and there's just a
lot of tooling and libraries that exists that
201
00:16:07.840 --> 00:16:14.879
exist there that are kind of non
optional in server side JavaScript development today.
202
00:16:15.240 --> 00:16:18.480
So a lot of work on the
Dino team these days goes into our node
203
00:16:18.480 --> 00:16:23.080
compatibility layer, where, yes,
with Dino's design, we do want to
204
00:16:23.279 --> 00:16:29.559
maintain an environment where we do use
ECMAScript modules only, and we don't you
205
00:16:29.600 --> 00:16:33.440
know, support common ass uh you
know as a like outside of this compatibility
206
00:16:33.480 --> 00:16:37.279
layer, and we do want to
favor you know, Web Standard APIs whenever
207
00:16:37.360 --> 00:16:42.960
possible. But the fact that like
the sort of reality is that a lot
208
00:16:44.000 --> 00:16:48.080
of the Node ecosystem is necessary if
you want to be if you would like
209
00:16:48.120 --> 00:16:52.360
to be productive in server side JavaScript
today. So, uh, the node
210
00:16:52.360 --> 00:16:57.759
compatibility layer in Youno allows you to
use just about any package that exists in
211
00:16:59.080 --> 00:17:04.119
NPM, like we have shim APIs
available for most of Node Core, which
212
00:17:04.160 --> 00:17:10.920
then enables a lot of the NPM
ecosystem to function on On Dino, it
213
00:17:11.000 --> 00:17:15.279
is slightly different because the way in
which you'd depend on a package, you
214
00:17:15.319 --> 00:17:18.279
know, could be a little different
in Dino than it was in Node.
215
00:17:18.400 --> 00:17:22.880
But we've also like implemented a lot
of compatibility features. Like you know,
216
00:17:23.519 --> 00:17:29.079
by default in Dino, when you
import a JavaScript file, you have to
217
00:17:29.119 --> 00:17:33.880
include the extension of that file.
And that's for a couple of reasons.
218
00:17:33.000 --> 00:17:36.599
Number, like in the browser,
if you're importing a file, like you
219
00:17:36.680 --> 00:17:41.599
always include the extension of the file. So that's kind of where that design
220
00:17:41.640 --> 00:17:45.519
pattern came from. It's also slightly
more efficient because you know, if you
221
00:17:45.640 --> 00:17:49.400
leave off the file extension, then
the run time has to do a bunch
222
00:17:49.440 --> 00:17:53.200
of checking to see, like are
you actually trying to import a tsx file
223
00:17:53.240 --> 00:17:56.559
a ts file like a JS file
like, and there's a lot of sort
224
00:17:56.559 --> 00:18:03.839
of overhead that comes along with that. Dino provides a mode that is cheekily
225
00:18:03.960 --> 00:18:07.799
probably named sloppy imports, which is
like an option that you can pass into
226
00:18:07.839 --> 00:18:12.759
the run time which is tolerant of
more Node style imports that leave off the
227
00:18:12.920 --> 00:18:18.079
extension. And with a combination of
some of these compatibility features, you can
228
00:18:18.119 --> 00:18:22.519
take a lot of code that was
originally written for noe js and run it
229
00:18:22.599 --> 00:18:27.559
in Dino without really having to change
much of anything. And the big push
230
00:18:27.599 --> 00:18:32.279
for us for Dono two point zero
for this year is like getting to the
231
00:18:32.319 --> 00:18:37.640
point where we feel like the most
vast majority of the most important Node packages
232
00:18:37.559 --> 00:18:41.519
just work in Dino, and I
don't know if we'll ever Like our goal
233
00:18:41.559 --> 00:18:47.039
isn't explicit to get to like being
a drop in replacement for node necessarily,
234
00:18:47.480 --> 00:18:49.720
but we want next js to work
on Dino, Like we want, you
235
00:18:49.720 --> 00:18:52.920
know, all the web frameworks that
you would want to use from the noe
236
00:18:52.960 --> 00:18:59.119
ecosystem to work really well on Dino
as well. So that's probably our biggest
237
00:18:59.160 --> 00:19:04.720
like engineering objective like over the next
several months is just continuing to improve like
238
00:19:04.799 --> 00:19:11.680
the set of compatibility features that we
have for some of those undocumented features.
239
00:19:11.759 --> 00:19:17.359
Like you know, when you NPM
install a module to node modules, you
240
00:19:17.400 --> 00:19:21.359
know, the NPM clients have certain
behavior as far as like how those modules
241
00:19:21.359 --> 00:19:26.799
are unpacked, which then other modules
depend on. Like I think, like
242
00:19:26.799 --> 00:19:30.519
if you install tailwind, it expects
like post CSS or something to be to
243
00:19:30.599 --> 00:19:34.680
be have been already installed, and
it actually introspects the contents of the node
244
00:19:34.680 --> 00:19:41.480
modules folder to do some things to
use that dependency. The note ecosystem is
245
00:19:41.480 --> 00:19:45.720
just kind of full of these little
nooks and crannies and like strange behaviors that
246
00:19:45.799 --> 00:19:48.680
have been built on top of that. We're you know, trying to find
247
00:19:48.680 --> 00:19:55.279
the best way as possible to like
support those while still providing like the DX
248
00:19:55.279 --> 00:19:59.359
that we want to provide through.
You know that this kind of reminds me
249
00:19:59.400 --> 00:20:03.039
of It kind of reminds me of
the Windows world. A lot of our
250
00:20:03.079 --> 00:20:06.720
listeners might be too young to remember
that, but for a long time when
251
00:20:06.720 --> 00:20:14.039
Windows was like the primary platform for
which software was being written, Windows itself
252
00:20:14.119 --> 00:20:18.039
had all these bugs going from version
to version, and they literally had to
253
00:20:18.680 --> 00:20:22.240
you know, when they created a
new version of Windows, maybe even using
254
00:20:22.240 --> 00:20:27.880
a different technology. They often had
to actually emulate buggy behavior just in order
255
00:20:27.920 --> 00:20:33.960
to make sure that older software continued
to run, because you know, if
256
00:20:33.319 --> 00:20:37.880
if you upgraded your Windows, then
all of a sudden your favorite game stopped
257
00:20:37.880 --> 00:20:41.720
working, you would blame Microsoft,
not the game, not the game creator.
258
00:20:41.799 --> 00:20:45.000
Yeah. I was gonna say,
I had to run tie Fighter in
259
00:20:45.119 --> 00:20:48.839
Windows ninety five compatibility mode for a
long time until you know, I found
260
00:20:48.880 --> 00:20:55.839
like a more modern or that I
could use otherwise. So, but I
261
00:20:55.880 --> 00:20:59.119
do have to ask, I mean, if you're putting in all this effort,
262
00:20:59.599 --> 00:21:04.880
and it's seems like a huge amount
of effort into emulating Node on top
263
00:21:04.920 --> 00:21:11.920
of Dino as it were, to
an extent, then like, why do
264
00:21:11.960 --> 00:21:15.599
I want to go with emulation?
Why shouldn't I just pick the original?
265
00:21:15.680 --> 00:21:22.400
What's the main benefit for me,
as a back end JavaScript developer or a
266
00:21:22.480 --> 00:21:29.359
full stack JavaScript developer of using Dino
over Node, especially if I do assume
267
00:21:29.440 --> 00:21:33.359
that I want to be using you
know, all this functionality that exists and
268
00:21:33.440 --> 00:21:36.720
not write everything from scratch. Yeah. So, I mean, I think
269
00:21:36.720 --> 00:21:41.599
there's a couple of reasons. The
first one is probably just reducing kind of
270
00:21:41.640 --> 00:21:47.200
the startup costs and complexity of your
project, where like you do have typescript
271
00:21:47.200 --> 00:21:51.359
built in by default, you have
the Testerlinter format or all of those tools
272
00:21:51.400 --> 00:21:56.119
available out of the box. So
the developer experience of like not having to
273
00:21:56.200 --> 00:22:00.880
manage those things and being able to
keep your code a little leaner and not
274
00:22:02.160 --> 00:22:08.160
have quite so many third party dependencies
is potentially somewhat attractive. Also, like
275
00:22:08.240 --> 00:22:11.759
a lot of the libraries that you
use in Node today probably are just like
276
00:22:11.799 --> 00:22:15.759
a little bit faster on Dino.
So like if an express server that you
277
00:22:15.799 --> 00:22:19.400
wrote a Node is just going to
be probably a little bit faster in Dino
278
00:22:19.440 --> 00:22:22.759
than it is in Uh than it
is running on Node. And kind of
279
00:22:23.519 --> 00:22:27.200
there's a lot of you know,
contextual things there for like which you know
280
00:22:27.279 --> 00:22:33.799
packages and what set of maybe middlewares
you're using. But uh a uh,
281
00:22:33.160 --> 00:22:37.279
I just actually saw a post like
over the weekend about you know, there's
282
00:22:37.319 --> 00:22:42.279
a hdpre framework called oak, which
is like a middleware framework sort of inspired
283
00:22:42.319 --> 00:22:48.279
by Coha, and the author tested
it across you know, BUN and Node
284
00:22:48.319 --> 00:22:53.240
and Dino, uh to kind of
see what the performance characteristics were and know
285
00:22:53.480 --> 00:22:56.920
and Dino and Bun were you know, about the same Bun was actually ran
286
00:22:57.079 --> 00:23:02.759
ran HDP requests slightly fast. There
is like a maybe ten percent increase in
287
00:23:02.880 --> 00:23:07.000
overall throughput, but both were like
twice as fast as Node. So I
288
00:23:07.000 --> 00:23:11.200
think there's kind of some things that
you get for free by switching to switching
289
00:23:11.240 --> 00:23:17.279
to DNA as well, and you
were able to keep or maintain this performance
290
00:23:17.400 --> 00:23:22.319
benefit even when adding the backward compatibility
with node. I mean, that would
291
00:23:22.319 --> 00:23:27.000
seem to be the challenge. I
would imagine that with node improving performance in
292
00:23:27.079 --> 00:23:33.839
a lot of places kind of runs
smack dab into the problem of maintaining backward
293
00:23:33.920 --> 00:23:41.839
compatibility. Yeah, I mean there's
there's certainly challenges with that, But I
294
00:23:41.880 --> 00:23:48.039
mean, the the shim APIs that
we've created for like the underlying HDDP node
295
00:23:48.079 --> 00:23:52.359
core APIs utilize the same sort of
opter earthly they get to benefit from the
296
00:23:52.400 --> 00:23:59.240
same optimizations we've made in Dino to
make HDP requests handling fast. So those
297
00:23:59.279 --> 00:24:04.599
shim api do tend to perform uh
pretty well. So like we uh you
298
00:24:04.640 --> 00:24:10.039
know, have been doing some testing
with web frameworks like Astro, say,
299
00:24:10.400 --> 00:24:15.359
and just using the sort of node
adapter for Astro, which which enables like
300
00:24:15.400 --> 00:24:19.799
server side rendering of uh you know
pages in that framework. Uh, those
301
00:24:19.880 --> 00:24:26.279
Node APIs actually run slightly faster on
Dino for server side rendering than they do
302
00:24:26.480 --> 00:24:29.759
in in Node. And I think
it's just because of you know, the
303
00:24:29.880 --> 00:24:34.119
underlying infrastructure being you know, slight
like being slightly more performant, not necessarily
304
00:24:34.119 --> 00:24:40.200
because do you know, for you
know, is intrinsically always faster than uh
305
00:24:40.400 --> 00:24:42.400
Node. It's just that, you
know, and it's not like, you
306
00:24:42.400 --> 00:24:48.799
know, Node couldn't be this fast
potentially see as certainly uh, you know,
307
00:24:48.920 --> 00:24:52.519
just as fast as Rust or c
C plus plus or whatever. But
308
00:24:52.759 --> 00:24:56.839
yeah, it's just the uh,
A lot of work has gone into optimizing
309
00:24:56.880 --> 00:25:06.440
the HDP interfaces. I think it's
also legitimate, I would say for the
310
00:25:06.519 --> 00:25:11.400
performance improvements to be Let's put it
differently, it's okay for the shims to
311
00:25:11.519 --> 00:25:17.319
run slower if the code that doesn't
need the shims can run faster, if
312
00:25:17.359 --> 00:25:19.720
you understand what I'm trying to say, So, as long as I don't
313
00:25:19.839 --> 00:25:26.960
need some weird note functionality for backward
compatibility the standard stuff, if that runs
314
00:25:26.000 --> 00:25:32.319
faster, I'm happy with that,
even if the shims themselves like pay a
315
00:25:32.319 --> 00:25:38.960
certain price. But you wanted to
ask something about the built in Typescript support
316
00:25:40.000 --> 00:25:45.640
that you mentioned before. So I
actually posted a link in our chat to
317
00:25:45.759 --> 00:25:51.960
a great quote from Matteo Colina,
who is really deep in the node world,
318
00:25:52.039 --> 00:25:55.480
by the way, is one of
the maintainers I think of note and
319
00:25:55.559 --> 00:26:02.079
he wrote some tweet recently which was
really am using Anie opening to an extent,
320
00:26:02.519 --> 00:26:07.599
which is typescript does not exist.
There is a multiverse of Typescript implementations
321
00:26:07.599 --> 00:26:15.480
depending on the permutation of the configs. And he added also to that this
322
00:26:15.680 --> 00:26:19.000
kind of weirdness are the key reasons
why I'm still skeptical about the typescript.
323
00:26:19.440 --> 00:26:23.559
Now, I'm not skeptical about typescript, but I definitely appreciate what he said.
324
00:26:25.000 --> 00:26:30.160
The fact that the different values that
you put in your ts config file
325
00:26:30.240 --> 00:26:37.519
can significantly impact the functionality the behavior
of typescript, or put another way,
326
00:26:38.119 --> 00:26:42.680
kind of means that typescript is less
than of a language standard and more of
327
00:26:42.680 --> 00:26:49.359
a utility that you can configure in
a sense. So my question is how
328
00:26:49.400 --> 00:26:55.039
does DNO deal with that? I
mean, is it using the same ts
329
00:26:55.079 --> 00:27:02.680
config as typescript as TSC or something
else. How does that work? I
330
00:27:02.680 --> 00:27:06.039
mean, there's a sort of a
I think like what Matteo is saying is
331
00:27:06.079 --> 00:27:11.039
correct, right, Like the like
the configurability of typescript does introduce a lot
332
00:27:11.039 --> 00:27:18.079
of different permutations of how Typescript can
behave one I think benefit in the context
333
00:27:18.119 --> 00:27:22.279
of Dino is that you know,
there is a set of behavior that's sort
334
00:27:22.279 --> 00:27:27.559
of codified and how Typescript runs on
Dino. So there isn't sort of an
335
00:27:27.640 --> 00:27:33.279
unlimited amount of configurability for like compiler
options and stuff like that. There is
336
00:27:33.279 --> 00:27:37.759
certainly is some and there are some
you know of those configure out configuration options
337
00:27:37.759 --> 00:27:45.880
that do still work in Dino,
but the Typescript environment is relatively predictable versus
338
00:27:45.920 --> 00:27:49.400
in in node, where you do
have like kind of full configurability of how
339
00:27:49.559 --> 00:27:53.759
the uh TSK or like how TSC
works at the end of the day.
340
00:27:53.839 --> 00:27:59.680
So yeah, but like the point
stands that, you know, if you
341
00:27:59.799 --> 00:28:03.240
have access to all those compiler options, it makes it very difficult to write
342
00:28:03.279 --> 00:28:07.720
touch script code that you know can
very can predictably run with every set of
343
00:28:07.759 --> 00:28:11.839
compiler options. So am I stuck
then with how you did it then?
344
00:28:14.880 --> 00:28:17.839
To a degree? Right, Like, so there are certain things that are
345
00:28:17.839 --> 00:28:22.039
configurable, there are certain things that
are not so there's probably features of like
346
00:28:22.160 --> 00:28:30.039
ts config that would work in a
node environment that are impossible in Dino just
347
00:28:30.079 --> 00:28:34.079
because we don't support those those options. So it is a constraint that exists
348
00:28:34.119 --> 00:28:38.480
for sure. By the way,
not supporting some ts configure options is actually
349
00:28:38.519 --> 00:28:44.039
a good thing, because I've literally
seen projects that were configured in such a
350
00:28:44.039 --> 00:28:51.599
way that interface definitions weren't each actually
even being used, and the developers didn't
351
00:28:51.599 --> 00:28:59.200
even notice. So like there were
incorrect types and literally types with errors in
352
00:28:59.240 --> 00:29:04.240
them, and the projects seemed to
compile fine because everything that was using like
353
00:29:04.319 --> 00:29:11.240
an unrecognized the imports didn't actually work, and anything that used an interface that
354
00:29:11.359 --> 00:29:17.200
wasn't specified defaulted to any instead.
So they basically had everything as any,
355
00:29:17.599 --> 00:29:22.200
but they thought they were writing typescript
but actually had everything as any, which
356
00:29:22.279 --> 00:29:26.519
is like the worst of all possible
worlds. Yeah, so all the overhead
357
00:29:26.519 --> 00:29:30.519
of using TSC with none of the
actual compile time safety, Yeah, that
358
00:29:30.559 --> 00:29:36.640
seems exactly exactly. So if you're
prevented from being able to do that,
359
00:29:36.759 --> 00:29:40.839
I would definitely count that as a
good thing. But what is the actual
360
00:29:40.920 --> 00:29:47.519
benefit of having the typescript functionality built
into the environment. I mean, let's
361
00:29:47.519 --> 00:29:52.200
put it differently. With Typescript,
I see two main benefits. One is,
362
00:29:52.319 --> 00:29:56.400
while I'm writing the code in the
development environment in let's say VS code,
363
00:29:56.839 --> 00:30:00.720
it does all the type checking for
me, squiggly lines, the completion
364
00:30:02.920 --> 00:30:07.400
stuff like that, and and and
highlights files that has have errors in them
365
00:30:07.440 --> 00:30:15.279
and so forth. The other advantage
is is the actually the actual compilation step
366
00:30:15.279 --> 00:30:18.559
to an extent, because if I
have errors in my you know, type
367
00:30:18.640 --> 00:30:25.519
errors in my code and not a
too funky ts configure settings, then the
368
00:30:25.559 --> 00:30:33.480
built step will actually fail if I
try to build something bad, so because
369
00:30:33.519 --> 00:30:37.960
I'm ignoring squiggly lines and VS code
for some reason. So my question is,
370
00:30:38.480 --> 00:30:42.240
you know, with with dno,
you don't need that built step or
371
00:30:42.279 --> 00:30:47.839
you don't have that built step.
So am I maybe kind of even losing
372
00:30:48.000 --> 00:30:52.319
some benefits of Typescript by working this
way? And alternatively, what are the
373
00:30:52.359 --> 00:30:57.440
advantages of working this way? Actually? So there is still a build step
374
00:30:57.599 --> 00:31:03.200
that happens. Like so there's a
UST based sort of equivalent of TSC which
375
00:31:03.200 --> 00:31:08.200
we would use sort of at run
time to generate the jobscript code because like
376
00:31:08.640 --> 00:31:15.359
Dino runs JavaScript code in VA similar
to how Node does. So we still
377
00:31:15.400 --> 00:31:19.319
do need to transpile typescript before it's
able to run in that environment, because
378
00:31:19.440 --> 00:31:26.319
VA doesn't natively understand typescript, So
there is a sort of build build step
379
00:31:26.359 --> 00:31:30.160
that happens as a result of running
your code on you know, it's just
380
00:31:30.200 --> 00:31:34.839
that it is opaque in that like
to you as a developer, it doesn't
381
00:31:34.880 --> 00:31:38.440
seem like you need to handle that, even though it is happening for you
382
00:31:40.240 --> 00:31:47.319
behind the scenes. I think the
advantage of having typescript built in largely comes
383
00:31:47.400 --> 00:31:51.960
from how you get to manage your
source code. So you know, you
384
00:31:52.039 --> 00:31:56.559
can you know, version controlled typescript, and you can you know, in
385
00:31:56.559 --> 00:32:00.480
the case of uh, you know
JSR, you can publish typescript directly to
386
00:32:00.559 --> 00:32:05.160
the registry. Other typescript developers don't
have to rely on your transpile code.
387
00:32:05.200 --> 00:32:09.759
They could actually import typescript source code
that you have written into their project should
388
00:32:09.759 --> 00:32:14.559
they should they need to. So
being able to just actually manage your your
389
00:32:14.599 --> 00:32:19.759
code base as typescript without having to
think about transporlation as a part of that
390
00:32:20.519 --> 00:32:23.000
ends up being ends up being kind
of nice in a lot of a lot
391
00:32:23.039 --> 00:32:29.920
of different contexts. So it's basically
reducing friction in the development process. Yeah,
392
00:32:29.960 --> 00:32:34.599
yeah, kind of friction, kind
of the overhead of that transportation process.
393
00:32:34.640 --> 00:32:37.720
Like you do, you kind of
don't have to consider it within your
394
00:32:37.720 --> 00:32:39.720
workflow. So side note, really
quick, Am I the only one that
395
00:32:39.759 --> 00:32:45.839
thinks of vegetable juice when I hear
V eight? There was a time I
396
00:32:45.839 --> 00:32:51.799
think I've gotten yeah? Or yeah, I think you know I should have
397
00:32:51.839 --> 00:32:54.640
had a V eight commercials for those
who are too young to remember that anyway,
398
00:32:55.880 --> 00:32:59.599
Yeah, but it's time. Sift
is not the only thing that you
399
00:32:59.640 --> 00:33:04.039
built. I think you mentioned it
that you've also got like a testing framework
400
00:33:04.119 --> 00:33:07.319
built in, You've got a linter
built in. Can you elaborate about these
401
00:33:07.359 --> 00:33:12.880
a little bit? Yeah? Sure, so yeah, so Dino has like
402
00:33:13.599 --> 00:33:15.920
a test command that's built in.
If you run like Dino help after you
403
00:33:15.960 --> 00:33:20.559
install Youno, you can get a
sense of like what all these command line
404
00:33:20.599 --> 00:33:24.359
tools are. But yeah, it
was really about, like there's a lot
405
00:33:24.359 --> 00:33:29.119
of decisions that you make when you're
bootstrapping a node project. They aren't really
406
00:33:29.200 --> 00:33:34.119
that important, like which test framework
you use, possibly not that important,
407
00:33:34.200 --> 00:33:37.480
which linter you use, and what
your linter settings are or what your format
408
00:33:37.559 --> 00:33:40.920
or settings are probably also not important, Like you can kind of bike shed
409
00:33:42.079 --> 00:33:45.880
on these things, if that's if
that is your preference. But also I
410
00:33:45.960 --> 00:33:50.599
just think that, you know,
accepting a set of defaults tends to be
411
00:33:50.720 --> 00:33:53.079
kind of nice. One thing that
I've really noticed is as I've gone between
412
00:33:53.200 --> 00:33:59.559
different Dino projects, because the testing
framework is the same, because the winter
413
00:33:59.599 --> 00:34:02.359
settings are the same and the formatter
settings are the same, Like, it's
414
00:34:02.440 --> 00:34:07.400
much less jarring to kind of go
from one Deno project to the next,
415
00:34:07.440 --> 00:34:10.920
because like the lay of the land
is pretty similar. So like having this
416
00:34:12.559 --> 00:34:16.199
sort of similarity is useful to you
as a developer because it takes like kind
417
00:34:16.199 --> 00:34:20.800
of trivial decisions, you know,
out of your hands. I'm I mean,
418
00:34:20.840 --> 00:34:23.039
you certainly could use other test frameworks
if you want, but you know,
419
00:34:23.039 --> 00:34:27.199
you don't necessarily have to make those
decisions, and it helps you kind
420
00:34:27.199 --> 00:34:30.239
of go from one project to the
next. I used to use Rubion rails
421
00:34:30.280 --> 00:34:32.960
for a long time, and that
was one thing that was kind of nice
422
00:34:34.039 --> 00:34:37.159
about a lot of those projects was
I knew the models were in this folder,
423
00:34:37.280 --> 00:34:42.880
and like a lot of those conventions
kind of helped me like navigate those
424
00:34:42.920 --> 00:34:45.559
projects, even if I was relatively
new to them. Like rails projects can
425
00:34:45.639 --> 00:34:49.880
be very you know, diverse in
a lot of other ways, but like
426
00:34:49.960 --> 00:34:52.960
some of that similarity is helpful in
terms of like the other tools that are
427
00:34:52.960 --> 00:34:58.199
built in. I mentioned Dino compile, which you know, you can point
428
00:34:58.280 --> 00:35:02.239
at a type script source code file
and it generates a binary that can be
429
00:35:02.360 --> 00:35:07.000
run cross platform. So like it's
a good way to kind of compartmentalize like
430
00:35:07.039 --> 00:35:10.360
a web server, say into just
a binary that you can run on you
431
00:35:10.400 --> 00:35:15.760
know, an arbitrary server somewhere.
Or if you're making a command line utility,
432
00:35:15.760 --> 00:35:19.840
it's a really easy way to create
like a cross platform command line utility.
433
00:35:19.960 --> 00:35:27.079
So t which is the package manager
that is was replacing Homebrew, or
434
00:35:27.159 --> 00:35:30.519
like the original author of Homebrew used
Dino to create Tea, which is kind
435
00:35:30.519 --> 00:35:36.000
of his sort of next generation version
of that package manager. And he used
436
00:35:36.000 --> 00:35:42.360
Dino for this reason actually because he
wanted to write typescript, wasn't necessarily interested
437
00:35:42.559 --> 00:35:47.239
in you know, having that transportation
step, and the ability of Dino to
438
00:35:47.400 --> 00:35:53.960
package up a cross platform executable was
convenient there as well. So Dino compiles
439
00:35:54.000 --> 00:36:00.119
super useful. Certainly a few other
nicely. So there's a Dino doc which
440
00:36:00.159 --> 00:36:02.639
is also a built in utility and
you can point it at a typescript file
441
00:36:04.440 --> 00:36:08.239
or a dot D dot t S
file and you'll kind of introspect those files
442
00:36:08.239 --> 00:36:14.920
and generate HTML documentation for your you
know, for your type script source or
443
00:36:14.920 --> 00:36:17.840
from your type configuration. So yeah, so there ends up being kind of
444
00:36:17.840 --> 00:36:22.440
a lot in the box, which
is which is pretty nice. By the
445
00:36:22.519 --> 00:36:28.679
way, does your typescript implementation also
support jastock I yes, it does,
446
00:36:29.119 --> 00:36:30.800
so, yeah, that's that's kind
of where it's pulling a lot of that.
447
00:36:31.039 --> 00:36:36.679
It'll pull documentation content from jas dot
comments if they if they exist,
448
00:36:37.079 --> 00:36:39.519
and a lot and it can guess
a lot just from type information as well.
449
00:36:40.079 --> 00:36:46.599
AJ will be happy. So I'm
old enough to remember the Unix days
450
00:36:47.079 --> 00:36:52.440
that the whole point was one of
the big selling points was that a lot
451
00:36:52.519 --> 00:36:58.800
of those built commands that are were
built into other operating systems in the Unix
452
00:36:58.800 --> 00:37:07.000
world will implement it as separate executables
or and ran as distinct userland processes,
453
00:37:07.239 --> 00:37:13.039
and weren't really built into Unix itself. But now it seems like with you
454
00:37:13.119 --> 00:37:19.519
and with bun that everything is kind
of being built into the main to that
455
00:37:19.719 --> 00:37:24.880
single executable like Dino with the one
command line switch does one thing, with
456
00:37:24.960 --> 00:37:30.519
a different command line switch does some
other thing. What's the motivation? What's
457
00:37:30.559 --> 00:37:35.800
the advantage of bundling all this functionality, you know, some of which could
458
00:37:35.840 --> 00:37:39.159
definitely be like distinct and standalone.
I mean, like the test runner now,
459
00:37:39.360 --> 00:37:44.960
like why what's the benefit of having
it built into that same executable and
460
00:37:45.039 --> 00:37:51.559
not being split off into a separate
executable file. I think like it's kind
461
00:37:51.559 --> 00:37:59.119
of you know, you're deciding where
and when to manage complexity within your project.
462
00:37:59.320 --> 00:38:01.760
Like if you are using uh,
you know, some kind of utility
463
00:38:01.760 --> 00:38:07.639
and user land. The complexity that
comes along with that is keeping that dependency
464
00:38:07.719 --> 00:38:12.360
up to date and whatever plumbing needs
to happen to kind of pipe the input
465
00:38:12.440 --> 00:38:16.000
and output from like one utility into
the next, and uh, you know,
466
00:38:16.079 --> 00:38:22.960
the Unix philosophy is definitely one of
the reasons that that like operating system
467
00:38:22.000 --> 00:38:25.679
has been so popular and continues to
be, uh like one of the best
468
00:38:25.679 --> 00:38:32.440
options for especially like technical you know, sort of technical use cases or like
469
00:38:32.519 --> 00:38:38.360
running code on servers that sort of
thing. But the uh, the price
470
00:38:38.400 --> 00:38:44.599
that you pay in like application programming
tool like uh, you know, something
471
00:38:44.639 --> 00:38:46.920
that's a little higher level, like
a DNO or a node or a bun
472
00:38:47.639 --> 00:38:51.760
is that, you know, the
things that you will tend to need over
473
00:38:51.840 --> 00:38:57.239
and over again. You have to
sort of reinvent every single time you create
474
00:38:57.400 --> 00:39:01.920
a new project, and the overhead
of you know, the startup costs and
475
00:39:02.159 --> 00:39:07.480
maintaining you know, a package dot
Jason that has twelve dependencies in it,
476
00:39:08.280 --> 00:39:13.199
none of which are actually have anything
to do with the functionality or a project.
477
00:39:13.199 --> 00:39:15.880
It's just like the tooling that you
need to actually build your code,
478
00:39:16.000 --> 00:39:21.400
test your code, lint your code, that sort of thing. There's a
479
00:39:21.440 --> 00:39:25.559
price that comes with that as well. There's certainly flexibility. But when you
480
00:39:25.599 --> 00:39:30.159
consider the trade offs of like,
Okay, now I have you know,
481
00:39:30.320 --> 00:39:35.199
this this dependency on jest and it
depends on this other thing. And now
482
00:39:35.239 --> 00:39:38.239
when I run you know, in
PAM install, I get these these conflicts
483
00:39:38.239 --> 00:39:42.440
that I have to kind of work
my way through and then I have to
484
00:39:42.519 --> 00:39:46.639
update, upgrade this dependency, et
cetera. So like taking dependencies out of
485
00:39:46.679 --> 00:39:54.239
the mix reduces the like maintenance complexity
in a pretty meaningful way that I think
486
00:39:54.360 --> 00:40:00.159
is kind of worth the trade off
in at least in this instance. But
487
00:40:00.280 --> 00:40:02.440
you know, there's certainly arguments to
be made the other way that you know,
488
00:40:02.480 --> 00:40:07.440
a lot of these utilities certainly could
be user land tools and evolve separately,
489
00:40:07.960 --> 00:40:13.360
but because they're kind of core to
any application that's non trivial, including
490
00:40:13.400 --> 00:40:17.079
them as part of the platform tends
to be a trade off that that helps.
491
00:40:17.840 --> 00:40:22.840
So if I'm using Dino, then
I likely won't install prettier and es
492
00:40:23.239 --> 00:40:28.280
lint and ts s lint and stuff
like that, or just use whatever is
493
00:40:28.400 --> 00:40:32.320
built in. Yep, that is
the intent that you wouldn't necessarily have to
494
00:40:32.440 --> 00:40:37.280
bring those tools in unless you're using
Dino in the context of an existing Node
495
00:40:37.320 --> 00:40:40.760
project, in which case you might
still you know, have those tools around.
496
00:40:40.840 --> 00:40:44.800
But yeah, and a Dino project, the expectation is you won't need
497
00:40:44.840 --> 00:40:51.280
to have those things. Cool.
I'm kind of curious. I'm going to
498
00:40:51.360 --> 00:40:55.400
change gears on a little bit.
How did you get into Dino, right?
499
00:40:55.440 --> 00:41:00.719
What's your story here? Yes,
so, I've been you know,
500
00:41:00.719 --> 00:41:05.400
a no Jazz user since like I
think the first code I wrote was for
501
00:41:05.719 --> 00:41:09.559
zero point eight of Node, and
at that time I was working at a
502
00:41:09.599 --> 00:41:15.360
company called Twilio, which is like
an API provider like messaging, telephany stuff
503
00:41:15.360 --> 00:41:19.440
like that, and Node was pretty
new and I was like, oh,
504
00:41:19.480 --> 00:41:22.480
Twillia, we should have totally have
like a client library for this node thing.
505
00:41:22.559 --> 00:41:23.440
I think, I think this,
I think it has legs. I
506
00:41:23.480 --> 00:41:28.880
think it's going to go somewhere.
So I wrote like an HGP client wrapper
507
00:41:28.960 --> 00:41:34.360
for like the Twilio API in Node
back in those days and the thing,
508
00:41:34.840 --> 00:41:37.440
and I kind of fell in love
with it because like, finally this my
509
00:41:37.559 --> 00:41:43.920
investment in JavaScript. I could now
use JavaScript a program every kind of thing,
510
00:41:44.079 --> 00:41:49.199
like from servers to front end robots, everything in between. So using
511
00:41:49.280 --> 00:41:52.599
JavaScript is kind of the lingua franc
of web development. Has kind of kept
512
00:41:52.639 --> 00:41:55.679
me involved in server side JavaScript for
a long time. But I think,
513
00:41:55.760 --> 00:42:00.880
like like a lot of Node users, like over time, you started to
514
00:42:00.960 --> 00:42:05.840
get the feeling that Node had jumped
the shark a little bit, where it's
515
00:42:05.920 --> 00:42:08.280
just like I look at a standard
Node project and I look at all these
516
00:42:08.320 --> 00:42:15.039
configuration files that I have without having
even having like written any code like there.
517
00:42:15.079 --> 00:42:20.000
There was certainly a certain amount of
discontent with how much complexity it kind
518
00:42:20.000 --> 00:42:25.440
of crept into the ecosystem. So
the prospect of having this this set of
519
00:42:27.000 --> 00:42:31.400
decisions that are kind of trivial made
for me was was pretty compelling, and
520
00:42:31.480 --> 00:42:37.280
so so like the lure of Dino
as a technology kind of started from there
521
00:42:37.360 --> 00:42:42.400
of like having this sense that you
know, complexity had been creeping into Node
522
00:42:42.480 --> 00:42:46.719
and the experience of using Dino it
was something where like once I used it
523
00:42:46.760 --> 00:42:50.280
once, I was like, okay, like I'll probably be a little grumpy,
524
00:42:50.360 --> 00:42:52.480
like if I have to use Node
without Dno again, because like if
525
00:42:52.480 --> 00:42:57.840
I have to configure you know,
TS configure web pack for these purposes again,
526
00:42:58.039 --> 00:43:00.920
I'll probably be a little a little
sad. Or what a minute,
527
00:43:00.960 --> 00:43:04.559
you mentioned web pack. Uh,
maybe you mentioned it before and I kind
528
00:43:04.559 --> 00:43:07.400
of missed it. But does that
mean that Dino also has a built in
529
00:43:07.440 --> 00:43:12.960
bundler? So there was there is
a was a built in bundler that was
530
00:43:13.000 --> 00:43:16.400
deprecated in uh, you know,
a previous version of Dino. It's something
531
00:43:16.400 --> 00:43:20.960
that we're kind of looking at again, but like, yes, build works
532
00:43:21.000 --> 00:43:23.599
pretty well in the Dino ecosystem,
like for that purpose, So it hasn't
533
00:43:23.639 --> 00:43:32.440
been like super high priority. But
the webpack as like a way of running
534
00:43:34.320 --> 00:43:38.440
like built like transpiling server side code
even was something that I had to contend
535
00:43:38.480 --> 00:43:43.760
with at least in my you know
projects that we're using notes, So like
536
00:43:44.079 --> 00:43:46.559
compiling like s CSS say, like
as a part of you know, those
537
00:43:46.559 --> 00:43:52.280
projects. So a lot of those
tools I find I need to use less
538
00:43:52.360 --> 00:43:58.320
in uh in Dino, which show
kind of oh go for a truck.
539
00:43:58.400 --> 00:44:00.880
Sorry, I was gonna pushed us
back to the story just a little bit.
540
00:44:01.679 --> 00:44:05.920
Yeah, So it wasn't any one
particular project. It was just kind
541
00:44:05.960 --> 00:44:12.400
of your workflow that pushed you toward
Dino. It sounds like, I guess
542
00:44:12.400 --> 00:44:15.280
my other question is, and I'm
always curious about this, is right now
543
00:44:15.320 --> 00:44:20.840
you're actually working for the organization that
gives us Dino. How did that come
544
00:44:20.880 --> 00:44:23.360
about? Was it just your involvement
in the project or was there something else?
545
00:44:23.400 --> 00:44:30.880
Did you know someone I've been sort
of around the project for some amount
546
00:44:30.920 --> 00:44:36.920
of time, but they decided they
wanted to like have a formal Devreux program
547
00:44:37.559 --> 00:44:39.960
and I actually wasn't aware of it, but somebody from the team reached out
548
00:44:39.960 --> 00:44:43.519
to me and it was like,
Hey, we're looking at doing a devre
549
00:44:43.679 --> 00:44:45.599
program. Is this something you'd be
interested in? I was like, uh,
550
00:44:45.719 --> 00:44:50.360
yeah, yeah, I totally would
be interested because I had been pretty
551
00:44:50.360 --> 00:44:54.039
stoked about the technology for a while. So it kind of came through some
552
00:44:54.079 --> 00:44:59.880
outreach from the company at the time. Okay, cool, if I'm pulling
553
00:45:00.079 --> 00:45:04.039
us back a little bit towards the
technology side. Uh, it seems that
554
00:45:04.239 --> 00:45:09.679
more and more NODE in the context
of full stack applications will be running in
555
00:45:09.760 --> 00:45:15.360
the context of some sort of meta
framework like it won't you might not be
556
00:45:15.519 --> 00:45:20.519
using node or on its own,
you might be using it with the next
557
00:45:20.559 --> 00:45:28.960
GS or an ASTRO or you know
whatever. And so my question is,
558
00:45:29.480 --> 00:45:36.800
how does Dino fit into this kind
of brave new world of meta frameworks that
559
00:45:36.960 --> 00:45:43.599
are full stack? Does it just
work out of the box, like when
560
00:45:43.639 --> 00:45:49.679
I when I install next GS,
how you know what? How does you
561
00:45:49.880 --> 00:45:57.719
know fit into that installation process?
So there's kind of a spectrum of how
562
00:45:57.800 --> 00:46:00.480
well do you know works with a
lot of the meta frameworks in the NOE
563
00:46:00.480 --> 00:46:05.519
ecosystem, but even just within if
you're just talking about like first party like
564
00:46:05.639 --> 00:46:09.679
Dino frameworks, you will probably be
using some kind of meta framework along with
565
00:46:09.800 --> 00:46:16.239
Dino. Fresh is kind of the
first party one that the Dino team maintains,
566
00:46:16.840 --> 00:46:22.480
which is sort of designed to run
on edge servers and implements like an
567
00:46:22.480 --> 00:46:28.119
island architecture similar similar to ASTRO.
And there's a lot of other frameworks I'm
568
00:46:28.159 --> 00:46:31.360
doing it in that in that way, but the assumption is that you know,
569
00:46:31.480 --> 00:46:36.440
zero JavaScript is sent to the client
by default, and we push more
570
00:46:36.480 --> 00:46:42.079
rendering to the to the server.
So certainly that's one of the options.
571
00:46:42.119 --> 00:46:45.480
Another meta framework that works really well
in just before you move on to the
572
00:46:45.719 --> 00:46:49.880
to another one. Y correct me
if I'm wrong. I think that Fresh
573
00:46:50.039 --> 00:46:52.840
is kind of built on on pre
Act, right it is. Yeah,
574
00:46:52.920 --> 00:46:58.719
So actually one of the maintainers of
pre Act, Marvin Hagemeister, is a
575
00:46:58.719 --> 00:47:02.960
member of the Dono team now and
as kind of primary maintainer of Fresh as
576
00:47:02.960 --> 00:47:08.920
well. So yeah, great,
definitely core technology there. Yeah, and
577
00:47:09.000 --> 00:47:13.320
then if for other I mean,
there's certainly other meta frameworks that you can
578
00:47:13.440 --> 00:47:16.639
use in Dino. The other like
notable one i'd point out is Hono,
579
00:47:16.800 --> 00:47:22.119
which is maintained by the cloud Flare
team. Actually is sort of like the
580
00:47:22.159 --> 00:47:28.159
spiritual successor I would say to like
Express and Sinatra from the Ruby world,
581
00:47:29.039 --> 00:47:31.920
where I've found Hono to scale up
like pretty nicely, So it can start
582
00:47:31.960 --> 00:47:37.519
from like single file web servers,
and you know, it actually scales up
583
00:47:37.559 --> 00:47:44.239
to reasonably complex use cases pretty well. So Hono and and Fresh are probably
584
00:47:44.280 --> 00:47:47.960
two of the best options that exist
just that work natively in Dino, but
585
00:47:49.000 --> 00:47:52.760
from the no ecosystem that that's like
one of the big challenges that we're trying
586
00:47:52.800 --> 00:47:57.480
to address with Dino two is getting
more of those meta frameworks to work really
587
00:47:57.519 --> 00:48:00.519
well in in Dino. Some of
the work pretty well today. So like
588
00:48:00.559 --> 00:48:05.920
if you worked a lot of the
frameworks that use VET as a build to
589
00:48:06.239 --> 00:48:09.880
in under the covers, so like
Astro would be one of them, speltcarts,
590
00:48:10.639 --> 00:48:15.800
yeah, noxt would be would be
another. Those frameworks tend to work
591
00:48:15.840 --> 00:48:21.840
pretty well in Dino because VET works
quite well for the most part in in
592
00:48:21.920 --> 00:48:27.559
Dino. So a lot of those
build steps work mostly out of the box.
593
00:48:28.400 --> 00:48:31.119
Like there's some edge cases depending on
like which parts of the ecosystem you're
594
00:48:31.119 --> 00:48:35.440
trying to leverage, there might be
plugins that may or may not work.
595
00:48:35.519 --> 00:48:39.440
But yeah, like the the node
adapter, So Astro has this concept of
596
00:48:39.480 --> 00:48:45.840
adapters which allow you know, server
side rendering in different environments like in cloud,
597
00:48:45.840 --> 00:48:49.360
fliter workers or a node or whatever
it would happen to be. And
598
00:48:50.159 --> 00:48:53.840
there is a Dino Astro adapter which
is a little bit out of repair,
599
00:48:54.559 --> 00:48:59.360
and that's largely largely my fault.
I haven't had a chance to update the
600
00:48:59.480 --> 00:49:04.119
adapter, but the Node adapter for
Astro works works great, and you can
601
00:49:04.199 --> 00:49:09.039
use that today. There's a spel
Kit adapter for Node that works great in
602
00:49:09.119 --> 00:49:15.320
Dino today. There's also like a
community maintained spell Kit adapter that is natively
603
00:49:15.400 --> 00:49:20.000
Dino that works really well. Next
is in a kind of a similar position.
604
00:49:20.119 --> 00:49:22.880
So a lot of those those types
of frameworks do work really well.
605
00:49:23.599 --> 00:49:28.639
Next JS is kind of a different
beast though, and it kind of leverages
606
00:49:28.679 --> 00:49:32.800
a lot of behavior in Node that
we have not been able to model like
607
00:49:32.920 --> 00:49:37.760
one to one in such a way
where like next is a good experience specifically,
608
00:49:37.159 --> 00:49:42.760
but that is an obsession that currently
exists on the Dino team is to
609
00:49:42.760 --> 00:49:46.320
figure out how to make a next
run really well as well. So certainly
610
00:49:46.960 --> 00:49:52.360
a goal. Yeah, that's kind
of important. I mean, not putting
611
00:49:52.360 --> 00:49:55.639
down any of the other frameworks,
but just numbers wise. Next, yes
612
00:49:55.800 --> 00:50:00.360
is more or less like as big
as all the other meta frameworks come buying,
613
00:50:00.519 --> 00:50:06.320
So so yeah, definitely not lost
on the crew here at Dino for
614
00:50:06.360 --> 00:50:12.239
sure is the necessity to have an
acceptable experience there, So I think we'll
615
00:50:12.239 --> 00:50:15.119
get there. But that that is
like a big project for us right now,
616
00:50:15.159 --> 00:50:19.760
and something that we're kind of gating
our two point zero launch on is
617
00:50:19.800 --> 00:50:25.079
like how well we're we feel that
we support those crucial metaphrameworks from note say,
618
00:50:25.079 --> 00:50:31.840
it's the next big thing, right
Dan well played, Steve well played.
619
00:50:32.320 --> 00:50:37.639
Yeah, and especially given that that
works next anyway. Yeah, and
620
00:50:37.039 --> 00:50:42.519
especially given that I work at the
company called Next Insurance that has nothing to
621
00:50:42.559 --> 00:50:47.920
do except that you actually except that
we actually do use it. Uh,
622
00:50:49.840 --> 00:50:52.360
you know. But anyway, the
time for the next question yet, I
623
00:50:52.400 --> 00:50:59.639
mean, I think we're starting we're
starting to approach the end of our show,
624
00:50:59.679 --> 00:51:01.880
and it seems like we're not really
going to be able to cover JSR
625
00:51:01.960 --> 00:51:06.440
this time, so we probably will
need to invite you over again to talk
626
00:51:06.480 --> 00:51:09.400
about it. Yeah. One thing
that I want to to kind of ask
627
00:51:09.440 --> 00:51:15.079
you about before we wrap up is
something that you kind of alluded to multiple
628
00:51:15.119 --> 00:51:19.639
times during the conversation, and that's
the edge computing story. I think there
629
00:51:19.800 --> 00:51:22.800
is, like, this is one
of your strengths, I believe, the
630
00:51:22.840 --> 00:51:28.320
ability to run on the edge.
How does that how do you differ with
631
00:51:28.480 --> 00:51:31.400
in node in that regard? Do
you differ from node? What are the
632
00:51:31.480 --> 00:51:37.079
advantages of running Dino in that scenario. What of the advantages of the edge
633
00:51:37.079 --> 00:51:40.119
in general, So go for it. Yeah, sure, I can try
634
00:51:40.159 --> 00:51:45.639
to yeah, unpack that a little
bit. So the one thing that is
635
00:51:45.039 --> 00:51:51.800
useful about how DINO works is a
lot of the core functionality and Dino is
636
00:51:51.840 --> 00:51:55.679
based on like Web standard APIs that
are available in the browser. And that
637
00:51:55.760 --> 00:52:01.480
becomes important because when you're running JavaScript
on the server on the edge, you
638
00:52:01.519 --> 00:52:07.360
are running it in a vight isolate, which you want to be able to
639
00:52:07.400 --> 00:52:09.519
sort of spin up and tear down
very quickly. And that's kind of one
640
00:52:09.559 --> 00:52:15.840
of the primary advantages of running JavaScript
on the edge is that instead of you
641
00:52:15.880 --> 00:52:19.079
know, a virtual machine that needs
to be sort of spun up and spun
642
00:52:19.199 --> 00:52:22.360
down like with a with a lambda
say, or like some or like another
643
00:52:22.400 --> 00:52:30.800
container hosting UH solution, a jabscript
environment can UH and can manage a pool
644
00:52:30.840 --> 00:52:35.519
of vight isolates similar to like a
browser tab in your in your browser,
645
00:52:36.000 --> 00:52:39.280
which are very sort of cheap and
easy to create and UH and tear down.
646
00:52:39.840 --> 00:52:45.320
So the cold start times for those
isolates can be really uh, really
647
00:52:45.440 --> 00:52:49.559
nice in a lot of scenarios.
And the fact that you know can run
648
00:52:49.599 --> 00:52:54.079
really well in a lightweight, UH
JavaScript environment like that one is one of
649
00:52:54.119 --> 00:53:00.119
the advantages that sort of makes it
work well in that scenario. So Denote
650
00:53:00.639 --> 00:53:06.440
is being used in uh sort of
edge edge functions in a few different contexts.
651
00:53:07.119 --> 00:53:12.559
So like if you use Netlify edge
functions that actually runs on Dino and
652
00:53:12.599 --> 00:53:16.000
Dino's cloud infrastructure sort of behind the
scenes. UH. For a long time,
653
00:53:16.239 --> 00:53:21.360
super Bases edge functions also ran on
our cloud infrastructure. They've since like
654
00:53:21.440 --> 00:53:25.920
taken Dino and created their own edge
infrastructure based on Dino that they're building on
655
00:53:27.039 --> 00:53:29.880
as well, which is awesome they've
done. They've been doing some really cool
656
00:53:29.880 --> 00:53:35.519
work there with the open source run
time. So yeah, so there's I
657
00:53:35.559 --> 00:53:38.679
think it's the relationship between like Dino
being able to run really well in a
658
00:53:38.719 --> 00:53:43.400
browser like environment and the fact that
you need to be able to run those
659
00:53:43.480 --> 00:53:50.559
lightweight V eight isolates on the edge
maybe makes it ideally suited for those environments.
660
00:53:52.239 --> 00:53:57.719
And then I think like the the
advantage generally of doing you know,
661
00:53:58.079 --> 00:54:02.039
processing on the server on the edge
is uh is latency. So if you
662
00:54:02.079 --> 00:54:07.639
can do compute tasks and you know
servers that are geographically close to your users,
663
00:54:08.360 --> 00:54:13.559
that's gonna result in you know,
faster round trips. There can be
664
00:54:13.599 --> 00:54:20.760
like data residency requirements that can be
satisfied potentially through where your code executes.
665
00:54:22.000 --> 00:54:27.400
There's other like types of functionality that
can be UH that is maybe optimally done
666
00:54:27.639 --> 00:54:32.039
on the edge, like whether it's
like manipulating headers for an HDP request or
667
00:54:32.199 --> 00:54:37.800
like doing image processing. There there's
scenarios in which you know, being able
668
00:54:37.840 --> 00:54:44.199
to execute that logic close to users
is is important. Or if you are
669
00:54:44.280 --> 00:54:49.800
doing UH have like an application architecture
that leans heavily on server side rendering,
670
00:54:50.360 --> 00:54:53.440
doing that server side rendering on edge
servers can be can be beneficial as well.
671
00:54:53.480 --> 00:54:58.599
So not every request to generate dynamic
HTML has to go to like a
672
00:54:58.679 --> 00:55:01.599
data center in Virginia. Yeah,
you can do that maybe all closer to
673
00:55:01.599 --> 00:55:06.320
where your users are. The one
thing that you really need to be careful
674
00:55:06.360 --> 00:55:10.400
about is the latency of your access
to the data, because if you're running
675
00:55:10.440 --> 00:55:15.679
compute on the edge but your data
is still back at the data center,
676
00:55:15.360 --> 00:55:22.840
you might actually end up hurting performance
rather than improving it because you use significant
677
00:55:22.920 --> 00:55:27.760
you may significantly increase the latency of
data access. So you really need to
678
00:55:27.920 --> 00:55:32.840
think about that aspect of your solution
or implementation. Yeah, for sure.
679
00:55:32.960 --> 00:55:38.719
I think it's you're starting to see
like more database vendors and those types of
680
00:55:38.719 --> 00:55:44.719
services popping up where they're sort of
natively designed to be access from edge servers,
681
00:55:44.960 --> 00:55:47.519
which is which is cool, but
it is certainly uh, you know,
682
00:55:47.599 --> 00:55:52.559
one of the architectural concerns that you
have to pick through. Now,
683
00:55:52.679 --> 00:55:58.400
one more question that I have is
this. So it's it's Dido dot com,
684
00:55:58.480 --> 00:56:01.719
which means that you're an actual company. You're not just an open source
685
00:56:01.880 --> 00:56:09.119
project, right, So what's how
do you plan to be like, you
686
00:56:09.159 --> 00:56:15.239
know, to make money to be
to make sure that the project survives because
687
00:56:15.280 --> 00:56:21.519
and the company doesn't go under,
Like what's what's the what's the value proposition
688
00:56:21.639 --> 00:56:25.920
in terms of you know, generating
generating funds. Yeah, so it's,
689
00:56:27.199 --> 00:56:31.559
uh, the place where we found
success so far is around like that edge
690
00:56:31.559 --> 00:56:37.159
computing infrastructure. So the one of
the paid offerings that do you know the
691
00:56:37.199 --> 00:56:43.039
company has today is something called sub
hosting, which is a way to like
692
00:56:43.079 --> 00:56:47.719
sort of take untrusted code and execute
it within like a cloud environment. So
693
00:56:47.840 --> 00:56:52.320
like I used to work at Tulio, and Tulio has this thing called Tulio
694
00:56:52.400 --> 00:56:57.199
Functions which is like you can give
Twilio a chunk of JavaScript code and it'll
695
00:56:57.280 --> 00:57:00.559
run that JavaScript code whenever you get
an incoming tech message or phone call or
696
00:57:00.559 --> 00:57:06.400
whatever. And there's actually a lot
of SaaS platforms or developer tool platforms that
697
00:57:06.599 --> 00:57:12.360
want to offer this functionality where we'll
execute some code for you when this integration
698
00:57:12.480 --> 00:57:16.360
event or this other event happens somewhere
in our system. And Dino has a
699
00:57:16.360 --> 00:57:22.039
platform for very quickly building that out
kind of based on this edge computing infrastructure
700
00:57:22.079 --> 00:57:27.719
that we created for Dino deploy,
which is a like an edge function hosting
701
00:57:27.719 --> 00:57:31.800
platform which is sort of generally available
to anyone to you know, you can
702
00:57:31.880 --> 00:57:37.000
run full web applications on it or
specifically you know, edge functions. So
703
00:57:37.519 --> 00:57:42.519
that I think, like the cloud
infrastructure is where a lot of the like
704
00:57:42.639 --> 00:57:46.039
revenue growth is going to be in
the future. But like the open source
705
00:57:46.119 --> 00:57:51.840
run time and also JSR, which
we'll talk about next time, are both
706
00:57:51.920 --> 00:57:57.320
like free and open source and will
be that way sort of indefinitely. And
707
00:57:57.360 --> 00:58:02.480
we think like those two things being
successful as open source projects will be a
708
00:58:02.920 --> 00:58:07.800
headwind for some of like the cloud
based stuff that we think will support the
709
00:58:07.840 --> 00:58:14.239
company. So just to make understand. Yeah, just to make sure that
710
00:58:14.280 --> 00:58:19.400
I understand in a sense, you're
kind of competing with cloud further, cloud
711
00:58:19.440 --> 00:58:24.880
Flare workers, like providing an alternative
to their solution. Yeah, the so
712
00:58:24.960 --> 00:58:30.039
the edge hosting infrastructure is kind of
in the similar similar space to workers.
713
00:58:30.880 --> 00:58:36.880
The sub hosting API that I talked
about for running on trusted code also is
714
00:58:36.960 --> 00:58:40.320
kind of in the same space.
Like cloud Flare has a like an enterprise
715
00:58:40.400 --> 00:58:44.800
offering in that realm. I don't
know if it's self serviced yet, but
716
00:58:44.840 --> 00:58:49.559
there's like a workers for enterprise or
workers for Platforms or something. I think
717
00:58:49.559 --> 00:58:55.000
it's called that does a similar thing. So that's probably the nearest competitive solution.
718
00:58:55.599 --> 00:58:59.239
And I think like the like Dino
and cloud Flare are kind of the
719
00:58:59.280 --> 00:59:04.360
two ways you can do edge compute
these days, like workers and deploy are
720
00:59:04.440 --> 00:59:07.800
kind of the only game in time
in town, so like versal edge functions,
721
00:59:07.800 --> 00:59:12.119
say, like us as workers under
the hood today. So yeah,
722
00:59:12.119 --> 00:59:19.079
so it is kind of similar to
that that solution cool, yeah, yeah,
723
00:59:19.199 --> 00:59:23.400
very cool. Yep. If you
could tell us here within like two
724
00:59:23.480 --> 00:59:27.679
minutes, because I do have a
hard stop at ten thirty mountain time,
725
00:59:28.519 --> 00:59:34.639
two seconds or two minutes what's coming
next in Dino. Yeah, So,
726
00:59:35.199 --> 00:59:38.800
as I kind of have alluded to, like, no compatibility is a huge
727
00:59:39.480 --> 00:59:44.639
focus for the team right now.
So increasing the amount of the note ecosystem
728
00:59:44.719 --> 00:59:52.280
that runs with no configuration within Dino
is kind of the biggest engineering goal in
729
00:59:52.320 --> 00:59:58.760
front of us for the Dino run
time itself. The other other bits that
730
00:59:59.159 --> 01:00:04.159
are coming out are you know,
continued you know, improvement of integration with
731
01:00:04.360 --> 01:00:09.880
JSR and tooling around my publishing to
the JSR registry and making JSR like work
732
01:00:09.920 --> 01:00:15.039
really well across every run time from
you know BUN to d NO to NOD
733
01:00:15.159 --> 01:00:17.920
to cloud flare, workers and browsers
and everything in between. So I think
734
01:00:17.960 --> 01:00:22.519
no compatibility and JSR are going to
be the continued uh you know focus for
735
01:00:22.599 --> 01:00:27.440
us. Awesome, all right,
well, let's go ahead and do our
736
01:00:27.440 --> 01:00:30.320
picks and then we'll wrap up.
Uh Steve, what are your picks?
737
01:00:31.199 --> 01:00:35.599
Oh, We're going to start with
the high point first, Okay, Uh,
738
01:00:36.159 --> 01:00:38.440
so real quick before I get to
the real high point, uh,
739
01:00:38.639 --> 01:00:45.840
blog posts. Interesting when I saw
on acher News today regarding the classic and
740
01:00:45.000 --> 01:00:51.599
long running debate of tabs versus spaces, and the title of the blog post
741
01:00:51.679 --> 01:00:54.719
is new data shows tabs are more
popular than spaces, but spaces users are
742
01:00:54.719 --> 01:01:02.920
happier and and so what it is
is there's a company that surveyed the Lundu
743
01:01:04.199 --> 01:01:08.320
Journal l U N d U k
E and surveyed seventy two hundred IT professionals
744
01:01:08.320 --> 01:01:14.639
and computer nerds, and they asked
all kinds of questions about what they use,
745
01:01:14.679 --> 01:01:19.280
and then tried to associate tabs users
versus spaces users with other things such
746
01:01:19.280 --> 01:01:22.719
as which text editors do they use, what os is do they use,
747
01:01:22.119 --> 01:01:28.559
what web browsers do they use?
And is there an in correlation with age
748
01:01:29.280 --> 01:01:32.639
and politics and so on and so
forth. It's really sort of entertaining.
749
01:01:35.199 --> 01:01:39.199
So I found it quite interesting.
I just put a link in our chat
750
01:01:39.440 --> 01:01:45.079
about the white Space programming language.
Are you familiar with it? Well,
751
01:01:45.079 --> 01:01:52.199
I know what like. White Space
is an actual programming language that just uses
752
01:01:52.280 --> 01:01:57.400
white space characters for programming. So
it uses all the instructions are coded as
753
01:01:57.440 --> 01:02:00.519
space is, you know, spaces, tabs, new lines, stuff like
754
01:02:00.559 --> 01:02:06.880
that. And the advantage is that
you can write your code within the file
755
01:02:07.039 --> 01:02:12.800
of some other programming languages code,
so you can have like two programs in
756
01:02:12.880 --> 01:02:19.000
the same source file and you know
it might be interesting if Dino had built
757
01:02:19.000 --> 01:02:22.519
in support for the white space programming
language. They'll get right on that,
758
01:02:22.639 --> 01:02:27.360
right, Yeah, yeah, exactly, we'll file that away as a high
759
01:02:27.400 --> 01:02:30.320
priority issue for sure. Yeah,
I'm going to guess that with if you're
760
01:02:30.320 --> 01:02:32.119
writing with white spaces, you always
have to use the dart background, right
761
01:02:35.440 --> 01:02:39.239
for sure? Right, okay,
And now for the dad jokes of the
762
01:02:39.280 --> 01:02:44.679
week. So you know, in
the past years, I've done, you
763
01:02:44.719 --> 01:02:47.519
know, a lot of interviewing of
job candidates, and I was and it's
764
01:02:47.559 --> 01:02:52.000
usually me asking the questions. But
this recent guy I was, I was
765
01:02:52.079 --> 01:02:55.159
interviewing and we were talking about money, and he said, well, what
766
01:02:55.199 --> 01:02:59.079
does a competitive salary even mean?
I said, well, it just means
767
01:02:59.079 --> 01:03:06.719
that your salaries can be against your
bills. Ye mm, now this day,
768
01:03:06.840 --> 01:03:09.320
these days, it's not it's it's
not as amusing. Let's put it
769
01:03:10.159 --> 01:03:16.400
as it was, right, the
bills are winning. Do you know that
770
01:03:16.559 --> 01:03:22.239
alligators can live up to live to
be up to seventy years old. That's
771
01:03:22.280 --> 01:03:27.880
why there's a very an increased chance
that they will see you later. All
772
01:03:27.960 --> 01:03:29.639
Right, I like that one.
That was a good one. Actually you
773
01:03:29.679 --> 01:03:32.679
later, alligator? Yeah, And
then uh, some deep thoughts for the
774
01:03:32.719 --> 01:03:38.000
day if any and anybody remembers Jack
Handy from Saturday Night Live. So what
775
01:03:38.159 --> 01:03:44.719
happens if you get scared to death
twice? M hm m hm m hm.
776
01:03:45.199 --> 01:03:50.199
Uh is the s or the C
silent in scent? Mm hmm?
777
01:03:51.159 --> 01:03:54.280
And then finally the same and similar? Are they the same or are they
778
01:03:54.320 --> 01:04:01.440
similar? It's it's like that old
saying that in theory, theory and practice
779
01:04:01.480 --> 01:04:06.880
are the same thing, but in
practice they aren't, right exactly, those
780
01:04:06.920 --> 01:04:10.960
are my picks of the week.
All right, you want to put that
781
01:04:11.119 --> 01:04:15.519
link in to that article in the
comments, and that way we can I
782
01:04:15.639 --> 01:04:17.320
will find that. Yes, all
right, Dan, what are your picks?
783
01:04:19.280 --> 01:04:23.760
Not a lot of picks? This
time? We've started watching a new
784
01:04:24.440 --> 01:04:29.559
TV series on Netflix. It's a
really new one. It's called The Gentleman.
785
01:04:30.239 --> 01:04:35.360
It's an action comedy television series created
by Guy Ritchie. And you know,
786
01:04:35.559 --> 01:04:39.400
with Guy Ritchie, it's it can
be hit or missed, but when
787
01:04:39.400 --> 01:04:43.559
it's a hit, it's a hit. So he created this kind of spin
788
01:04:43.639 --> 01:04:48.920
off from his ninth from his twenty
nineteen film that had the same name,
789
01:04:49.639 --> 01:04:56.679
So it's kind of the same sort
of settings and characters, and so far
790
01:04:56.760 --> 01:05:00.559
we're enjoying it quite a lot too. We really only watch on the one,
791
01:05:00.719 --> 01:05:03.239
the first episode, but so far, so good. Uh. It's
792
01:05:03.440 --> 01:05:09.719
like this uh, this guy that
turns out that he's a duke. He
793
01:05:09.840 --> 01:05:15.880
inherited the title and the state from
his dad, and it turns out that
794
01:05:15.599 --> 01:05:20.280
it's actually the state that his dad
actually rented out the state to the mob
795
01:05:20.800 --> 01:05:27.440
to to pack weed there that they
have like this huge weed factory on there,
796
01:05:27.559 --> 01:05:31.559
and he now has to deal with
all these Mob characters and whatnot.
797
01:05:31.719 --> 01:05:36.519
And you know, it's and you
know, if you've seen Guy Guy Richie's
798
01:05:36.599 --> 01:05:41.559
movies, you know, you know
kind of the setting and how the characters,
799
01:05:42.039 --> 01:05:45.360
the sort of characters that you encounter
there, and you know, so
800
01:05:45.519 --> 01:05:48.360
it's so far, so good.
We are really enjoying it so far.
801
01:05:50.239 --> 01:05:55.599
And I guess, oh, one
more thing is we are I'm kind of
802
01:05:55.719 --> 01:06:00.280
clearing up my my own like personal
library yet at home, like actual books.
803
01:06:00.840 --> 01:06:04.320
Like we've gone to the point that
we had like three rows of books
804
01:06:04.400 --> 01:06:06.920
in the libraries, one behind the
other, and it was kind of,
805
01:06:08.039 --> 01:06:12.519
you know, things are starting to
fall off the shelves. So I'm really
806
01:06:12.599 --> 01:06:16.679
getting rid of various books that I
don't need anymore. And it's interesting to
807
01:06:16.800 --> 01:06:20.079
go, like to go through the
books and decide what which ones you want
808
01:06:20.119 --> 01:06:26.320
to keep in which one you know
you'll give away to a library or whatever.
809
01:06:27.239 --> 01:06:30.960
And I'm thinking of maybe, like
I think, like a few years
810
01:06:31.079 --> 01:06:35.760
back, I did one of some
of my picks, who are about these
811
01:06:35.960 --> 01:06:43.639
old science fiction and fantasy books that
people don't remember anymore. Some of them
812
01:06:43.679 --> 01:06:47.119
are really excellent. Now that I'm
seeing those books again, maybe I'll revisit
813
01:06:47.239 --> 01:06:51.039
that as well. I'm just not
prepared yet. So if people, if
814
01:06:51.239 --> 01:06:58.639
if you guys or listeners are interested
in some excellent, you know, sci
815
01:06:58.760 --> 01:07:01.880
fi books or fantasy books that you
probably haven't heard of before, then let
816
01:07:01.960 --> 01:07:05.800
me know and I'll do that.
And those are my picks for today.
817
01:07:08.360 --> 01:07:11.360
Awesome, all right, I'm gonna
jump in with picks. Now. Y'all
818
01:07:11.440 --> 01:07:15.039
know that I do board games as
part of my picks, so I'll start
819
01:07:15.079 --> 01:07:17.199
out with that. A couple of
weeks ago, I went to a board
820
01:07:17.239 --> 01:07:21.960
game convention with a friend of mine
and we played a game called Apery.
821
01:07:24.159 --> 01:07:28.320
Now, if you're familiar with the
term apiary, it is about bees.
822
01:07:29.199 --> 01:07:31.159
Now, these aren't just any bees. These are space bees, which is
823
01:07:31.320 --> 01:07:38.400
kind of fun, and so the
space bees are out there trying to build
824
01:07:38.480 --> 01:07:43.960
and explore, and so what you
wind up doing is you're building around the
825
01:07:44.039 --> 01:07:48.760
space that your spaceship is on to
be able to do more stuff. Now,
826
01:07:50.599 --> 01:07:55.719
this has a board game weight of
two point ninety six, so it's
827
01:07:55.760 --> 01:07:59.760
a little bit on the complicated end
of games. It was a lot of
828
01:07:59.760 --> 01:08:03.800
fun, and there were some things
that I really liked about it. One
829
01:08:03.840 --> 01:08:08.599
of them is is it kind of
has that worker placement element that you see
830
01:08:08.599 --> 01:08:11.280
in a lot of other games where
you have the little people that you put
831
01:08:11.320 --> 01:08:15.560
out, except this one is actually
a bee, and whenever you bring the
832
01:08:16.000 --> 01:08:21.079
bee worker back, it actually increases
in power, and then once it gets
833
01:08:21.119 --> 01:08:25.840
to four power, when you bring
it back, it hibernates and goes back
834
01:08:25.880 --> 01:08:30.239
to one power. And so there's
a mechanic where you're playing with putting the
835
01:08:30.319 --> 01:08:34.000
bees out, and only level four
bees can do specific work, and so
836
01:08:34.840 --> 01:08:41.279
you're kind of balancing between building up
your ship and the capabilities and bonuses you
837
01:08:41.359 --> 01:08:46.199
get from that and getting the bees
back so that you can do other things.
838
01:08:47.199 --> 01:08:51.800
You can also bump other bees off
of spaces which again sends them back
839
01:08:51.840 --> 01:08:56.439
to your hive and you know,
levels them up, and so you're you're
840
01:08:56.520 --> 01:08:59.680
trying to weigh out how much advantage
you give to other players. When you
841
01:08:59.760 --> 01:09:01.600
do that, it's a lot of
fun, a lot of a lot of
842
01:09:01.680 --> 01:09:06.920
fun. And you you build out
the different spaces with different types of hex
843
01:09:08.199 --> 01:09:13.640
squares or hex spaces, which also
makes sense it's a B game. So
844
01:09:13.760 --> 01:09:17.680
yeah, so I'm gonna pick Apary. It came out last year. It
845
01:09:17.800 --> 01:09:21.199
was one of the hottest games.
It was one of the hardest games to
846
01:09:21.359 --> 01:09:29.760
get on and play at the at
the Board Game Convention because they had uh
847
01:09:30.479 --> 01:09:32.239
was it six I think it was
eight. They had eight hot games you
848
01:09:32.279 --> 01:09:35.720
could go try out and so and
this was one of them, and it
849
01:09:35.880 --> 01:09:39.600
was one of the harder games to
get on. Uh. The other one
850
01:09:39.720 --> 01:09:44.319
was The White Castle, and I'll
probably pick that next week. But yeah,
851
01:09:44.359 --> 01:09:46.159
I really really enjoyed it. Challengers
was another one of those games that
852
01:09:46.199 --> 01:09:50.880
I picked last time. So anyway, APR is my board game pick.
853
01:09:54.600 --> 01:09:58.520
I also and this is a pick
that I may see if I can get
854
01:09:58.600 --> 01:10:02.520
somebody on the podcasts to talk about. But I found that I needed to
855
01:10:02.600 --> 01:10:09.960
automate some stuff off of a website, essentially just to give a little bit
856
01:10:10.000 --> 01:10:14.640
of context. Speaker offered us a
deal if we moved our all of our
857
01:10:15.359 --> 01:10:18.239
podcasts over there. But the problem
is is that when when they imported the
858
01:10:19.520 --> 01:10:27.119
RSS feed, what wound up happening
was they they set up their own pages
859
01:10:27.159 --> 01:10:30.600
for each of our episodes, and
then instead of leaving the link to our
860
01:10:30.880 --> 01:10:33.239
website, they linked to theirs.
And I told them that that was a
861
01:10:33.359 --> 01:10:35.560
no go, right. I was
like, look, it has to link
862
01:10:35.600 --> 01:10:40.119
to our website or nothing. And
so I still kind of want to move
863
01:10:40.159 --> 01:10:44.600
over because they have a lot better
tools for putting the podcast sponsorships in,
864
01:10:44.760 --> 01:10:46.600
and you know, they have a
lot better number tools, and I can
865
01:10:46.680 --> 01:10:51.399
add all of the all of my
co hosts on all the shows as collaborators
866
01:10:51.439 --> 01:10:54.840
on the podcast so they can go
look up the numbers on their own and
867
01:10:54.920 --> 01:10:59.159
things like that. So there are
definite payoffs for this. But I need
868
01:10:59.239 --> 01:11:03.600
to fix that one thing. And
so I tried using Mechanized because I mostly
869
01:11:03.680 --> 01:11:10.640
work in Ruby. But the problem
is is that their page is client side
870
01:11:10.640 --> 01:11:14.880
rendered and Mechanized doesn't plain ice with
those, so it's using react or something.
871
01:11:14.920 --> 01:11:18.600
I didn't really look too hard to
figure that out, but Puppeteer in
872
01:11:18.880 --> 01:11:25.119
JavaScript does, and so I've been
fiddling with that a bit and figuring out
873
01:11:25.199 --> 01:11:30.960
how to Basically, I need it
to download the RSS feed and then which
874
01:11:31.039 --> 01:11:36.199
is just an XML file right,
have it parse out the location and then
875
01:11:36.880 --> 01:11:43.399
navigate the website because they don't have
an API to stick that URL in.
876
01:11:43.840 --> 01:11:45.560
And if I get that figured out, then I can migrate the shows over,
877
01:11:46.159 --> 01:11:49.520
so unless they find me a solution
before then. But anyway, so
878
01:11:49.520 --> 01:11:54.720
I'm gonna pick Puppeteers. Pretty cool, Kevin, what are your picks?
879
01:11:55.680 --> 01:12:00.000
Nice? So from the category of
Netflix shows, I've been watching A House
880
01:12:00.039 --> 01:12:06.600
of Ninja's recently, which is about
a family of ninjas who kind of gave
881
01:12:06.720 --> 01:12:12.319
up their shnobi lifestyle, are trying
to live as a normal family in Japan,
882
01:12:12.479 --> 01:12:15.239
but end up getting kind of sucked
back into the world of you know,
883
01:12:15.520 --> 01:12:20.600
Ninja intrigue, which it's an important
show with subtitles. It is dubbed,
884
01:12:20.640 --> 01:12:25.119
but the dove is pretty bad,
so I would recommend going. I
885
01:12:25.279 --> 01:12:29.680
never watched the dubbed things. If
I can help it. No, Yeah,
886
01:12:29.800 --> 01:12:33.079
the dove is not great, but
the dad jokes from earlier reminded me
887
01:12:33.359 --> 01:12:38.319
of a story about a king once
who loved grass. He loved the smell
888
01:12:38.359 --> 01:12:42.439
of grass, everything about it.
So he summoned his royal builder to his
889
01:12:42.680 --> 01:12:45.119
castle and said, I want you
to rebuild my castle in grass. And
890
01:12:45.239 --> 01:12:48.279
the builder was very skeptical, but
she said, okay, I'll rebuild your
891
01:12:48.399 --> 01:12:55.119
castle in grass. So she created
this massive castle all made out of grass.
892
01:12:55.159 --> 01:12:58.800
The king loved it, and you
know, she stored all of the
893
01:12:58.840 --> 01:13:02.159
old stuff from the prior castle,
like up above the main throne room.
894
01:13:02.760 --> 01:13:06.119
But the first day that the king
was holding court in his grass castle,
895
01:13:08.279 --> 01:13:13.000
he was actually crushed by his previous
throne, which fell through the grass ceiling
896
01:13:13.079 --> 01:13:16.039
because grass is not very good at
bearing weight. And the moral of the
897
01:13:16.079 --> 01:13:25.560
story, of course, is that
people in grasshouses shouldn't stow thrones. Oh
898
01:13:25.840 --> 01:13:29.600
OK, so good, thank you. I always love it when the guests
899
01:13:29.640 --> 01:13:32.720
bring the jokes. So good.
Yeah, all right, I'm sure people
900
01:13:32.720 --> 01:13:36.680
want to great, great, grateful, But yeah, people want to connect
901
01:13:36.720 --> 01:13:40.880
with you. Where do they find
you on the Internet. I'm at Kevin
902
01:13:40.880 --> 01:13:45.199
winnery on Twitter or just k winnery
on GitHub. Would love it if you
903
01:13:45.239 --> 01:13:49.560
would hang out on the Dino discord
as well. It's discord dot gg slash
904
01:13:49.640 --> 01:13:53.920
Dino, so feel free to join
us there. But yeah, those are
905
01:13:53.960 --> 01:13:59.000
probably the big ones. Awesome,
all right, we're up here, so
906
01:13:59.159 --> 01:14:02.279
we really just need to bring Kevin
over again to talk about JSR. That's
907
01:14:02.520 --> 01:14:05.880
uh I think so. Yeah,
I would love to chat about that more.
908
01:14:06.560 --> 01:14:10.479
Yeah, please do it, all
right, folks, still, next
909
01:14:10.520 --> 01:14:14.720
time, max out m hm