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