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