Hey, folks, welcome back to another episode of the JavaScript Jabber Podcast.
This week, on our panel, we have Dan.
Shapiir Hey from a howt tel Aviv a j.
O'Neil yo yo yo, coming at you live from blistering Utah.
Steve Edwards.
Yo, just one yo for me coming from a formerly warm but now cooling down Portland.
Yeah, I was just outside AJ. It's not terribly hot yet. It's gonna be hot this afternoon, but yeah, I'm also in Utah.
On Charles Maxwood. We're talking to Ryan Dall this week.
And Ryan, I'm just gonna do a little bit of an intro and then you can tell me all the cool stuff that you've done that I don't mention.
But you're largely credited with creating.
No JS, I know other people we've been involved in that, and you've moved on to also then create Dino.
I think those are the kind of the big things that you're known for.
Are there other things that people ought to be aware of other.
Than that you're a cool guy?
Because I think those are the flagship things that I've done.
Awesome. So I'm just going to jump in. We're kind of doing this.
We usually record on Mondays, and we're doing this out of band just so we could get you in and let people know about what's going on here. So Dino two is coming out, and I think that's kind of where we want to start. And you know, you send us some material, but I kind of like to just let you explain some of this.
You had Dino.
And you know, Dino's been out for a while and I know some people are using it and enjoying using it, But why did you need a DNO two? Like there were there things that you weren't able to do in dn O one that you needed to do or is it just like faster better?
And I don't know.
Yeah.
I mean, first, there is Node, and I think you know the idea that JavaScript is this language that everybody knows and it's got a really great VM via Chrome, this this V eight VM and JavaScript is is you know, Node was essentially ide eating on how you could take this client side programming language and attach it to servers and the fact that when you click on a button and get a call back, it's pretty similar to a web server getting a request and getting a callback, and
that event driven programming is actually a pretty optimal way to structure servers and uh, Node, I guess it goes without saying these days is pretty popular. So that's project, uh, you know, be used by I don't know, essentially every website, right, I'm certain we're recording this on stream yard dot com. It probably probably uses node in some form or another. Almost all websites do it. It is in some some
ways the cornerstone of the Internet. And uh, that is largely because JavaScript is the default programming language and so important it is. It is not like Java, it is not like c It is kind of intrinsic to humanity because so much of the world has been built on top of web browsers.
Right.
You access your library through the web browser, you access your bank through the web browser. And this infrastructure is not going to change anytime soon. It's its future proof in a certain way. Like I'm pretty sure we'll be using a GP and CSS five years from now, if not ten or twenty years from now. And CSS and and HGP are not dissimilar to JavaScript. They are protocols that make up the web, and so JavaScript is kind of future proof in this way. And that is really
the reason that Node has grown so big. I mean, note was I think I did a pretty good job attaching a web server to JavaScript. But you know, ultimately it's kind of the growth of JavaScript that drove notes success. But you know, Node.
Has before if I can interrupt, because I have to ask about this before you move on to what came after Note. So you basically stated here like two big motivations for the creation of Node, and I'm kind of curious if they if any one of these two was the primary one when you when you like envision initially envisioned it. One was, as you said, using JavaScript, which is the cornerstone of the web on the server side.
The other being the event model and and you know, the event loop and and all this mechanism, which, as you said, turned out to be such a great match for uh, for the server side, Like a lot of people initially didn't expect that, and you had the foresight to see that that it that it is such a great match. So I'm curious as to which one of these two was the primary motivation or they like equal.
It was the realization that those two compliment each other, that that was the creation of Notes. So a little bit before Note, like you know, let's let's say two thousand and eight. Two thousand and seven, I was working
on engine X modules. Engine x is a kind of native web server that is written in C and is event driven, and at the time, driving event loops was kind of an unknown subject, like you had to be a real expert, you had to really know what you were doing to kind of drive equal In two thousand and eight, and I was aware that this was kind of the optimal way to drive web servers as opposed to starting a thread per request, and I was enthralled by this thing and looking for ways to make this
easier and bring this to a larger audience of programmers. It was like literally like one hundred people who knew about this, and maybe a bit more than that, but like you just had to be this like an expert and part of some subculture to build an event than
web server. And I was looking at different programming languages, originally Ruby, looking at Haskell for a little bit, looking at ways to kind of bind to drive web servers in an event driven way and in a you know, backed by epole on Lenux and inspired a lot by twisted Python and event machine and Ruby and the problem you know, looking at those things deeply found that the big problem with those systems was that they interacted really
poorly with the rest of the standard library. So if you take SA event machine in Ruby, you realize that there's all sorts of blocking operations elsewhere in the Ruby stack. And and if you take kind of non blocking stuff and blocking stuff and just try to merge them altogether, like you just it ends in disaster. Because the trick with with event driven web servers is you could never block the event. That's the that's the you know, the
principal thing that you have to do. And so you have to really build the system from the ground up to be non blocking, an event driven. And I had the insight, you know, maybe the singular insight in my life that oh my god, JavaScript offers the opportunity because there is no defined standard library, there's no defined way of interacting with the operating system. Into two thousand and eight,
there was no server side JavaScript. This offers kind of clean, clean landscape for me to build up a pure event driven web server and all of the associated libraries that you need to do that. So if you're making say an outbounds TCP connection, you also have to drive that in a non blocking way, or if you're doing a timeout, you also need to you you cannot block the event loup when you sleep for for a couple of seconds. Right,
all of this needs to be event driven. And yeah, so this just works magically with JavaScript and makes all of this much more accessible to people. So, you know, I think.
The the broad.
Bent of what I'm trying to do is make and I think this continues through Dno One and Dino two, is trying to make programming accessible to people and allowing them to program pretty deep important infrastructure, you know, driving event driven web servers and whatnot with just a few lines of cote and and you know, without necessarily understanding what is happening at the lower layers with people and everything else that's going on. I think most Node users
have no idea about any of those those things. And that's great. It's a it's a clean abstraction.
So I guess what I'm wondering then, is so, so you popped the hood on d O one and you said, we're going to change out some of this stuff, right, We're going to we're going to add some new features to the to the engine, or I don't know.
This metaphor is going to get real weird in a minute, I guess.
But so what I'm wondering is, is you know what's different between Dno one and Dino two that get you to this thing that you're trying to create.
Yeah, so okay, let me let me take a little step step back and just introduce Dino a bit. So around twenty nineteen or so, I've been working on other stuff, I haven't been working on Node, and kind of came back to Node and was starting to look at it deeply and was really kind of disappointed about how I found the state of note. Obviously I follow it, like know that it's growing, but you know, it did not feel like the clean, simple abstraction that I was going for.
You know, when you start adding all of these NPM dependencies, you have like a two gigabyte modules folder, There's there's common JS everywhere, there's ECMAScript modules, the HGP client and Node is different than the HP client and web browsers. It was just this kerfuffle that, you know, really disappointed me because this is getting away from the goal of like you don't need to know what's going on, you can just sit down and start programming.
Right.
JavaScript is for the children, like it should be should be easy for people to just start getting programming, start getting going. Also, on top of all of this, Typescript was very clearly becoming a thing, and integrating Typescript into your NOE project required all of this setup and configuration files and builds, and it's just it starts making it
not very nice to program in. And so started Deno with with the idea to clean up a lot of this stuff with a kind of from the ground up run time implementation, not in C plus plus like I did with Node, but uh in Rust, a new new new language, and really focus on making a typescript first, narrowing the gap between server side JavaScript and web browser JavaScript, really using web standards, making an emascript module first, making
it batteries included. That is having kind of a tool full tool chain of programming utilities that you need because you know, it's not just the execution of JavaScript. You also need code formatting and linking, and you need an LSP to connect to your editor, and the list goes on and on, like you really need a full tool chain of things. And you know, in my mind that is the run times obligation to provide those things I really like how go UH does things. It's it is
a all you need is go and UH. It gives you everything that you need to get started. On top of all of.
This, If I can interject again and I apologize for rupting you, it seems that basically said what you're saying is that you had this great idea, but in certain ways it was kind of ahead of its time. You basically invented and created a lot of the ecosystem, and as the ecosystem evolved and matured and introduced by four certain pieces that were missing at the time, Like you know, acmascript models just weren't available when you created notes, so you kind of had to invent common JS to create
this module system. So and in a sense you were kind of stuck with those inventions that you created, even though over time a lot of them turned out to be less than ideal. Is that the proper way of saying it, and like node can't change for the same reason that browsers can change. I mean, a lot of us would be happy to go back maybe and change a lot of the various domain pis, but it's impossible
because backward compatibility trumps everything else. You can't break the web, and likewise, you can't break the million applications that currently run on Node. But the big difference is that on the front end, you know, the browsers are what they are. On the back end you have the option of using maybe something else instead of Note. You're not breaking compatibility
if you decide to use something else. So does that kind of paint the picture of why you kind of instigated Dino is like you're certain a chance for a redo or retry something like along these lines of, hey, I now have promises, I can do a weight stuff like that.
I think of it in terms of like scaling limits, like Node just kind of reached this scale that, like the note has this kind of small core philosophy, Like the philosophy of Node, you know, just kind of started breaking down at a certain scale. And I you know, it's unfair to say it's breaking down. I mean, like note is the cornerstone of the Internet, right, I mean, it's it's totally fine, but I think there is still an opportunity there. JavaScript is going to last many years
from now. We are not at the end state, and like Node in twenty nineteen, I think it's unfair to look at it and say like this is it. This is JavaScript for the rest of time. Like that is not the case. JavaScript is going to last many, many years in the future. In some ways, we're just at the beginning. And I think it is incumbent on us, if you know, if you care about this, if you're working in this ecosystem, to try to simplify it, and I think it can be simplified by addressing these problems
at the run time level. The comment about breaking changes is important, and I think that's that's one of the things with Dino two that that we are reevaluating. I mean, Dino started out with with very much uh, a incompatible API and set up to node and we have found that to be problem you know, nice in many ways, but but kind of problematic at scale.
Yeah, I read a bunch about like the the NPM compatibilities, and yeah, some of the node compatibilities and some of the things that we read.
Leading into this.
So how much of that is in Dino two And how much of that did you just wind up bolting into Dino one piece at a time.
I mean, uh, Dino Dino two is not like a hard break or anything. It is just more and more features kind of uh evolved into into Dino Dino one. So yeah, I guess that's an important point to make is that like anybody who's who's written a Dino program like that is going to continue to work. There's no there's no breaking changes, so to speak. In Dino two. What has been happening over the last two years is we started maybe eighteen months ago, kind of started, uh,
node built in APIs in Deno. The ability to import node colon fs for example, and be able to read files from from there, and also NPM support, the ability to kind of pull in NPM packages kind of been in a nicer, more elegant way, we think than than in Node where you you kind of need a separate package manager and kind of install these things into node
modules and Dino you can just reference NPM modules. You can do imports in PM colon Chalk or n PM colon Express, and it just kind of it just kind of works like a kind.
Of I have to ask about this because I recall when dn O one came out, what it was just Dino back then one. When Dino came out, one of the main selling points and a lot of people kind of got all in The huff about it was that it didn't actually have a package manager. It was, as I recall it was, you want something, you just downloaded it from the web. It arrives over HTTP, it gets cash, so you don't need to download each and every time. But it works just like your browser. You don't need
a package manager. And now all of a sudden turns out that you actually do need a package manager.
So was your initial package manager? Okay, correct, Yeah, we started with a So we started with acmascript modules. The theory being mscript modules is the real module system, not common JS, and that future JavaScript should be built on top of Yes, m and the real it is the real I mean it is literally specified in Oh.
Yeah, I guess to that degree. Yeah yeah.
And you know it's real in the sense that browsers. You cannot require in a browser, but you can import in a browser, and you can import h GP specifiers, you can import hip colon slash slash blah blah blah uh and kind of link linked to a JavaScript file in a browser. So it is it is that is the real module system in JavaScript. And so our our thinking was, let's expose this to server side JavaScript, and maybe this is sufficient for maybe this is all you need.
Maybe maybe HI, maybe links is all you need. Uh, And we went pretty far with this. Our idea was like, if we build up tooling around this and make this uh ergonomic enough that we could have kind of a decentralized module system where anybody can post code on any website and you can just link it into your projects. It's pretty great. It's pretty great for small scripts.
Why not get this is because it seemed like Go had solved this problem better than anyone else has ever solved it. And I think that Go modules had already existed by the time that Dino came out, so very much inspired I go, well, yeah, why not? That's because the talk I watched it sounded like, mathematically, from a graph perspective, the ghost system is literally perfect. You cannot get better. You can get worse, you can make worse trade offs, but you can't make better trade offs.
Uh.
We again, we stick to the standards. So there is not a way to import a a GET repository in the web browser. And so we were reluctant to add something that that is not something that works in the browser, because you know, the the axiom that we have is that we want to narrow the gap between server side JavaScript and browser JavaScript as much as possible. We want to have the same APIs, we don't want to have the same module system. And yeah, you could, you can
add that on there. But I think our original take with with Dino was let's just stick to HGP specifiers and see how far we can get with that, and the yeah, I think we we essentially have the answer now a couple of years later, which is that it works for small scripts. It works really really great. If you're just scripting, you know, hacking together a little build script or or a little you know, file manipulation tool
or something. You have a single file, you can kind of throw in some h GPS imports at the top. You can kind of publish these things. It doesn't work so well when you start having larger projects, multiple files, multiple packages. You're you're kind of having these u r ls kind of strewn all over your co base. They don't necessary. Of course, a version string can be embedded in a URL, but without a real kind of semantic understanding of what versions of modules you have, you have
a lot of duplicated dependencies. You might have essentially the same dependency with like a slightly different patch version, slightly different URL kind of in your dependency tree.
Why not attack that at the standards body level, because that seems that seems like a problem that is universal enough, that has existed since the dawn of Unix, I think, I mean, version numbers have been around I think since certainly since people have had computers in their home. So why why don't we have a standard at the at the web level or you know, to attack that with one of those with the one of those standards bodies.
I mean, there is essentially a standard for versions now semver, and we do participate in the standards bodies, but standard bodies are also very very slow moving and are not necessarily something that you can You don't want to standardize
first and then implement like we we are. We are trying to build software for humans here and like actually actually solve problems, and so you know, only working in the standards body is attended TC thirty nine A couple of times, I have to tell you is the most boring thing I've ever done in my entire life, and just want to It's it's like that I'm trying to ship software that people can actually use so yes, we do.
You know, Dino is a member of TC thirty nine, and we do interact with standards bodies and we do try to make JavaScript better in that sense. But there's there's a pretty big gap between standards and implementation that allows for a lot of creativity.
I have some paint drying that you can watch.
I kind of want to go back to the imports because you were talking about, yeah, pulling in through a ht TP and you know, you get the library or whatever you need, right and it loads it in and you know, hopefully it's all set up properly for the module import.
It.
What what's changed, right?
I mean I've read the blog post about HTTP imports and I think that's where you're headed here, So you know, I don't know if you had something to finish on that thought and then yeah, where are you're going pretty im.
What's what's changed is is that it just like, first of all, it doesn't work at scale. Like versions are a problem. We have the problem of servers going down. So if you have some dependency that has some other dependency that is hosted on you know, a personal home server, and that server goes away, then like the all the transitive dependence uh dependence of that program of that module uh die along with the server. So there's a reliability problem.
But I think the overarching problem is that when you're dealing in kind of bigger projects, you have problems like, hey, I need to use the A W S, S D K, like I need to talk to S three or whatever. And we really don't want to be in a situation where you need to rewrite all of this software for Dino, and that that gets very problematic at the scale. Right, I need to use uh g r p C right like we we we we cannot rewrite the world, uh, given all all that has been done in JavaScript. Uh So this this.
Is actually one of my big questions because it seems like Node fills a niche and it's really imperfect, but it's you know that that niche is full and there's you know, there's there's do you know, and there's fun and and I think there might have been another project that maybe has already burned out, but you know, there's there's these projects that have major advantages over Node, but they're an incremental improvement. Node was a big bang and
the future advancements are like just another galaxy. Right, So when you look at the ecosystem. I was actually really excited back when Dino was Hardbreak because I thought, great, this is a chance for us to get quality software that's been thoughtfully written. That's not just everybody who's ever touched a computer throwing something up on NPM. Because the stuff that's on NPM, ninety nine percent of it is garbage and there's like that small, small percentage that and
that's just like, that's just a preto distribution. I'm not I'm not like trying to throw out a disc there. Like most of the information in the world is wrong. Most of the you know, most of anything is going to tend towards the less useful and the hone, the specific, the skilled, you know, like most athletes aren't Olympians, you know. So like for me, the idea that we were going to have a clean break from Note and we were going to be rebuilding the core pieces just clean was
super exciting. And these seem to be in juxtaposition. You're saying, well, we need to rewrite the engine, but actually we don't need to rewrite the libraries. Where does that how do those reconcile or why is why is that. Okay.
We added NPM support and node built in support to be able to poll in modules, including ones that use common JS and development patterns that we consider to be antiquated or deprecated, and there is unfortunately an enormous amount of complexity to be able to support common JAS in an ECMA script only world. But that doesn't change kind of the overall philosophy of Dino, which is too level up JavaScript. We don't allow our users to say use require or to do kind of poor development practices. We
were really encouraging people to level up JavaScript. But being able to pull in gRPC from NPM is absolutely necessary when you need g RPC, because gRPC is preaking complicated and like nobody is going to rewrite that. So in a sense, like a hard break is kind of nice until you realize that, like there is a lot, a
lot of a lot of infrastructure out there. The way that we can encourage people to have better development practices to write clean code is what we're doing on JSR, which is a new open source registry that is kind of a superset of NPM. Like you can depend on NPM modules in JSR, but we have something called the JSR score where you get a higher score if you follow better development practices. So it kind of allows people
to publish trashy code. And I agree with you, there's kind of a power law distribution in terms of quality of anything, and there is going to be a ton of crap out there. So there's a ton of packages on JSR that are going to have like a zero JSR score. But we tell you how to improve this. Add JS docs to to your exports, use typescript, use you know, various things to kind of encourage people to
up the quality of the code that they're distributing. And yeah, I think this is I think this is the right tactic. Like we need to have kind of stepping stones into the future. Again, JavaScript is going to be here for many, many years, and the you know, no JS of twenty nineteen is not the end state, Like I just I firmly bel leave that because there's just too much economic pressure to make JavaScript better. Uh so we need we
need kind of ways to incrementally improve this. And as as we were saying before, Node has all sorts of dependencies on existing software. It's very hard to fundamentally change how Node operates. It's effectively impossible. You can kind of tack on different things here and there, but you really need a project like Dino to to kind of fundamentally think about these things differently. But you know, it's it's it's not a kind of binary story. Like we we do.
We have realized that we need to be able to pull in and PM modules and be able to use SA g r PC or the A W S S d K. Otherwise people can't really develop real software in this thing. And again we are we are not doing this as an academic exercise. We are trying to write software for real people.
So you said something, you said something that was really interesting to me. You said that effectively, you can pull any existing NPM module which obviously uses which was obviously written or developed for note, which means it uses no practices, no structures, no the APIs, et cetera. But when I'm developing in Dino, I'm intentionally restricted to the dno way, which is the better way.
So kind of means I would call it the modern javascripts like we modern Java encourage best practices.
Because it's standards standards.
It's not, yes, well, it's it's kind of modern standards and I'll touch on that in a second, because there are certain things in Dino that I wish were part of the standard, like the I wish that the dno quote unquote standard library was the JavaScript standard library. And I'm if like, my biggest complaint against the JavaScript language as it is is that it's really lacking a standard library, and I would have loved for the Dino Standard Library to be the germ or the root of that of
such a standard library. But going back to my previous question or point was that I didn't is a point that I didn't understand or know before was is the fact that effectively you're you've created like two kind of
distinct runtime environments with under one hood. There's like the dirty, scruffy environment that you need to support for the existing note modules, and there's the cleaner, nicer environment where you write your own code so you you can the note modules that you can do things that you can't intentionally do. That's really interesting and something that I didn't realize.
So, for example, the node modules that you import might use common JS, of course, but they might also have like a process global. Process global is not a web standard, so we avoid having the process global in Dino. So in your kind of top level script that you're writing, although you might pull in express which might very well call process, and the top level script will not be able to call process and without an explicit node call and process import if you're following.
So you've created a sort of node virtualization environment within Dino and you're effectively running the node NPM modules within that again quote unquote node virtualization environment sort of.
Yeah, I mean virtualization environment is suggests that it's uh yeah, suggest that it's virtualized in some sense. So I wouldn't call it that, but there there is uh uh yeah, there's a there's all sorts of of kind of trickery that that we do to make this uh uh kind of hidden from the user.
And how compative? How compatible is it? I what level of compatibility were you able to achieve? I mean, it can't can't have been easy. Let's put this one.
It's it was not easy. It took us a very long time, a lot of a lot of engineering effort. The level of compatibility is fantastic, it's it's very good. We've been working on this, like I said, for for about two years now. There's always going to be a long tail of incompatibilities, and we consider any module that we can't run a bug and we will fix it. But it's really really good these days. So Dino can even import node modules that have tension modules to them,
like compiled extension modules that use NAPI for example. So so Dino implements all of the NAPI binding layers. It's it goes very deep, and it's it's you know, our goal is is uh, you know, let's let's call it four nines of compatibility or something like that. There's always going to be a tail of incompatibility, but like essentially anything that you pull in and should work out of the box.
And yeah, you know these days, the big, the big problem with projects like that from my own experience is that, like you said, like everybody uses this, like ninety something percent of the modules that people use are essentially the same holders. Like there are certain small subset of modules that are the most popular by far, but the problem is that a lot of organizations use another module in
addition to that. So the question always is am I not going to find myself stuck because some weird module that some developer that worked here five years ago imported and I'm dependent on and it does something really really out there, and the environment as a problem with it.
I mean, it's always possible. But the compatibility layer happens at kind of the node API boundary.
Right.
Note has all of these built in modules like fs API, and Dino implements these very very deeply and well, and so I would expect even random side modules are going to work. But like I said, there's a long tail and there will be incompatibilities. But yeah, I would encourage people to try it. You will be shocked. You can
import essentially anything. You can take next JS and you know, create next gs app and do Dino run dev in there and this well, this this works right, So Dino can can take any package, chase on node first project and run this natively in Dino as well.
And the other question that I have is again one of the one of the defining aspects of Dino when it came out was the security and the sandbox model. The fact that you your your sandbox by default and you open up certain aspects and you only open up those aspects that you actually need. Well, again, my question then becomes do you run into issues with that when you're using arbitrary node modules that have no concept of this security sandbox and if so, how do you deal with it?
Yeah, so I haven't haven't mentioned that, but that that is indeed one of the kind of flagship things that we were trying to do with Dino is like the web browser or and and you know, this goal of kind of narrowing the gap between server side JavaScript and browser JavaScript. Browser JavaScript is super secure, right. You're running untrusted code day in and day out in every single tabu and the V eight VM provides a super secure
sandbox for this. And uh in Node uh. You know, we were more interested in in what we could do, uh, rather than thinking too much about whether we should be doing it. You know, we we uh we uh we just I wasn't thinking about security back then. I was thinking more let's put it exactly thanks, yes, And I think, you know, now, with with with some years to to think back on that, I think, uh uh, being able to utilize the secure sandbox that v e provides is
it should be should be mentioned. V eight is the is the the real workhorse here behind Dino and Node.
Uh.
And in some ways you can think of Dino en Node as kind of you know, if VIGHT is the Linux kernel. Then then Node and Dino are kind of like two Lenux distributions, right, two different distributions of VIGHT. Anyway, we in Dino, we do use the security of the v eight VM, and by default, when you run a program, whether it has NPM modules or not, you have zero access to the system. You cannot make network connections, you cannot read from the file system, you cannot see environment variables.
It doesn't matter if your NPM dependencies or dependencies of dependencies, call process m whatever. All of that is gated in Dino because again we've re implemented all of this, and so that extends to the NPM modules and you are able to gate access a pretty fine grain layer in the user space at the VIGHT level and kind of say say whether whether things are are able to access, say the file system, or if they're if they're able to make outbounds network connections or listen on a socket.
All of that is controllable, and it does extend to the compatibility layer. It's a very nice aspect of the system. You kind of have to provide a few more flags, and it's a little slightly less ergonomic because like yeah, in many cases you do want to turn off the sandbox right if you're running you know, if you're writing a script like it's probably going to interact with the file system, it's probably going to interact with the network.
But you know, there are many cases where maybe you're just writing a proxy server and you really don't need access to the file system at all. It's very nice to have that at your fingertips and be able to gain that access.
The cool thing about it, though, is so what I'm understanding from you is you can start fully sandbox open whatever features you know you need, then start using the various snowed modules, and then if something breaks because of security because of the scent box, and I assume that there's the appropriate notification for that. So you are aware that you know this module try to do something that it's not allowed to do. You can then decide whether or not you know you actually need that module and
are willing to grant that security aspect to it. And conversely, you might ask yourself, hey, why is module that's supposed to be doing networking want access to my filesystem? You know, maybe I should be more suspicious about what it's actually doing.
How do you guys, feel about a screen share? I guess this is a podcast, so probably, well.
You can screenshare for for we can do a quick screen share. But you know our listeners obviously are losing out.
Well, do you want descriptive reading?
Let's let me see if this works. Well, well, let me see. Can I share a window? Yes, let me just pull up a terminal here a.
J I want descriptive singing.
Can you see this.
Listening along at home? We can't see anything yet, but now it's a terminal.
Chuck, be careful what you asked for?
A right, so let me just whatever tests dot t S and and let me just just show you he's.
Using them, by the way, not neo VIM like a nube for those listening.
This is this is actually but whatever.
Yeah, the I am at the top was a dead giveaway.
And Alias did his VIM like a professional, not like a nube. By the way.
Let's say we wanted to make so I'm console logging hello, And let's just say I want to like make the background color red? Okay, And and I think how you do this? In Node you often use the chalk library, so you can import chalk from and in Dino you just do chalk okay, and then you can say something.
Like chalk dot so it's npm chalk to tell it that it's an NPMD.
That's that's right. So you can do something something like this. Hopefully this works. So DINO tests and what you see here is that it says DINO requests environment access to force color. Chalk is reading environment variables and so I can I can say like uh no and deny that. No, you can't read that. No you can't read that. No you can't read that. You can't read that, can't read that, and it logs it not in color. Let let me let me try this again with allow muh or just
dash e to allow environment variables. And now chalk has has operated correctly. So yeah, I mean a really simple demo, of course, but it's chalk was not built for security sandboxes, like it knows nothing about this. But you know, through through our patibility layer, we are gating access to the environment variables. And maybe you didn't know that chalk was was actually accessing those things, and you decide that like, hey, actually I don't want to use chalk. I don't want
to expose my environment variables. Let me do kind of the Dino first way of doing this, and in fact the Web standard way by putting ah, you know percent see there and doing background color red is actually the you know Web standard d slash Dino first way of doing this. This is how you do it in the browser. And now you don't Now you don't need any any control access you can you can just use use the CSS directly. Here are you following me?
Yep?
Yeah, for those of you that are listening along, you can actually pass a CSS style as a string the same way you would put it in HTML as a an argument in console dot log to fill in a percent c. So you you have a string with three percent CS and then you can add three styles.
As I recall, you can also do the same thing in the browser devle.
Yeah, yeah, this is we We do not invent APIs, so this is not like a DNOE thing to do where.
Yeah, but for those are curious, the same way that you can use colors in your console logs inside the browsers work. Indno, the exact same way. That's that's the basic Yeah.
But I think the main point there is is that like chalk does read environment variables. Probably knew, but nobody knew that, but maybe you're sensitive to that, maybe you have secrets in your environment variables, and maybe you don't want to allow access to that. Chalk's a pretty simple example, but this kind of extends to any NPM module and so you can kind of see what these NPM modules are doing and decide specifically if you want to allow
access to that. So, yes, the security sand boxes is still, uh, you know, a primary thing, and you know, and we think pretty important.
What I really like about this is the fact that, you know, we've been in the context of security. There's been a lot of talks about the problem the security issues when people like take control over existing projects and insert malware into them, kind of creating all sorts of
supply chain issues. And the Dino approach is a very interesting safeguard against that, because if somebody introduces malware into an existing package to do something that it isn't supposed to do, there's a good chance that the existing sandbox could prevent it from actually doing that, and all of a sudden you'll get that error and the thing won't maybe won't work, but you haven't introduced a security vulnerability.
Yeah, it gets really problematic when it comes to like NPM post install scripts. Like anytime you add a dependency, like any dependencies of that n n C are going to run their post insult script. You're you're essentially in in node. Anytime you add a dependency, you are running untrusted code from random people on the internet on your computer without any sort of sandbox. Like it's very problematic.
Plug plug for socket. I use socket because I don't I don't. I don't want to be running untrusted code from random people on the internet when I have client work and AWS keys and you know that sort of thing. I forget what their website is.
It's socket dot dev.
Socket dot dev. Yeah, socket and that that links in. I think they have GitHub actions that will link in on push to monitor your package, Jason, as well as uh an alias for NPM so that it hooks into the NPM install and make sure that malware doesn't run on your computer.
Yeah, and we and we did have for us on our show back. We should probably have them on again.
I'm going to change our direction just a little bit here, unless there's something else you want to add, Ryan before I do that.
No, no, So, so one of the other things that.
We're seeing come through is JSR and so I wanted to talk about that from a bit too. Here we've already been going for fifty minutes and I want to be mindful of your your time. But yeah, it looks like an interesting project. Do you kind of want to set the stage for what it is and why you even created it?
Yeah, like post gethub acquisition and PM is like not evolving at all, and you know it's kind of the central place where you share JavaScript code. Like this is pretty unfortunate. Like JavaScript is a very vibrant world with all sorts of changes happening. You know, we're moving to typescript, we're moving to ESM, and like the place where everybody is sharing code has is effectively dead. There's all sorts of security problems as we were just discussing. Uh, it's just, uh,
it's not fun. Like have you I'm sure everybody here is published an NPM module. You tried publishing like something that's written typescripts? Have you dealt with you know, common JS E s M, Like what what sort of output do you have? How does the exports thing work? Like it just gets really complicated and again kind of gets gets away from this JavaScript being for the children like this. This should be a toy like language. This is a scripting language. We are not programming in C plus plus
like it should be. It should be fun and nice, and the registry could be supporting us so much more here. And as I said, when we were discussing it GP specifiers, you know, we kind of come around to this, this realization that a centralized registry is actually very important for reliability. You can't have things hosted on random servers. So we we have created JSR. It is open source, unlike the NPM registry. It is meant to be a community service and is managed by me right now effectively in the
Dino company. But we intended this to be a community service and open source and community driven. And it is just delightful to use. If you have ever published to NPM, you will immediately see the benefit. Like you can just publish your typescript. It just works. It is really meant for a world in which there are multiple JavaScript run times. The Node Package Manager is meant for a world in
which there is Node. But in twenty twenty four, we've got Node, we've got Dino, we've got bun, we've got cloud flayer workers we've got the browsers right, there's many different places where you're going to be running JavaScript, and it's important for a registry to support all of those targets that you might be writing JavaScript for. It's very important for it to support Typescript. And we've just got all sorts of useful features in there that are attempting
to level up JavaScript. And I think I mentioned earlier the JSR score, where you know, we give you a kind of a point score for your package, and it's probably going to start off with zero percent because most stuff is crap. That's fine, But in order to get towards one hundred percent score on your GSR score, you have to implement things like having a description for your package,
making sure that there's documentation for it. Test coverage is not one of the is not one of the things that add factors into the JSR score, because it's really hard to decide in general, across multiple run times, how what sort of test coverage you have?
One thing?
Oh, go ahead, well I was going to say, suffice it to say that that we put a lot of thought into into js R and uh uh yeah, I I I really think this is this is where we should be having the vibrant sharing of code in the future. It's it's it's delightful to use.
So one thing that very much concerns me is that code should not be vibrant. Codes should be dull and
dead right. And most of these registries, and all of them that I'm aware of, kind of play off of the you know, it's it's it's kind of like social media, and so the idea is to update and update and update, and so what ends up happening is that what's always on the homepage are the the modules are that are the most insecure, the least well engineered, have the most bugs because they're the modules that are just always changing or or being written new and will never be finished.
And then the code that is mature and stable, the code that you wish that you would find, ends up being at the bottom of the pile where you'll never find it. And then these modules that are just making constant changes are the ones that become popular. Where's the modules that are the diamonds and the rough that have three stars are the ones that are like, it's got full documentation, it's type that it's simple code.
I'm not sure I agree. A J. I mean, people are still using express, and Express is not is effects supposedly dead.
So well, okay, once once a module is carved out a niche that it's game over, right, that people are always going to use that module forever. But I'm talking about the pattern of giving immature and buggy code priority because it's the code that's always being updated as opposed to stable code that works. Well, you know, do you are you a do you see that as a problem and do you have a way to promote code that is stable overcode that changes frequently or is new.
I also kind of disagree with the premise. I mean, I think you know, in some sense the I agree with you that like people should strive to get their packages to a final state, and that the code should be boring and not interesting. But obviously the technology, the software stack of of humanity is growing and new things need to be developed and they will need to be iterated on, and they need a place to share those things.
Yes, I agree with that, but for example, once you've implemented a Jason parser, you're done now. Thankfully a Jason parser is so boring it gets to be in the standard library. But there are many things where once you've implemented them, they are done. If you are publishing updates, that should reflect negatively upon the package score, because you should not be publishing updates to something that can be complete and having.
Projects software right, not everything.
Kitchen sinking, yes, but if you're kitchen sinking something, if you're building a framework where every week you're adding a new feature and another feature and another feature, another feature, then you're just creating kitchen sink blot right.
Maybe.
I mean you may have a tool that that's what people want. I mean that there are systems. I mean take Ruby on Rails for example. A lot of people love working in it and it kind of kitchen sink stuff, and they keep adding things to it that do more jobs.
So, I mean, the web standard is changing all the time. It has to adapt to that.
You probably don't want the kitchen sink logging library, and we saw where that leads when it when that happens, But you probably do want to kitchen sink something like like next JS maybe or or Ruby on Rails. It kind of depends on where you are.
I'm just saying that curating this in that way is a huge job, and I don't it doesn't sound like Ryan and the other folks that Dino are necessarily I mean, they see some of the problems, I'm sure, but I don't know if they're interested in solving that problem.
I'm saying heuristically, not always favoring the things that are buggy and changing constantly, having some like yeah, just not giving superpowers to the people that are just publishing weekly And I'm sure so many company companies. But you are aware of this, and you're update hacking.
Like publishing should be hard so that you can't change it, Like I don't think things should be unnecessarily hard.
No, no, no, no, no, I'm I'm saying give it. So for example, you go on your website packages recently updated, new. I see, I don't want packages that are being updated all the time, and I probably don't want packages that are being new unless they're pretty close to completely.
But I don't. I mean, that's just something for the homepage. I don't think this is the primary mechanism for finding stuff.
I mean, what is the primary mechanism for finding stuff? Because it seems to me like for an MPM, the primary mechanism for finding stuff is Google.
So yeah, yeah, and I think the same as is true for JSR. I mean, we do have a search there. I wouldn't call it perfect yet, And the JSR score that I mentioned, which again encourages boring coding practices, like you know, just have some docs, you know, like factors
into the search results. But like, ultimately, like a registry is going to have lots and lots of stuff on it, and you're not going to necessarily like find a list of all the things that are on the pack, Like you can't have a list of all the things on NPM and scroll through it and find it. It doesn't matter whether it's sorted by new or not. You're going to pull it in terms.
Of search engine optimization, right, Like if you want to hack the system, you can just publish updates. You can just bump the minor version and basically do nothing and it'll show up on the homepage. Google ranks the NPM homepage higher than it ranks other pages on the internet. Right.
So there is and you're publishing. I'm sure you have whether it's a like an XML feed or whether it's you know, some sort of Jason feed, but there's I assume there's something that you're publishing where you're probably putting out to search engines and whatnot in things that the things that are updated frequently are the things that are going to get the highest like they're going to get the benefits.
That you're worried that the that the kind of new recently update call on the JSR homepage like impacts the se O of of like crappy packages. I mean, yeah, okay, sure.
I would like to I'd like to pull us back to before we finish, I'd like to bring up another another another topic that you mentioned several times. And it's also interesting because Node recently did a change regarding that as well, which is Tipescript support. I mean, like the big one of the one of the biggest things. Sorry, Chuck, you wanted to say something, I just.
Want well, I wanted to just ask one other question about jsright here, real quick, go for it. I mean, because because you know, we were talking about the quality of the packages and things like that, But my question is how do you use it?
Right? Is it?
Is it the import maps and the imports like we're talking about before. Is there a cl I was going to say c l I, but a command line interface for those who aren't t l A three letter acronym. Yeah, uh savvy. And is it only for public? Is it for pulling them into my prep?
Yeah?
How does this all kind of hang together so that I can go?
Okay, JSR looks to me better in some cases than NPM.
It's it is better than NBM in every in every situation. I guarantee you it is fantastic. You can use this. So if you're using Dno, it's it's like we have native support for JSR, so you can just do import JSR colon h your package, just like you can do import NPM call in your package. Right, It's it's a u r L in the system. And so Dino has native support for this. And you can of course put JSR specifiers into your import maps and turn them into
bear specifiers if you know what those words mean. If you're using Node or bun, you can use the NPM compatibility layer like behind the scenes. All of these packages are actually exposed as an MPM registry NPM dot JSR
dot io, and you can add them to your package. Jason, So there is really great docs on on JSR, and I'll just drop you a link here, but on each of the package pages you should see like a little usage statement and it will tell you the commands to run to add it to your to your package Jason. But yeah, the support gets really really good when when it comes to Dino where where it all is super smooth and requires no extra commands.
Awesome.
Yeah.
I just put that into the comment on Facebook, YouTube a Twitch as well, so people can find it if you're watching there.
And we'll try and get it into the show notes as well.
But yeah, I mean that that was what I wanted to know, is, hey, it looks like a great experience. So yeah, and this is ready now right. This isn't something you're announcing and saying, hey, try it a couple of weeks. It's out there.
It's done, done and done. No, we're still iterating on it. But I think it is like ninety nine percent done, Like it's working. It's fantastic.
Well, if I understood correctly, Dno. Two is just an iteration. It's like, do you know one point eighty seven? But at some point you just need to go to two?
Right.
It sounds like there's a few milestones, but it's not right. It's not a rewrite.
It's not a rewrite, And the main thing is is that this NPM support is really you know, at four nines of completeness. It's like complete. You have this option of JSR available to you if you want to have the leveled up version of NPM. Yeah, I think it's you know, there's other aspects of this that we haven't gotten into, like the long term support. Dino is very
stable at this point. We are not changing anything. We're introducing long term support in Dino two, and we also have workspaces in Dino two, but that you know, it's kind of getting you know, two is about scaling up projects to to you know, relatively large code bases where you know, I think Dino started with like really great for single files, and you know, what we're trying to do is keep it, keep Dino great for single files, but make sure that it scales up to two projects
that you know, have one hundred thousand lines of JavaScript in it, and that includes the NPM support, that includes and JSR that that means, the long term support and workspaces all all kind of factor into this like scaling up of Dino.
So I would really like to sneak in one or maybe two things before we wrap up. Let's see if I if we manage it. So the one of them I started to mention was the type of support like the as you said initially, you in a kind of similar way to how you recognized early on the the role that JavaScript could and should play on the service side.
You realize early on that the market was heading towards typescript, and in fact, like I think the majority of JavaScript code in the enterprise is actually typescript, and you introduced like effect built in support like from the get go. Interestingly, now know that's just introduced a sort of support for typescript as well, by effectively stripping out all of the type information, essentially treating it by comments and running what's left.
Is that similar to what you do or do you do something different?
It's similar to what we do when you run typescript and Dino we very nice attribute of typescript is that it's a super cheap operation to transpile that into JavaScript. You don't really have to understand the types, you just
strip them out, and that's how Dino runs things. Dino also has the type checker, the Typescript type checker in it, so if you run Dino check, it will check your types and the typeescript is kind of fully baked in through the system, through the linter, through JSR, the you know, Dino tries very hard to make it so you don't need to write any configuration files. No, no ts configured necessary.
So the typescript goes much deeper in Dino. But yeah, indeed, uh is note is picking up on some of the features of Dino.
So so because you're effectively just stripping out the typescript, you really don't care about the typescript configuration because I think it it was uh Matteo Colina you probably know once said that typescript is not a language, it's a universe of languages, because you could really specify what kind of language it is via your TS can figure. Uh, And there's certain then there's certainly truth in that you can really modify the way the typeescript as the language works.
But I guess that if you're just stripping out the types and effectively just ignoring them, then it all all boils down to the exact same thing.
Uh, There's there's a bit to unpack there. So, first of all, Dino does not just stript types. Dono understands the types deeply, do you know, do you know has deep type script support in it as does js R. Like this, this typeescript support goes goes very deep in the system, so much much more so than just stripping types. Ah, It's true that you can configure typescript in different ways, and typescripts with different configuration code bases with configurations can
be incompatible with each other. We strongly believe that typescript should move to a single configuration, single language world where you can actually distribute typescript as the primary code, not the typeescript type script JavaScript. And that is one of the main features of JSR. You literally write the typescript and distribute the typeescript because we believe that run times like Dino and Node in the future, we'll be able to understand that typescript directly. And so we believe in
linking typescript together and having a single configuration. And I think a lot of people people might think that there's a world of possibilities in all of these possibilities. There is a world of possibilities with typescript. You can you can set all sorts of things, but not all of those possibilities are equally ranked. Okay, there is a good way to configure Typescript and pushes you towards that configuration
as is JSR. That's part of the JSR score. So we encourage the default best practices in typescript, and we encourage using Typescript as a primary language and distributing typescript and linking Typescript to typescript and not introducing always this compile step. I think this is unnecessary complication because ultimately the code that people are writing is Typescript, and having this kind of intermediate compilation step and linking step is it creates complications for people.
Yeah, but the compilation step also serves a certain purpose, I think, because at the end of the day, typescript is not about run time type checking. It's about it's about development type type checking and compile time type checking. If you're taking away the compilation you're also negating effectively the compiled time type checking. You kind of want a certain middle step, don't you No?
Do you know Dino has Dino check subcommand that runs the type checking. It's it's effectively like a lint right on on your on your so you'll you'll when you're developing, of course, you'll see this in your LSP, you'll you'll see red squigglyes and and the typeescript TSC kind of
running in the background. Uh, but also during you know, when when you push the c I or whatever, you should also be running Dino check, which which is you know, effectively t SC and UH check those types and you should get errors if if those types are not correct. So there's no compilation step, you're still no compilation.
Linting instead of compilation basically is what you're saying. You're not getting rid of a step, but you're replacing a compilation step with a linting step. Yes, so if I'm running a step anyway, what's the benefit of linting over linting and compilation? Why not do the compilation?
Think about what happens. Think about what happens when you write a typescript module and you distributed this to NPN. Think about what you have to think about the type stripping. And you need to build a build process to create JavaScript, and you need to think about the output of that. So you need to generate some code, right, you need to run TSC and create a discs folder and have kind of the type stripts JavaScript output it into that folder.
You have to think about, you know, what flavor of JavaScript you have that is all not abstracted away from you. Right in Dino, in JSR, that is completely gone. You do not think about that. You don't even know about that. If you're a user, all you are using is typescript. So yes, in your c I script you still have one line that says dino check and that effectively does your type checking for you. But there's a whole bunch
of complication that is completely alleviated from you. And I think as a user, when you go to use JSR, you probably are not even aware of this, and the overall vibe that you get is just like, holy shit. I did not realize this could be so simple because you're not necessarily it's not going to be like kind of a conscious Not everybody's thinking about their disfolder and the distribution of JavaScript all of the time. Right this is this is effectively internal details that have been because
NPM is not evolving, are exposed to users. And when you go to a system like JSR or DINO where we kind of deal with typescript natively, the end effect, the vibe for the everyday programmer is just holy shit. This is crazy simple. I didn't realize it could be this nice.
Cool makes sense now. I don't know if we have time to touch on that. But my second question was about it seems that one place where Dino has been really successful compared to Node and apparently more appropriate is in edge computing. Is that correct? I seem to recall that.
Edgy Dino is notice bigger than you know in every in every respect.
H So you know, including memory processing time?
No? Uh, well sorry I got the reversed. Yes, that's correct. U. Yes, do you know Dono the company I think what you're alluding to has in edge compute, Uh, commercial service called Dino deploy and Dino subhosting. And yes we we this is how we make money. We we we provide services around edge compute.
Well, we've heard of other companies using Dino because of its better performance characteristic characteristics that we as we've interviewed other people. So I think that's where our our bias leans toward what we've heard from you know, other people on the show and whatnot.
Or is that.
Generally generally performance is better in in Dino it is. Uh, we spend a lot of time to make make it great.
What do you have? I this might be for part fun what about bun.
Fun is? Uh? Yeah, was there a joke there? Fun is is a re implementation of Node, uh that is trying to outperform it. So I think they've done some nice ergonomic moves. They're also kind of uh building the package manager into the run time, which I agree with. I think that's that's a good step, and also taking on kind of this typescript type stripping feature from from Dino.
But you know, basically, have have the have the idea that yeah, twenty nineteen JavaScript is is the end state, and all we need to do is make this faster. And I fundamentally disagree with this. I think there there is really something to level up here and improve on. I do not think we should continue to use common JS require indefinitely, so you know that. I think. butN in in many ways is is uh, you know, trying to do Dino, but but maybe learning from our mistakes.
You know, they very aptly are focusing on node compatibility. But yeah, to what end? Why why rewrite node exactly?
That?
That's that's always my question. I think rewriting rust, Yeah, I mean I'm sure it's I'm sure, it's fun. Ultimately that's that's not what I'm trying to do here with with dino is is rewrite node in in rust. We are trying to level up vascript and make this stuff fundamentally simpler for for developers. Performance wise, I find the benchmarks that they have at the top, you know, above their fold on on their their website are not wrong,
but they are cherry picked. The performance situation with Dino is fantastic, and Dino outperforms, butN in all sorts of circumstances in many of the ways that matter more. For example, if you want to you know, if you're running on eight of US Lambda and you're concerned about your your primary concern is not necessarily about Hello World throughput, which is the benchmark that they have up on their page. But it's a little unfair, actually, it's it's it's very
cherry picked. And I think with a system JavaScript run times are have all sorts of functionality that you know SPA, there's there's thousands of APIs that that have been implemented performance changes all across the board here. Uh but you know, I think if you if you look at the overall picture, the performance situation is vastly overstated above the fold on
Bun's website. And yeah, I think generally have the goal of re implementing note And yeah, that's as that's I guess, a goal, but not not what I'm trying to do. We are we are trying to level up JavaScript and kind of build the JavaScript for the next twenty years.
That was an excellent line to end on.
Yeah, good stuff.
By the way, to answer your question, the rim shot was because you mentioned the magic word pun.
So I just had to throw that. I see, I got it.
Somethinking about pun and Bun and I was like, okay, that deserves one right there.
All right, well, let's do picks, Dan, you want to start us with picks?
If I mused myself, it will be helpful. This is the second show that I'm recording in one week, so I'll excuse myself and say that I'm all picked out and move on to the next person.
All right, AJ, what are your picks?
So?
I tried swift, and I have not had enough time with it to give a true take, but I'd like it. I have this problem with mac os as they introduced these permissions and tools that I used to have that work, they kind of stop working or new bugs get introduced as they're changing out all those permission models. And one thing that's been happening lately is my network drives become unmounted and then when my computer wakes up, they're not remounted.
And so I wanted to create something that would listen for the unlock event and then mount my network drives. And it ended up being the demo code was ten lines of SWIFT, and then I expanded that out because I wanted to make it like a normal project with command line arguments and you know, the stuff that I typically do, and kind of get a feel for it, and I really really like it. It's it's kind of to me, it kind of feels almost on par with
GO in some respects. I don't think that there maybe as thoughtful and deliberate in the way that they present APIs as GO is, but it is very explicit and there's there's enough training examples that as a person who had never touched Swift before, I was able to use GPT to pretty much, you know, be the code assists.
My primary code assist in creating my program, which ended up being more than ten lines it's more like one hundre because of the like I said, there's some arguments parsing and some other stuff and me just playing around. But yeah, so I'm I'm gonna pick Apple's Swift. It it seems to be a really solid language, and I yeah, I don't know, I have it. It's different, it's it actually reminds me more of PowerShell than of anything else,
which that sounds like a disc but it's not. PowerShell is probably one of the best things that Microsoft has ever turned out. PowerShell is incredibly well engineered and thought out. It has a different paradigm. It's actually a much more functional paradigm. But and it doesn't have a concept of standard in and standard out as much as it has a concept of pipes and streams. And so it's not
just standard in and standard out. You can, I think you can have an arbitrary number of streams, but they're they're kind of functional in the way that they work, almost like channels go or something. I don't know quite how to explained. Anyway, Swift is Swift is a pick for me.
And then before you move on, it's just what you said about GPT just occurred to me that we totally forgot to ask Ryan, which a which mL model are you going to be building into Dino?
Yeah? Yeah, what's your what's your AI strategy for the future?
I really, you know, doing a startup like that, that question gets asked and ironically very often, Uh oh, I know, I our our, our, our technology is pretty orthogonal to this. But if you go back and kind of look at some of my stuff, uh, Dino actually started out as a TensorFlow plus node project. We I was coming out of Google Brain and wanting to do mL models in JavaScript.
And we haven't touched on kind of the Jupiter notebook support in in Dino, but you know, I guess suffice it to say that that I think data science and statistics and stuff in JavaScript is a thing that will happen in the future. And although I'm primarily working on the module system and kind of getting the run time up and running right now, I have dreams of kind of stealing statistics away from Python and scientific computing and making this work in JavaScript really nicely.
I love the idea, to be honest, I've been thinking for a while that I I would love to see something like that in a language that I find more approachable, right, So you know, for me that's Ruby and JavaScript, but you know, yeah, just having those capabilities in these hands, and I think especially JavaScript.
With the reach that it has, I mean, that would be amazing. So I'm all on board with that, AJ, did you get all your picks out?
You know?
One more, I think I'm gonna have to switch my my browser screen shotting service from running with Bun to running with Dino. So I'm just testing it right now. It worked. I was able to just like change two lines of code what process dot exit was one of them, But now it's not closing. I'll figure that out. But yeah, so so I guess I guess I'm a Dino fanboy again. Ryan. I I've had some things to say in the past, so.
What you I am shocked?
No between like as this cycle has gone from you know, Node and Dino and Bun. I was like on the Dino train for a while, but I was really frustrated with some stuff and then I was on the Bun train. So I'm uh, I'm JavaScript fluid.
All right, All good, we're trying, we're trying to figure it out. Hopefully you have a nice experience with with you know, in the future.
Well, it's it's going to improve my my performance on opening up a binary to run Chrome to do a screenshot.
So all right, I'm gonna jump in and derail us back to Steve.
Steve, what are your picks?
Okay, Ryan, I'm not sure if you were, But the high point of all our podcasts is my dad jokes, so hence my name Dad Joker. So wait, okay, supposedly thirty of the world's population lets their pets sleep in bed with them. I'm really upset though, because I tried it yesterday and now my goldfish is dead. The other day I learned that Albert Einstein was a real person, But this whole time I thought he was a theoretical physicist.
And they like, it's so good.
They don't get better.
That's the best when you've had an agents, I thought.
A pretty high bar. And then last night I saw this breaking news story that during the day, actually sorry, during the day, count Chocolate to Stay Puff, marshamallow Man, and the Teddy Grahams Bear all perished in a fire and they said, s'more at eleven, what.
Your joke about Einstein? Reminded me of a dad joke about this young physics student who is at the party and he's dancing with some girl trying to pick her up, and he says, you know, Einstein and Newton's dead. Einstein's dead, and I'm not feeling so well this evening. I guess that didn't end.
I'll give you a rimshot anyway for the effort.
That's all I have done, all right.
I guess it's my turn for picks, so I'll jump in with I always do a board game pick. I don't know if I did this last week or earlier this week, so I'm just gonna and if you get it twice in a row, I am sorry.
I'm gonna pick Challengers. It's a game.
It's kind of a mix between Capture of the Flag and War. It's a relatively fast game. You play seven rounds. Whoever has the most points at the end of seven rounds, the two top people go head to head, and whoever wins that one wins. And effectively it's a deck building game or kind of, so you draft cards.
You can put two cards.
Into your hand or one higher level card on some rounds into your hand. You're building out your deck, and then you flip the cards over and they have different abilities and so anyway, sometimes they stack nicely, and essentially there's I can't remember what the zone is on the side of the playing field, but you can stack up to six types of cards on the site. If you
run out of room there, your opponent wins. If you run out of cards, your opponent wins the round and then they get a trophy that has the points on it. So the gameplay is relatively simple. It's just knowing how to get the cards to synergize is the game you're really playing, and then knowing when to pull things in and out of your hands so that you don't bust on putting stuff onto your bench right and running out of room there. So it's it's a terrific game. I
think board game geek rate waits at to something. I didn't look it up, but it's it's super fun. It plays up to eight people. That's the other thing that I like about it is that usually you get a board game and it'll play four, sometimes it'll play five or six. Challengers plays up to eight and everybody gets a card that just shows you where to sit next, so that you're playing. And yeah, the board game weight is one point seventy eight.
It's pretty approachable. I think my eight year old could play it.
I don't know that she'd really do well with the deck building piece right put all these together, you know, to have a mighty hand, but I think she could to a certain degree. No, oh, I really like these cards. Or pick the higher the higher number cards so that you can win the flag back. So anyway, I'm going to pick that came out in twenty twenty two.
I played it.
At the game Board Conference up in Layton and it was awesome. So anyway, yes, you can play it with two players. It is probably better with four, six or
eight players. If you have an odd number of players, there's a robot deck that gets progressively harder as each round goes by, because it's got things like this card is worth whatever round you're on, or however many fans, which is the points you have, or things like that, so you know, it's kind of set up to kind of match your hand, but you play both hands when you're playing against the robot. So so you can play with odd number of players too, is what I'm saying.
But yeah, it's it's typically better if you have at least four and that's just because then you get to switch up who you're playing against. But you can definitely play it two player. Yeah, it's it's pretty awesome. So I'll put the board game geek link in here, and then I'll go find an Amazon affiliate link here in
a minute, and then other picks. There was an article that came or not an article but a blog post that DHH put out basically talking about free speech, and basically essentially what he was saying is that people have the right to say things, even if they're offensive, even if they're awful, even if they're full of crap. He didn't say full of crap, uh, he said some He used the word I'm not going to use on the podcast, but you know, but you have the right to say
what you're going to say. And I like the idea of that, just from the standpoint of, hey, look at least I know who you are, right, and I think most people are smart enough to figure out, yeah, you know you're saying this and you really are full of crap.
So but but he was responding mostly.
To the stuff where they're sent sentencing people to like twenty months in jail for posting something to social media that's offensive in England and oh my goodness, yeah, just very true.
I've seen the video.
Yeah, yeah, the thing that and you see this in the United States too, and you know it's cherry picked examples, but they give an example of like a man essay to woman and got six months, but a person who posted something mean on Twitter got twenty months.
It's it's a it's it's problematic because unless you know, it's very easy to get specific cases wrong if you don't know the details, like you know, on the one hand, it's obviously free speech, and we're all all in favor of free speech, but then turns out that incitement was made, so it's it's it's it's like if you say, you know, go out and kill all such and such people, right. Yeah. So I'm not saying that it's not that it's right or wrong. I'm saying that you need you should have
the full context before making judgment. I tend to reserve my judgment until I have. You know, as much.
As it was a mob boss with a coordinated attack, it doesn't matter if on Twitter you say go kill someone. I mean, if it was a leader of a terrorist organization, that's one thing.
But in some countries it is.
You know, I didn't mean to open this can of worms, but I will.
Again, I'm not making you all judgment. I'm I'm just saying that in some countries have different laws regarding free speech than the US does. And you, yeah, cognizant that.
Yeah, I recognize that.
I think I think the issue that he's pointing out and he didn't go into like incitement and stuff, right, he was just saying, hey, look, you should be able to say wrong things, and and that I agree with.
Right, Yeah, down to incitement.
If you're encouraging people to go out and hurt other people, you know obviously that that's a real problem. But if you're expressing your opinion, you can express bad opinions.
Anyway.
I'm trying to think if there's anything else I wanted to pick. I have an AI summit that I'm putting together in October, so keep an eye out for that.
Other than that, Ryan, what are your picks?
I really like Grain dot com. This is some tool that helps you record meetings. And you know, Dino as a company, do you know, do you know has uh is remote and we have meetings with people and and uh Yeah, Grain just helps you record it and make some transcript of it. And I find it just super useful too. It's just got a great interface, so pretty pretty simple tool. But but and I'm sure there's probably other ones, but I've been finding a lot of utility from grain.
Awesome.
All Right, One last thing, and we should have asked this way earlier. But if people want to see more information about Dno. Two, or if they want to reach out to you and say, hey, I like this or I don't like that, how do they find you?
Yeah, I'm rough Ce rough Underscore Underscore see on on Twitter with Dino Underscore land On on Twitter, uh and Dino.
Dot com on on the webs and yeah, there's a discord you can. You can find my email if you search hard enough. So, yeah, we're happening to Rye Rye the Twitter handle or what.
Yeah, well I thought you were right? Were you not right?
I was ry Yeah with an h in twenty ten. But yeah, I stopped using Twitter for a number of years and just just came back a couple of months ago.
Well, I'm sorry for your mental health. I'll offer you some asprin if you need it.
All right, It's it's it's fun being on Twitter these days. Yeah, back in the not days, it was very noisy.
Oh bet that explains the That explains the shockingly low number of followers you have. Yeah, I was by the way, Chuck, did you give Ryan the chance to do picks?
I did you pick?
Co?
Oh? I missed it. Sorry I wasn't I wasn't paying attention. Sorry.
Yeah, all right, Well we're gonna go ahead and wrap it up. Thanks for coming, Ryan, And thanks to your team. They've done an excellent job kind of keeping us informed.
So to do this. And thanks for making such a huge difference to the web. I consider the Web to be like maybe one of the greatest achievements of humanity of all time. And and and I think that you know, you and the Dino team, but even you personally have made a significant impact on that. So thank you for that.
Yeah. Well, I don't know if I can take credit for the Web. I can take credit for note which Yes, thank you, and yeah, thanks for having me.
On It's fun.
Thank you for the reminder of the Flintstones every time I hear the name.
All right, till next time, folks, max out