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