Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Become a patron. For just five dollars a month, you
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month will get
you that and a special dot NetRocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com.
Speaker 2: Hey, Carl and Richard here with your twenty twenty four
NDC schedule.
Speaker 1: We'll be at as many NDC conferences as possible this year,
and you should consider attending no matter what. The Copenhagen
Developers Festival happens August twenty sixth through the thirtieth. Tickets
at Cphdevfest dot com.
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth, Tickets at
Ndcporto dot com.
Speaker 3: We'll see you there, we hope.
Speaker 1: Hey, welcome back to dot net Rocks episode nineteen eighteen.
Where are we in history today? Richard?
Speaker 2: And of World War One?
Speaker 1: End of World War One? Wasn't that fun?
Speaker 2: By beginning of the H one N one pandemic flu Yes,
that will kill people for the next four years and
it's still around today.
Speaker 3: Yay.
Speaker 1: I'm Carl Franklin. That's, of course Richard Campbell, and we're
here for episode nineteen eighteen with the guy who built node,
Ryan Dobb. We'll talk to him in a minute, but first,
it's better no framework. Awesome world of music.
Speaker 2: Oh man, what do you got?
Speaker 4: So?
Speaker 1: I looked for trending repos on GitHub and I found
this amazing app. I haven't used it yet, but it
looks amazing. It's still in alpha. It's called Follow.
Speaker 2: Oh yeah.
Speaker 1: And remember RSS readers, right, those were all the rage when.
Speaker 2: Blogs the good old days.
Speaker 1: Yeah, think of This is an RSS reader on steroids.
So it's called Follow. It's all about allowing you to
follow your favorite websites, blogs, social media accounts, podcasts, and
notifications in one place. And so it also has AI
to assist in operations, provides AI reports to highlight key
information for your subscriptions. Personal AI knowledge base built from
your subscription uses blockchain as an incentive mechanism for active
users and outstanding creators. But more about that. You know,
check out some of these pictures right, so you can
follow your favorite sites like they have a picture of you,
following the verge of Twitter and Mastodon and all the socials.
What is it, NASA astronomy pictures, so videos from.
Speaker 2: YouTube, anything you might subscribe to.
Speaker 1: Anything you might subscribe to.
Speaker 2: Yeah, that's interesting.
Speaker 1: And so it's it's kind of like that. It's kind
of the old RSS browser on steroids.
Speaker 2: Yeah. Wow, it's good to see you know. It's not
like we stopped needing it. It's just that when they
shut down Google Reader, we're all heartbroken and we haven't
gotten over it.
Speaker 1: Right, So this is a and I love this. Remember
trillion You used.
Speaker 2: Trillion right, yes, I used trillion back.
Speaker 4: Yeah.
Speaker 1: So trillion was like an instant messenger that went everywhere
and it was one.
Speaker 2: Just try to consol it all the clients, right, I
mean these days I have WhatsApp open and Signal open
and Messenger open and exactly Telegram and like save.
Speaker 1: Me yeah exactly. And there's no there's no real way
to do that now because everybody wants to use their
app so they can get your information and not their competitors.
So this is for Windows, mac Os, Linux and the browser.
There's going to be Android and iOS versions coming soon.
Speaker 2: Cool.
Speaker 1: So that's it. Nineteen eighteen dot popt me, that's pwop
dot e and that'll bring you right to there, or
you could just look for GitHub dot com, slash rss next,
slash follow. That's what I got. Richard, who's talking to.
Speaker 2: Us, love it. So you know, it was digging around
a bit because we'd done talked about node and other
tech a few times, and I ran across a show
for a while back. This is from show twelve eighteen,
so seven hundred shows ago. Wow. That would be November
of twenty fifteen when we talked to Paul Mooney about
micro service design, which is hilarious considering where we are
right now with the conversations this past year about modular
monoliths and that whole mindset, and so it was really
a pleasure to sort of dig back into that. Go right, yeah,
look at all these things we used to believe. And
one of the comments in there is from Ryan lippback again,
this is from a few years ago. He said, I
love the show. It's a topic very near and dear
to my heart. Is I'm me Deep Doo, a two
plus year project that's completely changing the landscape of application
development at my company. I think one of the really
important concepts of Hall hit On was the idea of
starting with something small and low risk. We have been
taking a suite of applications that are all monolithic in
nature and doing variations of the same thing, and are
starting to find the commonalities between them, extracting that into
their own services, and then to make that available. The
idea of being that in time we have replicated up
of this functionality to start sun setting some or all
of the legacy platform. Oh Man, Ryan, I hope you
tell us how this went eight years later, because that
that is the true keyotesque, like jousting at the windmill.
I found the debate about Jason schema interesting. It is
something we've recently started using. The application development and environment
is heavily dot net based until recently, we are adapting
to no JS and possibly go eight years ago. Until recently,
we've shared our message contracts as new get packages, which
makes total sense if you're in the dot net world.
This is problematic as soon as you started venturing into
other languages. Jason scheme is a way to provide us
to offer language agnostigs message contracts that we shared across
the applications written in different languages. Because there's lots of
other complaints around Jason schema, like you can drive yourself
crazy with this stuff, but platform agnostic, that's not something
you're gonna argue with. And make no mistake, I am
still in regular therapy for the lasting trauma I experience
using with soap and wizdles. But I think Jason's schema
can be used to divine a contract then, and it
does provide value. Thanks and keep up all the great stuff.
And that's from runnew ws Star. Oh good, yes, yeah,
but I just appreciate how relevant this entire conversation is
eight years later, the way we're building software right now,
and all of the same battles, and it just reminded
me like it's not that everything new is old is
old or everything old is new again, but it's like
we're still just trying to make software and trying to
get stuff done, and we've been doing that the whole time.
And I went read jason schema again because I haven't
touched in ages, and I'm going to include the show link.
Just this was thoughtful and useful, and it's interesting to
think about the newer ways graft QL and so forth
that we've gone to from there. Yeah, this lots to
be said here, So Ryan, thank you so much for
your comment, and a copy of music Cobi is on
its way to you. And if you'd like a copy
of music Koby, write a comment on the website at
dot NetRocks dot com or on the facebooks. We publish
every show there and if you comment there and I
read on the show, we'll send you copy music go by.
Speaker 1: I just noticed somebody bought the Flak collection of music
to code by twenty one I Go twenty one twenty
five minute tracks design to help you stay in focus
while you're writing code or do anything.
Speaker 2: And and Flak being the lossless format. Yep, it's like
wave because you didn't want to go Aggvorbis. What's up
with you?
Speaker 1: Well, yeah, Flak is Wave quality but half the size,
so it's perfect for downloading. All right.
Speaker 2: I'm perfectly happy with my MP three's honestly.
Speaker 3: Yeah.
Speaker 1: You know that's the joke, right, is that all these
audio files are all about their great microphones and all
their processes for recording and editing and stuff. And in
the end, you're making music for people who are going
to listen on earbuds. No offense, Ryan, but you know
you're going to listen to MP three's on earbuds. Yeah,
and they really don't care.
Speaker 2: You know, it doesn't matter most of the time, it
doesn't matter. Come on, right, I got a good sound
SYSTM to the car, but not that good.
Speaker 1: There still are a few audio files who have their
speakers set up and you know, their their CD quality
stuff and whatever's all right, enough of that, Okay, let's
bring on Ryan Doll. So Ryan Doll is the creator
of no JS and it's modern successor Dino. That's d
O Is it Dino or Deno Dino? Well, first of all,
on behalf of all developers everywhere, I'd like to thank
you for inventing no JS, because you really changed the environment.
You changed the whole scene of back end development from
well especially in our case, right, we were using Internet
Information Server for most of this stuff. And as Richard
likes to say, it's a Swiss army knife with all
the tools out and you have to play whack a
mole to patch it up with the stuff that you
don't want. Whereas no JS comes along and says, hey,
this is just does one thing. It does it really well.
Speaker 2: Well, be clear, it starts out doing nothing. You have
to tell it to be allowed to do anything. Yeah,
but that's good. You take out one blade at the time,
only the ones you need.
Speaker 1: And the influence that no js had throughout the industry
was undeniable. So thank you from all of us to you.
Speaker 4: Yeah. Thanks, I'm continually surprised that notice as big as
it is. It's Yeah, I'm very happy to have kind
of stumbled upon the right idea that that servers can
be programmed very similarly to client site JavaScript. You know,
you get a non blocking servers are structured in callbacks
as our kind of websites. You know, a button has
a click handler, a website has an on request web
server has an on request handler. And you know, putting
those those two ideas together turned out to work really well.
And I think in combination with the fact that JavaScript
is far and away the most popular language in the
world in some ways the default programming language. Yeah, kind
of us.
Speaker 2: Has what was a line Handsoman used, I mean maybe
he was quoting someone else. It's like, it's the assembly
language of the Internet.
Speaker 1: Yeah that was cancer man.
Speaker 4: Yeah, it's it's the it's the English for programming languages,
right right, It's what everybody speaks.
Speaker 2: Although you did seem to hit the perfect moment like
two thousand and two thousand and nine, where the idea
that JavaScript was a standalone language was still a bit novel.
It was a scripting language or browsers, and suddenly it's like, wait,
run on a server, what's that about?
Speaker 4: Yeah?
Speaker 2: But it was also at the time when you know
the V eight engine, the Gecko uh, and what the
heck was the Microsoft one? But they were all started
dueling each other for features and the run up to
HTML five, like the acceller, the evolution of JavaScript detonated
right about that.
Speaker 4: Yeah, Yeah, I mean I think I was very much
lucky to be playing with the right stuff at the
right time, right. I think if it wasn't me, somebody
somebody else would have would have kind of put put
two and two together.
Speaker 1: So we noticed that after three years you kind of
walked away from Node and started your own things. So
what tell us the story of that?
Speaker 4: So Node, uh was you know after after a couple
of years, was was you know, very clearly on a
good trajectory. It was, uh, you know, very early for
I think the large audience of people, but you know,
for for kind of the inner circle of development, like
it was very clear that we were that we had
like you know, hit hit on the right model. I
had made a business arrangement with my employer joined to
sell Node to them whatever that means for a for
ant licensed project, but transfer them the trademark, you know,
let them run the website, you know, basically allow them
to be kind of the official the official sponsor of
the project. And yeah, given those those two things, I mean,
the project was was kind of well structured, there was
a bunch of contributors, things were moving along. I had
been paid. You know, I'm not the sort of I
like starting things. I like working on new stuff, and kind.
Speaker 1: Of I kind of figured that about you.
Speaker 4: Maintaining stuff indefinitely is not necessarily the most exciting thing.
So yeah, I handed over the rains to Isaac Schluter
and stepped back from the project. And these days Node
is managed by a nonprofit foundation and there's many contributors
and you know, different companies kind of pay money to
to have engineers working on it. So you know, despite
despite kind of making this business arrangement back in back
in the early twenty tens, uh, you know, noe is
is still a kind of public domain software, and well,
used and liked around the world.
Speaker 1: And is still a critical piece of business infrastructure. I
mean it is critical.
Speaker 4: I think every website uses node. That's that's not really
a stretch riverside the thing we're on right now Google
dot Com. Literally every website maybe note is not serving
Google notice certainly not serving Google dot Com. But somewhere
in the process of creating that CSS or that HTML,
the build process of doing stuff, it's inevitable that. I mean,
it's it's the canonical run time for JavaScript outside of
the browser, and so is involved in all sorts of
front ends tooling.
Speaker 2: It's always good to go poke at the GitHub repository
for a project, say how healthy is this? And I
look down as like, oh, they pushed to build an
hour ago. Yeah. No, I think it's busy.
Speaker 4: I think it's going on all websites. It's not a stretch.
Speaker 2: Yeah, and all the time. And I mean, I don't
know how you feel about JavaScript these days? Is it
Do you feel like it's stabler? The rate of changing
it to me doesn't seem as extreme as it used
to be.
Speaker 4: Like the language spec itself. You mean it's moving. I mean,
that is what is so exciting about the Web and
JavaScript is that there's just so much attention and energy
being poured into it. You know, the spec is pretty
stable these days, you know, since since ekmascript modules were
introduced in twenty fifteen. You know, there's not like super
huge radical changes, but things are changing all the time.
You know, the temporal API and new new kind of
dates manipulation API for example, is becoming state now. It
still continues to evolve because there is such a you know,
it's so deeply embedded in human infrastructure that there's just
many thousands and thousands of people like trying to improve
this this kind of pretty crappy language, like to be honest,
like I don't necessarily love JavaScript, It's just where we
all are. And I think that's why that's why I
find it interesting to work in.
Speaker 1: That accidental success kind of like Herman's Hermits.
Speaker 2: Darn it, Brendan, you should have thought further ahead. Is
that thirty years ago? Now? Good lord?
Speaker 1: Yeah? And wasn't it written in a weekend in a
hotel room or something.
Speaker 2: Like that when it was oak? So you hand over
the range of twenty twelve. We know Dino appears in
twenty eighteen, So what were those six years, like were
you wandering the desert?
Speaker 4: I went to work for Google for a time. I
was unemployed for a time, just working on random projects,
you know, trying to trying to create create a new
app as I still still kind of want to. Uh.
I have a Pinterest, Pinterest clone that are you know,
better version of Pinterest, the social social app that I've
been working on.
Speaker 1: Can you follow for that.
Speaker 4: It's just to that someday. But yeah, just just just
kind of working on stuff, which is kind of my
preferred mode of operation. Do. Dino was one of one
of those mini projects that I've been working on but
kind of achieved a lot of attention and I'm I'm
still working on it now, trying trying to uh see
it through.
Speaker 2: I remember the JAS comp where you did the ten
things I regret about no JS, like heck of a
way to introduce some new ideas.
Speaker 4: Yeah, and those I think some of those principles are
are not around in Dino anymore. We're just releasing Dino
two here this month. And uh, you know, for example,
complaining very much about package Jason and NPM modules and
the original demos of Dino were very simple without any
support for NPM. We walked that back and had to
be pretty pragmatic about stuff because you just realize that
at some point that gravity people, Yeah, people need to
pull in whatever like the a WUS SDK or g
r PC, and there's just no way that you're going
to rewrite like the a WUS s DK and uh yeah,
having having kind of backwards compative, I think the just
some gravity to to the to the NPM ecosystem. But nevertheless,
Dino remains uh dedicated to leveling up JavaScript and I
for one believe that this language is not going to
go away next year or two years from now, or
you know, maybe maybe not ever, and so I think
there's really a case to be made for building solid
foundations for for this language.
Speaker 1: One thing I notice is that it supports web assembly.
Speaker 4: Yeah, absolutely, I mean, you know, do you know, like
Node is built on v eight from Chrome, and you know,
you can kind of think of Dino and Node as
like different Linux distributions, Like you know, they both both
both use the same kernel, but they have kind of
a different code around it. So yeah, A v A
has fantastic you know, va is is the best javascripts
VM in the world, and of course has all the
cool features like LASM.
Speaker 2: Can you talk to us about the role of typescript
in do you know just you know is thinking about
something more adjacent to the Microsoft community. It's great to
see it there.
Speaker 4: Yeah, I think types so a lot of people think
of typescript as like a separate language from JavaScript. I
think of it as like the evolution of JavaScript. This
is where JavaScript is going, right, It's it's very it
is JavaScript with types, and it's become clear over the
last i don't know eight years or so that like
typescript is the canonical syntax for adding types to JavaScript.
We have supported typescript in Dino from the outset.
Speaker 1: Yeah.
Speaker 4: I guess it should also be said that, you know,
if you look at the you know, amount of code
on get out for example, JavaScript of course is number one,
Python is number two, typescript is number three, so you know,
in some ways, like JavaScript has both the number one
and number three spots. So I think that future versions
of the javascripts back will actually have some version of type,
like I feel like it will be standard ees inspect
out at some point in there's there's proposals in the
works to have types as comments added to the spec
so that browsers can actually understand Typescript directly and just
kind of strip out the types. Don't do it, you know,
they wouldn't do any type checking, but they would they
could strip it out and get the JavaScript out pretty quickly.
Speaker 1: We should be clear right now for those who don't
know that Typescript isn't a language that runs. It's a
language that creates JavaScript that runs.
Speaker 4: That's right.
Speaker 1: So it isn't a replacement for JavaScript. It's a JavaScript generator.
So I think what you're talking about now is adding
Typescript features to JavaScript acmascript, right that.
Speaker 3: Sort of do what typescript does.
Speaker 1: Is that what you're getting at, Yeah.
Speaker 4: There's kind of you can think of it as there's
two modes for Typescript. There is. So there's one compiler
pass that's super easy where you just strip out all
the types and what's left is JavaScript, right, and you
can do that. You can implement this sort of thing
like trivially. Then there's the type checking where it says, oh,
this function, you know needs a string argument. Let's go
make sure that the variable that you're passing to it
is actually a string and give you an error if
it's not. The type checking algorithm is wildly complicated and
like not something that you could re implement. Dino actually
does does both of these things. What I'm talking about
adding to the JavaScript spec would be type stripping. That's
the trivial operation. Perhaps in the future Chrome you could
like use typescript directly in your HTML, and Chrome could
understand that by like stripping out the types and executing
the JavaScript. But reimplyment, Yeah, the type checking is is
something that you would do in CI, not not like
at run time.
Speaker 2: Yeah, there's no reason to do it at the browser level.
It should be done at the push basically. Yeah. Yeah, now,
and it's any're right. The folks that write that kind
of code to do type validation like that, they're different
kind of humans, Like.
Speaker 1: That's that's an, that's anders Land.
Speaker 2: Yeah, it's anders Land and Luke Hoban and those guys
like just crazy smart. But also it's almost like they're
sacrificed a part of their brain to think in compiler passes,
Like that's not a small thing to have to think
that way.
Speaker 4: Yeah, yeah, and I mean the people who write V
eight for for that matter. I mean also also, yeah,
compiler people, it's a different breeder programmer yep.
Speaker 2: Right, And strangely enough, it's like it's the thing they
want to do too, Like you can't plug them into
other projects either, they will go find another compiler to
work on, like that's what they look it's a specialization.
Speaker 4: Yeah.
Speaker 2: Well, and you seem to have a pattern too, Ryan,
because you keep building tools for us to make more
reliable websites.
Speaker 4: Yeah, I would not. I am definitely not a compiler person,
even though you know I interact with the v A
VM quite heavily or with the Typescript compiler. I use
those as tools. I would consider myself a server person,
like right, I know how to write servers and kind
of use those programming languages to do this, like I
IO juggling, how do you how do you juggle a
thousand web socket connections in the most optimal way? And
you know, my my mantra or you know, goal I
guess is to allow people to do that more easily
because in the past, you know, pre node, it was
it was a specialized skill to be able to to say,
have a have a multiplayer web server that had a
bunch of ongoing connections where everybody, you know, write a
chat server, I r C server or something like that,
and being able to open that up is kind of fun.
Speaker 1: So when you started, note at least were you using
web sockets or was this all just HDDP sockets.
Speaker 4: Yeah, websitits did not exist.
Speaker 1: Yeah, web sockets didn't exist.
Speaker 2: Yeah, but long.
Speaker 4: Long pulling existed, so you could you could you know,
have an open h GP require that kind of streamed
out responses. Yeah right, yeah, transferring coding streams. You can
just send send more and more chunks, chunks down to
the down to the browser mm hm, and up in
the other direction as well. You can just make a
make a request and keep appending to the body.
Speaker 1: I did not claiming anything close to what you did,
but I spent a lot of time back then before
node really working on socket based servers that juggled multiple
clients and the problems with that, especially scaling and especially
dealing with net garbage collection. Sometimes the sockets would get
moved around and so you had to pin them in memory.
Like just a whole bunch of plumbing that nobody even
thinks about anymore. You know, that's hard stuff.
Speaker 4: Yeah, I think to a large extent like this is
alleviated but I think, you know, doing this at larger
scales is still kind of open questions that people are
working on. So if you know, if you have a
single server, you know, single instance server, you know, maybe
you can handle a thousand connections at once or so,
but what what do you do when you have a
million connections? Right that? Like, how do you structure that?
How do you do this like in a serverless way?
Because you know, frankly, I'm so bullish that serverless is
kind of the future of cloud. You know, how do
how do you do this at the edge? How do
you like there's kind of you know, we've kind of
moved on to to like larger scale problems, and those
are not worked out yet.
Speaker 1: Definitively, I'm interested to hear what you think about signal R.
I'll tell you my opinions of it. I think it's
really good for some things. But the thing that it's missing,
and it becomes quite obvious when you use it, is
any kind of any kind of cash, you know, And
so if your client is not connected, while when the
server sends you something, you miss it, it's gone, right,
And I guess that's why messaging and all those things
are they are the way they are is because hey,
I might go down and I might come back and
I want to get all my messages.
Speaker 4: I have zero experience with dot net.
Speaker 1: Okay, signal artisan just dot net. It's a JavaScript as well,
so yeah, but it's an implementation of web sockets, right
all right, Well, anyway we can move on from that.
But it's just, uh, you know something that I was
curious about.
Speaker 2: Yeah, I mean, I'm always jumpy about direct connections between
a client and a server for longer than that's absolutely necessary,
like m but I, you know, cut my chops on
scaling where get in get out, like maybe yeah, turn
the resources quickly as possible. As soon as you're doing
anyone to run relationships like that, you're going to run
out of resources pretty fast. That being said that real
time stuff's cool, like they they continue the animated dashboard,
that kind of thing. It's just as long as you
got the user count under control, you're fine.
Speaker 3: Mm hmm.
Speaker 2: It's you know, what's the problem space you're working And
I think it's one of the challenges with with web
in general is there's so many things you can do
with it. Thinking about any one pattern, you're probably wrong.
Speaker 4: I think that's that's a truism. Yeah, it's exciting as well.
I mean you can can do kind of anything with it,
so everybody can be very creative.
Speaker 2: Yeah, just an experiment, like you go down different paths.
The problem is to applying a pattern suitiment suited to
a high scaling technique to a highly interative technique and
now you're fighting with it or going highly interactive on
something needs to scale and so on.
Speaker 1: Sounds like we're opening up the airing of grievances for
web technology here. Who wants to start?
Speaker 2: Why don't we take the break first and we can
do the second half as grievances.
Speaker 1: That sounds good. All right, we'll be right back after
these very important messages. Do you have a complex dot
net monolith you'd like to factor to a micro services architecture?
The micro Service Extractor for dot Net tool visualizes your
app and helps progressively extract code into micro services. Learn
more at aws dot Amazon dot com, slash modernize, and
we're back. It's dot Netrocksom, Carl Franklin, It's Richard Campbell. Hey,
and that's our friend Ryan Dahl and the inventor of
no JS. And just a reminder If you don't want
to hear these ads, you can sign up for a
Patreon five bucks a month. I'll get you an ad
free RSS feed that you could probably use with follow.
I don't know. I'm just fascinated, totally. I'm totally fascinating.
I downloaded it. After this show, I'm going to run it.
I'm going to see what it is. Anyway, we're talking
about the airing of grievances of web technologies, which is
a topic I suggested we don't have to go down
this rope, but I'll start that. One of the things
I don't like about modern web applications is you know,
your your site is half rendered, and then you see
a button that's available, and you go to click on it,
and just before you click, boom, it moves over and
another button you clicked on that you didn't intend to
click on, which is going to call the fire department
or something. Right, And these aren't necessarily things that are
bad that are built into the web that you must
always have, but but it, you know, like my wife says,
I blame the programmer. Stupid programmers. Somebody built this thing. Yeah,
anybody got a comment or aggrievance.
Speaker 4: I mean I think, you know, that style of bug
is something that ideally the platform should provide. I mean,
obviously you can kind of code around these things, but yeah,
in general, like it would be good if the web
platform did the right thing by default. And I'm not
exactly sure who's to blame here. Is is it the
you know iOS or is it Safari or is it
the CSSPEC you know? Probably different in different situations, but
in general, I think the philosophy of like should be
not broken by default or the easiest thing should you know,
the right thing should be the easiest thing to do,
and like the wrong thing should be the hard thing
to do, is right, And probably in the case of
jumping buttons that is a little flipped around.
Speaker 1: It's just an easy thing to fix. If you're a programmer.
Is just to not enable any of your UI until
it's fully formed, you know, And if the user has
to wait for that, that's a good thing. I think, yeah,
as long as they can see it, as long as
they can see it, as long as sometimes when it's
not fully formed, it looks formed and you just don't know, right,
you're an interpret state spinny button you want to pull
out of one to debate. This goes all the way
back to the Node days too. It's promises and ASYNC
coding in general for JavaScript. I mean, this scripting language
that was supposed to be very linear and just part
of helping and render a page, and it's grown into
this crazy thing. But we need a sync programming like
that to me was a battle. I don't know where
you fall on this, Ryan, I think you talked about
promises right at the beginning of Note.
Speaker 4: Promises were in a very very early version of Node.
I took them out because I was worried about the
garbage collection pressure that creating many objects created, but clearly
that was a mistake. It was long before there was
like a spec for promises, so we are kind of
inventing the API for it. But I mean it's a
pretty straightforward API, and.
Speaker 2: It is now.
Speaker 4: It is back then too. I mean, you know, you
have an object to you, you have call back attached
to that object. So yeah, I mean, I'm glad that
it's been specked out now and there's like a clear
way of doing ACYNC programming. And of course you know
in DNO now, like all the APIs are very much
promise based, and that just makes everything much nicer with
like a sinkle weight, a single weight back in no
development times was in a crazy idea that nobody could
actually imagine coming to pass. And yeah, those those compiler
guys made it happen. It's like it's a fantastic kind
of sugar on the syntax to on top of kind
of promises to allow a single weight.
Speaker 2: And that's you know you talk about typescript acincle weight
that sanders as well, right, like they got that thing
to work and see sharp and it really seemed to
propagate after that. Was that twenty ten?
Speaker 4: Yeah, yeah, I don't know the origin of where that
came from.
Speaker 1: Yeah, that's it, and.
Speaker 2: You know you made it when the C plus plus
guys want to implement it.
Speaker 1: Like John Skeet from Google was smitten with a sink
away so much that he reverse engineered and figured out
how it worked. We did a d n R TV
on that and it was just amazing.
Speaker 2: Imagine want to do this. But you know the concept
is simple, The implementation is the hard part. When do
you abandon the socket the holder Like I've been awaiting
but it's never getting here now what like there is
a sense here like you said at the garbagelastion angle,
it's the when is this a dead package? Like it's
never going to arrive? And how do you cope with that?
Speaker 4: I mean, my primary programming language is actually not a script.
It's it's Rust, right, and rust implementation of a sinc
awaight is just just fantastic, right. I mean the answer
to that question, of course, is like you have some
sort of timer object, wrap the promise in or the future,
and rust with with some something that times out and
uh has it has a deadline to it. All of
that stuff can be structured very very nicely in Rust
and compiles down to like, you know, just just the
tightest assembly code possible. And it's it's just a fantastic
language to work in.
Speaker 2: MMM. I've heard it described as the modern C plus
plus Like it's absolutely it's the low level language you
want to as well. Recentovich is on board, like pieces
of Windows are being rewritten in it, pieces of Azure
being ready written in it. It's going into places where
it matters.
Speaker 4: I will never start a new C plus plus project,
that's for sure.
Speaker 2: You're done.
Speaker 1: I wonder what Kate Gregory thinks of Rust. It's really
cool to to hear our world's colliding. You know that
that it's just one big ecosystem software development and we're
all learning from each other. I like that, can't we
all just get along next?
Speaker 2: Because you didn't start up with Rust for Dino, right,
did you? Wasn't it originally a Go.
Speaker 4: Project, very very early, like the first? So I did
this demo for this this ten things I hate about
node talk, and I spent like thirty days, you know,
putting the demo together. And Go. Actually I had been
playing around with Go plus V eight for years before that,
kind of looking for ways that you could restructure a
JavaScript VM and kind of you know, just just through
the tools that I had to handle together. But yeah,
Go has a garbage collector, as says V eight, right,
Go has a run time, and you know, in a
complex system like a JavaScript runtime, like you need to
control everything you can, like you really need you cannot
have like GC randomly popping up in the background. V
eight obviously has the GC and will randomly pop up
in the background. But like, let's leave it to one,
let's not have two. So you know, I think Rust
was a you know, a bit of a leap in
twenty nineteen or I think that's decision, but it's paid
off greatly. Like it's just just fantastic to be able
to build on Rust build on top of you know,
we have a wrapper around V eight that exposes essentially
the same C plus plus API that V eight uses
in Rust, but memory safe and really structured. And then
on top of that we kind of layer all of
our Dino stuff. And what's great is, you know, actually
C plus plus the syntax and is fine. I mean,
you know pointers, Like I don't find that so problematic,
like the fact that it's not memory safe. It's the
build system that's really a problem, like the fact that
you just can't pull in dependencies that you know, you've
got to kind of wrangle seamake and make and like
you know, autocomf and all sorts of stuff, and it
just becomes a real headache to be able to pull
in external code in Rust. In modern languages, like you know,
there's there's a.
Speaker 2: There's a package manager, and there's a pipeline and.
Speaker 4: There's a package Yeah, exactly, you can just you can
just add independencies and that allows us to just go
so much faster.
Speaker 1: And Carnigan and Richie made C to be the cross
platform language, right, I mean that's back in the day.
Back in the day, that was the promise, and C
plus plus certainly, I mean it was cross platform for
a while.
Speaker 2: I was supposed to be this safe version.
Speaker 1: Yeah right.
Speaker 2: See, you know my mistake when you when I first
saw this was go lying in V eight duh, they're
both googleed. They should love each other. I just don't
know they do.
Speaker 4: Yeah, I think they have nothing to do with each other.
Speaker 2: I think that's fair. That's very fair. And yeah, to
talk about rust in twenty nineteen, that's challenging. Those are
early days.
Speaker 4: Yeah, maybe even twenty seventeen.
Speaker 2: I don't know, man even no, yeah, no, no, no kidding.
So in the end, we're still in a lot of ways.
I feel like Dino's got the same sort of philosophy
of just what you need to build a web resource
or whatever whatever your project needs. Am I wrong there? Like,
I don't think your philosophy's changed much.
Speaker 4: So. Inde, Node, you need to know a lot about
the ecosystem to really get ramped up right. Node is
the run time, but you need to add on your
Typescript compiler. You need to add on your linter. You
need to add you need to know that prettier is
the way that you code format. You need to know
how to set up a project structure. In Dino, the
entire tool chain is literally executable.
Speaker 1: Right.
Speaker 4: There's a Dno dot ex that you can install on
your Windows computer that has everything in it. Right, It's
a single file distribution. And this has the code formatting,
you know, Dino format subcommand. It has very much inspired
by Go of course, you know, has a Dino lint subcommand.
It has obviously the runtime execution. It has type checking
Dino check to type check typescript. All of this is
kind of packaged together and thought about cohesively, so that
you know, maybe for the advanced node programmer, maybe not
a huge difference because they kind of know how to
operate in this world.
Speaker 2: They assembled the same set of tools themselves.
Speaker 4: Yeah.
Speaker 2: I mean, I would also see in advanced node developer going, hey,
you're making choices I want to make myself.
Speaker 4: Sure. Yeah, But for you know, the c sharp developer,
who's who's coming to JavaScript or just you know, doesn't
you know, like many people hates JavaScript, but it's forced
to work in it for whatever reason, you know, somebody
coming from Java or just just people less steeped in nodisms.
It's pretty great to be able to be like here's
your Dino dot exx file. You know, run run Dino
help and get started right, and you probably already know
JavaScript more or less. Uh, you know, we have the
Dino LSP that hooks into vs code, so like get
all your intellisence and and tab completion stuff working out
of the box. You'll get the code formatting kind of happening.
And uh yeah, it's just a delightful experience, which for
a scripting language. You know, like I said, I'm a
RUSS programmer. Uh uh, you know, my my programming Rust
is not as delightful as JavaScript. But you know the
reason that you might work, you know, I like Rust
of course because you can write fast code. You can
control exactly what you are what the CPU is going
to execute. But uh, you know, there's a time and
place for scripting languages where you just want to move fast.
And when you're moving fast, like let's remove all the bs,
like let's let's focus on let's just get the scripting language.
Like who wants to set up, you know, spend a
bunch of time setting up a structure for a for
a freaking scripting language. I'll do that for C plus
plus because, like, you know, there's some benefit that I'm
getting there. But you know, I'm working a scripting language,
for god sakes, let's let's make it. Let's make it
easy to use.
Speaker 2: Yeah, it's not just a scripting language anymore. Ryan, I
don't know if you'd noticed, but it's been up to stuff.
I do like the tagline uncomplicate JavaScript, but I almost
feel like it's more uncomplicate web dev.
Speaker 4: Sure. I mean, yeah, JavaScript, that's a core of web dev.
You know, uncomplicate Typeescript as well, I mean Typescript. Traditionally
you have to have your tsconfig dot json like set
a bunch of configurations. You know, people have complained that
it's not one language, but like a suite of languages,
depending on which different options you're enabling. We make all
those choices for you. I mean, you can drop in
your ts can fig, but like you know, is zero
can fig like literally just open a file, pull in
an MPM dependency, no package json, no no necessity to
do anything else.
Speaker 2: It seems far more opinionated than Node ever was. Oh
for sure, yeah, like no kind of left you open
for and in some ways left you wandering the desert,
like do you know what bits the light up?
Speaker 3: First?
Speaker 2: Like it you work through sub tutorial to try and
get anything to run a node at first, where this
one's going. Now we do it this way, here you go.
Speaker 4: I mean, I think I don't regret this, but I
mean I think this is a result of me stepping
away from the project. Right. Had I stayed in the project,
I would have been very opinionated and like dictated things.
Node is a democracy, and you know, is a kind
of free democracy that's nice in many ways, but it
also means, you know, it goes in all sorts of
different different directions and there's not necessarily hard decisions being made.
Do you know makes hard decisions and people you know
violently disagree with us sometimes, but you know, it does
kind of result in, you know, frankly zero configu you know,
very little boilerplate, and I think that is absolutely delightful
for people who you know, the majority who just do
not give a crap a lot of those decisions.
Speaker 1: You can change the default configuration if you want to, right,
I mean, nobody's saying that this is the way everything
must be done. It's just the default convention over configuration.
Speaker 4: That's right. Yeah, So the principle with with Dino is
like you can start with a single file. You can.
You don't need to have a package Jason, or a
product project structure. Like literally a single file is all
you need to get started and go pretty far with that.
But you can of course have a Dino dot json
to set configurations. You can have a ts canfig you
can set configurations in there. You can have a package Jason.
You know, a big part of what we're doing with
Dino two is kind of scaling Dino up to more
complex project structures because yeah, frankly, there's a lot of
people out there with very large JavaScript code bases, and
for sure we want we want to make sure that
Deno scales to support very complex setups as well.
Speaker 2: Okay, talk to me about the differ between Dino and
Dino Fresh.
Speaker 4: So Fresh is a web framework built on top of
dinum So dinos. The runtime Fresh is Fresh is a
way of doing reacty sort of websites. So it has
kind of server side rendering of jsx React style style JavaScript,
and it has Yeah, it's designed to be very fast
has It has a pretty simple structure with a technique
called islands where you kind of segment your client side
code with your server side code. It is a full
stack web framework, meaning that you write client side and
server side code, which you know, frankly is a great
way to build websites as the benefit of JavaScript is
that you can kind of share code between between the
two sides, and by default, uh, you know you can
you can kind of it's build static websites. So by default,
like you can write a bunch of React code, actually
it uses Preact, but you know, same thing. For for
all intents and purposes, you can write a bunch of
server side React code. It'll just render to a static
site and there will actually be no client side JavaScript.
And but you know, as as necessary, if you need
to add on interactive bits, you can kind of pull
those in pretty easily and generally follows kind of Dino's
philosophy of zero can fig zero boiler plate. It feels
really simple and nice to use, and.
Speaker 2: Is it obvious what should be client? What should be server?
Do you get in any debates of where any stuff
that needs to live? I guess you can switch if
you want to.
Speaker 4: I mean, if if you have a button that changes
color when you click on it or whatever, then then
you know client side.
Speaker 2: Yeah, so it's always question mark when's the codes living
in two places? Like do I need to pick? How
big of the deal? Is this fairly open?
Speaker 4: I think it's usually pretty clear, but I guess in
kind of the limit when you get into very complicated applications,
maybe it's a little tricky.
Speaker 2: Should be a parent most of the time, but once
in a while you're going.
Speaker 4: To get an a question.
Speaker 2: So two point zero is imminent? What make you what
makes you do a new version number? Like, what are
you thinking? So?
Speaker 4: Yeah, like I said, we are kind of working on
scaling up to big, bigger, more complex javascripts and typeescript projects.
So the big thing that's happening in Dino two is
that we can essentially execute any node project. Now, modern
node projects you do need to use ESM like exmascript
module syntax, not require but import, but you should be
able to drop into any kind of modern ish node
project and use DNO to execute the code in Dino itself.
Whether you're in kind of a node project or not.
You can pull in NPM dependencies. Pretty pretty nicely. And
we've also introduced this new package registry called JSR where
people can publish JavaScript and typescript code and it is well,
I don't know how much you guys interact with NPM,
but post get Hub acquisition, NPM is really not changing
at all. And that is kind of a shame for
the world's most popular programming language, where there's like vibrant, exciting,
creative things happening, publishing the NPM is still very much
stuck in the common JS era. It's really hard to
for people to figure out how to take typescript and
compile it down and publish it for different different situations.
And yeah, frankly, we live in a world that is
not just Node. Now. There's there's a number of run times.
There's there's a note of course, but Dino and Bun
and cloud flare workers and browsers of course. So JSR
is a modern package registry for JavaScript and typescript that
makes it just delightful to publish ads, say, for example,
auto generated documentation for consumers of these modules, and is
cross platform like can work with all of these different
run times.
Speaker 2: Ind you say that of an NPM, because on one hand,
when get up acquired. You're like, oh good, it's safe.
Now we won't have to worry anymore. It doesn't have
to figure out how to make money or any of
those sorts of things. It's now living in that big ecosystem.
But like there's in inertia. I wonder if they lost
key people like that. There's just they're afraid to do
much to NPM.
Speaker 4: Yeah, I think it's hard to change anything because it's
so large at this point and there's no real all uh,
there's no real business there. I mean that was always
the problem with as a company that like they couldn't
figure out the business. And so I think, yeah, it's safe,
that's that's a good thing.
Speaker 2: Package managers in general aren't a business. We all need them, right,
none of well none of us will pay for them.
Speaker 4: Yes, I totally agree, which is, by the way, is
which why JSR is kind of a completely open source
unlike NPM is completely open source. And although I'm managing
it right now, the Dino company is managing it. It
is a aims to be a kind of public service,
and I hope to put it into a foundation of
some sort.
Speaker 1: I'll have to check that out. Coming from New gat
in the ease of which I can use that in
my environment. NPM was a real kind of learning curve
for me, So I'm hoping that I'm hoping this is
going to be nicer, and it sounds like it already is.
Speaker 4: It's it's super delightful if.
Speaker 1: That's the way it should be.
Speaker 2: I don't know. The perfect packing manager is when I
never think about it, just is what I needed to do. Yeah,
and the moment it pops up and interrupts me, look
at you and you yet, yeah, then it's wrong. Right,
That's a that's a problem.
Speaker 1: Sometimes you do want to make sure that you're not
getting the newer version that isn't compatible with another package,
that isn't compatible with another I mean you do kind
of need that control.
Speaker 4: But assuming speaking of like never needing a package manager
like in Diino two. If you want to pull in
an NPM dependency, for example, a common one is Express
kind of a web you know, simple simple web framework.
You can just import and PM call and express like
you don't need to set up and do kind of
an NPM AD or create a package Jason. You can
really kind of scale down your your stuff and just
have these kind of single line imports, that's defined education
and yeah, and Dino knows how. Dino included in the
Dino ex single file is a package manager and knows
how to pull down the MPM dependencies. And you know,
you don't have this problem of having a node modules
folder in your local project. Uh maybe you want that,
that's an option, of course, but uh, generally it stores
these things in a global cash and so yeah, it
has a generally clean feel to it.
Speaker 1: So when Dino is done and you're on that trajectory
again and you're you're looking around and saying, you know,
I think I want to go on to the next thing.
Do you have something in mind that you want to
do that you can share with us.
Speaker 4: I was just saying to my wife earlier today, like
I want to return to my Pinterest app and get
this this uh this social network going because I hate Pinterest.
It's so terrible. I need it, don't you kind of
need it? I never I never a lot of random
ideas that I would love to pursue, random id manager,
some of them are I pursue with with Dino. You know,
we we just released this JavaScript trademark open letter a
couple of days ago, which is kind of a pet
project of mind fighting Oracle for did you know that
Oracle owns the JavaScript trademark? I hate them and why
do they own it? And how confusing that is, and
especially for people who you know, have something called the
Dino JavaScript runtime. It's just very annoying. Yeah, a lot
of a lot of fun, fun undertakings I continue to do.
Speaker 1: Kind of thinking. There's a little sarcasm in that word
fun coming out of your mouth there.
Speaker 2: But there is a whole initiative going on to try
and get them just to render the trademark. Like right,
you're not doing anything with it, it's not important to Heck,
you barely pay attention to Java. Why you have the
JavaScript trademark as well? Like just it makes everything confusing.
It's just because Sun registered at the time, not that
it was important to them.
Speaker 4: I mean, the Java trademark might actually be important because
that is something that they continue to develop and presumably
have a business around. I'm not against trademarks, of course,
but it is the JavaScript one is very problematic. You
can check out check out this open letter that I'm writing.
So I'm planning on filing. I just learned about this
process a couple of months ago, I'm planning to file
a petition with the USPTO, the Patent and Trademark Office
to cancel oracles JavaScript trademark because I think it is
it is actually invalids as defined in the US Code,
And I go through that in this in this open letter,
and yeah, I think I think next month we'll actually
file this.
Speaker 2: Great, I mean, good for you. They should actually just
release it and try and make themselves look like the
good guy. But it is Oracle. There's not a lot
of good guy there.
Speaker 4: Yeah.
Speaker 1: Yeah, let's let's hold open source developers feet to the
fire so that they can't use our trademark.
Speaker 2: Nice, stupid. There's nothing they could do with it that
would be useful in any way or.
Speaker 1: Profitable for them, right, what's the point? Yeah?
Speaker 4: I think the best best thing they could do is
release it and get the goodwill for it. But as
Brian Cantrell has said, don't anthromorphize the lawnmower, Oracle being
the lawnmower.
Speaker 2: A lot more that collects is licensing fees along the way,
oh man, a licensing strategy known as so how much
money do you have? Yeah? Right, all right?
Speaker 1: The leaf sucker.
Speaker 2: Hey, Ryan's so much fun to talk to you. Thanks
so much for all the great work you do. It's
really a pleasure.
Speaker 1: And it was delightful talk to you as well.
Speaker 2: Great.
Speaker 4: Thanks, It's fun all right, and.
Speaker 1: We'll talk to you, dear listener next time on dot
net rocks. Dot net Rocks is brought to you by
Franklin's Net and produced by Pop Studios, a full service audio,
video and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Speaker 5: Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two thousand
and two.
Speaker 1: And make sure you check out our sponsors. They keep
us in business. Now go write some Oh see you
next time. Got trade middle vands do the summer time
that means home than my Texas a line d