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.
Hey, Carl and Richard here with your twenty twenty four NDC schedule.
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.
Ndcporto is happening October fourteenth through the eighteenth, Tickets at Ndcporto dot com.
We'll see you there, we hope.
Hey, welcome back to dot net Rocks episode nineteen eighteen. Where are we in history today? Richard?
And of World War One?
End of World War One? Wasn't that fun?
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.
Yay.
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.
Oh man, what do you got?
So?
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.
Oh yeah.
And remember RSS readers, right, those were all the rage when.
Blogs the good old days.
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.
YouTube, anything you might subscribe to.
Anything you might subscribe to.
Yeah, that's interesting.
And so it's it's kind of like that. It's kind of the old RSS browser on steroids.
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.
Right, So this is a and I love this. Remember trillion You used.
Trillion right, yes, I used trillion back.
Yeah.
So trillion was like an instant messenger that went everywhere and it was one.
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.
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.
Cool.
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.
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.
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.
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?
Well, yeah, Flak is Wave quality but half the size, so it's perfect for downloading. All right.
I'm perfectly happy with my MP three's honestly.
Yeah.
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.
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.
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.
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.
And the influence that no js had throughout the industry was undeniable. So thank you from all of us to you.
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.
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.
Yeah that was cancer man.
Yeah, it's it's the it's the English for programming languages, right right, It's what everybody speaks.
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?
Yeah?
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.
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.
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?
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.
Of I kind of figured that about you.
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.
And is still a critical piece of business infrastructure. I mean it is critical.
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.
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.
I think it's going on all websites. It's not a stretch.
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.
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.
That accidental success kind of like Herman's Hermits.
Darn it, Brendan, you should have thought further ahead. Is that thirty years ago? Now? Good lord?
Yeah? And wasn't it written in a weekend in a hotel room or something.
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?
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.
Can you follow for that.
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.
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.
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.
One thing I notice is that it supports web assembly.
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.
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.
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.
Yeah.
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.
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.
That's right.
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.
Sort of do what typescript does.
Is that what you're getting at, Yeah.
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.
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.
That's that's an, that's anders Land.
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.
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.
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.
Yeah.
Well, and you seem to have a pattern too, Ryan, because you keep building tools for us to make more reliable websites.
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.
So when you started, note at least were you using web sockets or was this all just HDDP sockets.
Yeah, websitits did not exist.
Yeah, web sockets didn't exist.
Yeah, but long.
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.
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.
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.
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.
I have zero experience with dot net.
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.
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.
Mm hmm.
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.
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.
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.
Sounds like we're opening up the airing of grievances for web technology here. Who wants to start?
Why don't we take the break first and we can do the second half as grievances.
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.
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.
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.
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.
It is now.
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.
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?
Yeah, yeah, I don't know the origin of where that came from.
Yeah, that's it, and.
You know you made it when the C plus plus guys want to implement it.
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.
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?
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.
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.
I will never start a new C plus plus project, that's for sure.
You're done.
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?
Because you didn't start up with Rust for Dino, right, did you? Wasn't it originally a Go.
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.
There's a package manager, and there's a pipeline and.
There's a package Yeah, exactly, you can just you can just add independencies and that allows us to just go so much faster.
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.
I was supposed to be this safe version.
Yeah right.
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.
Yeah, I think they have nothing to do with each other.
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.
Yeah, maybe even twenty seventeen.
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.
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.
Right.
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.
They assembled the same set of tools themselves.
Yeah.
I mean, I would also see in advanced node developer going, hey, you're making choices I want to make myself.
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.
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.
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.
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?
First?
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.
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.
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.
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.
Okay, talk to me about the differ between Dino and Dino Fresh.
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.
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.
I mean, if if you have a button that changes color when you click on it or whatever, then then you know client side.
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?
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.
Should be a parent most of the time, but once in a while you're going.
To get an a question.
So two point zero is imminent? What make you what makes you do a new version number? Like, what are you thinking? So?
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.
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.
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.
Package managers in general aren't a business. We all need them, right, none of well none of us will pay for them.
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.
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.
It's it's super delightful if.
That's the way it should be.
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.
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.
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.
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.
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.
Kind of thinking. There's a little sarcasm in that word fun coming out of your mouth there.
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.
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.
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.
Yeah.
Yeah, let's let's hold open source developers feet to the fire so that they can't use our trademark.
Nice, stupid. There's nothing they could do with it that would be useful in any way or.
Profitable for them, right, what's the point? Yeah?
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.
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?
The leaf sucker.
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.
And it was delightful talk to you as well.
Great.
Thanks, It's fun all right, and.
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.
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.
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