Speaker 1: Welcome to React Roundup, the podcast where we keep you
Speaker 1: updated on all things React related. This show is brought
Speaker 1: to you by Void and top End Devs. Unvoid provides
Speaker 1: high quality design and software development services on a client
Speaker 1: friendly business model. Unlike all other software agencies, Unvoid allows
Speaker 1: clients to only pay after the work is delivered and approved.
Speaker 1: Visit unvoid dot com to learn more and reach out.
Speaker 1: If you know a company that needs more professionals to
Speaker 1: help with design and software development, that's u n void
Speaker 1: dot com and top end Davs helps you stay up
Speaker 1: to date with cutting edge technologies like JavaScript, Ruby, Elixir,
Speaker 1: and AI. Visit topandevs dot com to join their AIDV
Speaker 1: boot camp, weekly community meetups and access expert tutorials. I'm
Speaker 1: Lucas Paganini, founder of Onvoid and host of this podcast.
Speaker 1: Thank you for tuning in. Let's jump into the episode.
Speaker 2: Welcome to React ground Up. I'm Jack Harrington and I'm
Speaker 2: here with my co host TJ Van Tool everybody, and
Speaker 2: Page Nadering House. Hello everyone, and today we're talking to
Speaker 2: Eric Simons.
Speaker 3: Hey, how's it going.
Speaker 2: Thank you for having me, Thank you for showing up,
Speaker 2: and what do you have to talk about? Today React
Speaker 2: ground out.
Speaker 4: Well, I think probably probably a couple of things, but
Speaker 4: I think probably the most interesting thing is some stuff
Speaker 4: that we've been working on with the next js team
Speaker 4: and Google Prome team that lets you like run no
Speaker 4: JS in your browser, which might sound like a really
Speaker 4: weird idea, but it's actually very awesome. I mean, especially
Speaker 4: with the kind of the current trend of you know,
Speaker 4: React is really kind of you know, blurring the line
Speaker 4: between what is server code of what is front and code, right,
Speaker 4: and so this actually kind of this allows you to
Speaker 4: actually have a much faster and better development and debugging
Speaker 4: experience for that, and.
Speaker 3: We can kind of dig into that.
Speaker 4: But I think that's probably the most interesting thing called
Speaker 4: webt containers, the technology we made for it, and so
Speaker 4: I don't know, maybe sat on Twitter.
Speaker 3: At some point, maybe it didn't, but you know, being
Speaker 3: kind of being kind of dig into it.
Speaker 2: No, it's super cool. And so you can run next
Speaker 2: js in the browser.
Speaker 4: Yeah, yeah, and so and it's actually so it's like basically,
Speaker 4: well I can kind of back up, I kind of
Speaker 4: give the context of why the how we ended up
Speaker 4: doing this thing and so for it, so back five
Speaker 4: years ago now as of this month. Actually, my co
Speaker 4: founder of the company's names Albert. He and I actually
Speaker 4: grew up down the street from each other. Literally here,
Speaker 4: I guess people can't see the video, but I'm in
Speaker 4: Chicago my parents house right now, visiting them. And Albert
Speaker 4: grew up like literally ford of houses down his parents
Speaker 4: are still there. And so we grew up and you
Speaker 4: learned how to go together when we were in high school,
Speaker 4: and we ended up going out Stillicon Valley and starting
Speaker 4: some companies. But five years ago, I guess about six
Speaker 4: years ago, we had the realization that browsers were like
Speaker 4: getting really powerful, and at the time, we were actually
Speaker 4: teaching people how to do web development, and we kept
Speaker 4: running into this problem where like students who were learning
Speaker 4: would get stuck on like setting up stuff locally on
Speaker 4: their computer, and so we're trying to teach React and
Speaker 4: they'd be like, hey, reacts says amount of file launchers.
Speaker 4: We're like, that is not React. That is just stuff
Speaker 4: that broke on your computer for like no good reason. Right,
Speaker 4: So we're like, Okay, well, how do we how do
Speaker 4: we solve this problem because like we were, we can't
Speaker 4: even teach react, right, And we ended up like having
Speaker 4: this realization of you know, all these build tools like
Speaker 4: webpack and et cetera are just like they're written in JavaScript, right,
Speaker 4: and so theoretically, would it be possible to like copy
Speaker 4: pasta webpack and then slap it into a browser tab
Speaker 4: and like just kind of have it work right and
Speaker 4: and so the answer is, like, it's possible. It's just
Speaker 4: it's an incredible amount of work to do that. But
Speaker 4: Albert and I have always been suckers for a good challenge,
Speaker 4: and so we sat down for six months and built out.
Speaker 4: Essentially it's kind of like a code pen plus plus
Speaker 4: where it had MPM built into it, it had like
Speaker 4: web packloaders, you could you know, do all this cool stuff.
Speaker 4: So we launched it and kind of like took off
Speaker 4: like a rocket. And so that's stacked with dot com
Speaker 4: is effectively it's like it's online ide that actually runs
Speaker 4: entirely in your browser. It's not using servers. And so
Speaker 4: this is different than things like get up code spaces
Speaker 4: or like code sandbox run stuff on servers. If you
Speaker 4: ever used those things, you know you might notice they're
Speaker 4: like pretty slow. You have to be signed and use them.
Speaker 4: That's because they're actually provisioning a server for you to
Speaker 4: write your code on, which costs them money, and there's
Speaker 4: a lot of latency, et cetera. So usually the experience
Speaker 4: is worse than your own local environment than when you're
Speaker 4: using what of these online. But anyways, so the short
Speaker 4: of it is that we end up figuring out, like
Speaker 4: a couple of years ago after having launched that it actually, well,
Speaker 4: the web has been progressing at a really rapid rate,
Speaker 4: and we realized that it was actually theoretically possible at
Speaker 4: least to write a new type of operating system and
Speaker 4: web assembly from the ground up where you could actually
Speaker 4: run no JAS entirely in the browser, which then opens
Speaker 4: up the ability to run next, JSS, fight all these
Speaker 4: different tool chains and you can just MPM install them,
Speaker 4: MPM run start and it's running all on your computer,
Speaker 4: so it actually works offline, et cetera. And so we
Speaker 4: actually that's that technology is called web Container, and so
Speaker 4: we actually rolled that out back in May, and so
Speaker 4: stack with the effect that ma you know, Stack, that's
Speaker 4: just like the fastest most secure ID on the planet
Speaker 4: because it's all being done inside the browser security sandbox,
Speaker 4: et cetera. So that's kind of like that's like probably
Speaker 4: information overload, but that's kind of the short of like
Speaker 4: kind of how we started off and kind of how
Speaker 4: we got here today on stuff or building.
Speaker 5: Yeah, I think this is kind of crazy to me
Speaker 5: because like it took me a while, and maybe I
Speaker 5: can talk through this too because it might help others.
Speaker 5: Because when I first saw the announcement, my first thought
Speaker 5: was like, oh cool. Then my second thought was like, wait,
Speaker 5: what does this do again? Right, because it's it's like
Speaker 5: oh because and what made it click for me is,
Speaker 5: you know, I write a lot of just like really quick.
Speaker 5: The main thing I use note for is like writing
Speaker 5: little scripts to do things like I need to mess
Speaker 5: with some files or something. But my workflow for that
Speaker 5: is while I write some script locally and I run
Speaker 5: it locally because Node is a local thing, because that's
Speaker 5: how it always like works in my brain. It either
Speaker 5: runs in my computer, it runs on some server somewhere,
Speaker 5: And the idea of going out to a browser and
Speaker 5: writing something with Node and runrunning it is kind of like,
Speaker 5: at like the very simplest level, what this sort of
Speaker 5: thing makes possible. And that sort of blows my mind
Speaker 5: a little bit because I still like the part that
Speaker 5: still doesn't totally run in my brain or that I
Speaker 5: don't totally compute, is like, how is this possible? Because
Speaker 5: node is Node is big, right, Like it's fairly complex,
Speaker 5: and so are you somehow like loading that are like
Speaker 5: people downloading node when they go to like step flits
Speaker 5: dot com site web containers or whatever, or like how
Speaker 5: exactly are you like injecting that environment to make it
Speaker 5: possible to develop with these this sort of tech.
Speaker 3: Yeah, it's a that's a really good question.
Speaker 4: And then so to kind of add to the to
Speaker 4: and I think I kind of I missed the punchline,
Speaker 4: which is actually that running no jass in stacklets dot
Speaker 4: com is faster than your local environment. Like execution speeds
Speaker 4: are twenty percent faster. When you go to stackts dot
Speaker 4: com and like start an extrass project, you can kind
Speaker 4: of get you can actually literally see how fast it runs, right,
Speaker 4: and the FPM installs are like five faster, And so
Speaker 4: it's like, how is that even possible?
Speaker 6: Right?
Speaker 4: How is it even possible that you could like take
Speaker 4: node put it in a browser and it's like faster
Speaker 4: inside of your browser than it is outside of your
Speaker 4: browser on local And so the answer is actually it
Speaker 4: was like, this is kind of the key realization that
Speaker 4: we had was that, you know Node, Like, if you
Speaker 4: go back to the origins of Node, they pulled V
Speaker 4: eight out of Chrome to bring it to local, right,
Speaker 4: But Google Chrome and all these other browsers they have
Speaker 4: their own jobs pretention, whether it's V eight or spider
Speaker 4: Monk or whatever. And so if you can actually write
Speaker 4: like a compiling tool chain that can take NOJS from
Speaker 4: source rip out va and actually use the existing JavaScript
Speaker 4: engine right in your browser, you don't have to drag
Speaker 4: along a lot of the gigantic stuff that usually comes
Speaker 4: along with that because it's already included. And the other
Speaker 4: benefit of that is that your browser is continually updating,
Speaker 4: getting faster and more secure while you sleep.
Speaker 3: Right local. With Node, they use.
Speaker 4: A specific pinned version of V eight with every release
Speaker 4: of Node, and so if you're using Node eight, you're
Speaker 4: using a version of the eight that is incredibly old
Speaker 4: and has lots of security vulnerabilities at this point. But
Speaker 4: by actually coupling it, you're with stack blitz, right, your
Speaker 4: environment actually gets faster and more secure while you're sleeping.
Speaker 4: And so what that actually kind of gives you, right
Speaker 4: is like with one copy of V eight. There's actually
Speaker 4: a huge inefficiency on local because if you think about
Speaker 4: web development, like what does it kind of look like?
Speaker 4: Usually you have no JS processes running, webpac or whatever
Speaker 4: have you, some end number of let's call it like
Speaker 4: five to ten processes that are running.
Speaker 3: So that's five to ten copies of the eight.
Speaker 4: There you have vs code open, which is Electron, which
Speaker 4: is therefore Chrome and has its own copy of the eight,
Speaker 4: and then you have Chrome open previewing your web app. Right,
Speaker 4: so all in all we're talking about a dozen plus
Speaker 4: copies of the eight running, which is hugely inefficient, and
Speaker 4: so by actually collapsing it all into save one in
Speaker 4: the browser, there's a there's a gigantic performance game you
Speaker 4: get from doing that. And so that's actually the main
Speaker 4: thing that that allows stack up to be faster than
Speaker 4: you than your local machine is that it's using one
Speaker 4: copy of V eight instead of dozens kind of all
Speaker 4: across these different processes or applications on your computer.
Speaker 6: So that is that brings me to a good question
Speaker 6: because typically when I'm using node it's because I have
Speaker 6: maybe like a create React app front end, a Node
Speaker 6: Express server back end. Can I build that in stack
Speaker 6: Blitz as well, something that serves up different files and
Speaker 6: routes to APIs and does all the typical things that
Speaker 6: you'd expect a UI to be able to do.
Speaker 3: Oh yeah, absolutely absolutely.
Speaker 4: So that's in our first market we're really going after
Speaker 4: with this technology is web development, and you can do
Speaker 4: all of that. So you can run pre react app
Speaker 4: with a separate because if you actually go to stack
Speaker 4: lis dot com, you don't because it's running on your computer.
Speaker 4: We don't make you log any So you can literally
Speaker 4: go there now start an next gs app or start
Speaker 4: a graph ql app and you actually see a terminal
Speaker 4: that pops ups. You can actually run multiple processes at
Speaker 4: the same time, just like you would on local and
Speaker 4: so you can be running create React app, Andi graph
Speaker 4: Cil server where they're like talking to each other and
Speaker 4: everything entirely inside of your brain and so like all
Speaker 4: of the sort of common workflows that you would be
Speaker 4: doing about development. Absolutely, like that's exactly what this thing
Speaker 4: is designed for.
Speaker 5: Yeah, it's I mean, this is super fascinating because it's
Speaker 5: just it enables a lot of stuff. Because you had
Speaker 5: said you'd worked with the next Jass team, if you
Speaker 5: talked with them at all, because I could totally see
Speaker 5: like embedible demos, like because like right now with next JSS,
Speaker 5: if you want to learn how something that has some
Speaker 5: sort of server component into it, like server rendering or
Speaker 5: something like that, like you can't they can't share a
Speaker 5: live example of that, right, Like they could share a
Speaker 5: GitHub repo, but the that's always a pain, right to
Speaker 5: download a get the hub repo, and like sometimes that
Speaker 5: involves some setup. Anytime there's a server, there's some sort
Speaker 5: of setup. But like I could totally see just embedded
Speaker 5: in their docs like here's here's the stack blitz instance,
Speaker 5: here's the like almost like here's your client sites code,
Speaker 5: here's your server side code, much like you'd embed like
Speaker 5: a code pen that shows how to make a dropdown
Speaker 5: work or something like that.
Speaker 4: Yeah, yeah, absolutely again and they so I think in
Speaker 4: there they've actually adopted this for their kind of the
Speaker 4: official examples in the next JS repo and docs whatever
Speaker 4: have you. So I think you if you actually browse
Speaker 4: to those and get up there's a lot of them.
Speaker 4: They have like these open and stackplts buttons where you
Speaker 4: can actually pop them open and then you can actually
Speaker 4: embed this stuff too.
Speaker 3: And so I think that the no JS documentation site.
Speaker 4: Actually I think just they've started embedding this, you know,
Speaker 4: like stack flitz projects because again, like compared to like
Speaker 4: there's these other online things that use vms like rappolit
Speaker 4: or Glitch, but sandbox, the problem is that when you
Speaker 4: actually embed them, they typically don't let you edit the
Speaker 4: code because they don't want to provision a VM for
Speaker 4: every person who's just browsing by the page, right because
Speaker 4: it's going to be way too expensive. And so with
Speaker 4: this model, like we can actually really give this out
Speaker 4: for free to everyone, which has been kind of an
Speaker 4: important thing from our perspective is that like this is
Speaker 4: coming back to the origins of why we did this.
Speaker 3: This is a huge upgrade from.
Speaker 4: The learning experience, right, and so we don't want this
Speaker 4: to be something that is payballed or like you have
Speaker 4: a whole bunch of hoops you have to go through
Speaker 4: to try and use it. That you should be able
Speaker 4: to just be able to be browsing. If I want
Speaker 4: to learn no JAS, I should be able to browse
Speaker 4: their documentation and have a live environment that's booting inside
Speaker 4: of my browser, right like without running into file watcher issues.
Speaker 3: Like that's twenty twenty one.
Speaker 4: This should be fixed by now, right, So that's that's
Speaker 4: actually a really a really key thing that you like.
Speaker 4: The learning angle, I think is a huge area where
Speaker 4: this technology actually really improves the experience substantially.
Speaker 6: I think that that's fantastic. One question that I have
Speaker 6: is how how do people like Because I haven't used
Speaker 6: it myself, but how do people like the environment set up?
Speaker 6: Because I know that everybody who has their vs code
Speaker 6: instance has like you know, they're prettier formatting their es
Speaker 6: lant setup, their kid ignore, get lens or all the
Speaker 6: stuff that they've got plugged in, So how do you
Speaker 6: handle that and all the particulars that people like to
Speaker 6: kind of tweak and set for their own own development.
Speaker 4: No, really, it's a very good question. That's actual what
Speaker 4: we're working on now. So basically today we've got kind
Speaker 4: of this script down version of vs code. This is
Speaker 4: that it we designed to be very fast from the
Speaker 4: get go, and this is actually the same editor we've
Speaker 4: launched with like five years ago, and so this is
Speaker 4: before we had the ability to.
Speaker 3: Just execute arbitrary and no JS programs in the browser.
Speaker 4: Right now, Actually, what's what's kind of cool is that
Speaker 4: if you can run no JS in a browser when
Speaker 4: you actually look at bs code and what like what
Speaker 4: makes vs code extension Like technically like what is a
Speaker 4: bs code extension? They're all actually just no JS pro
Speaker 4: And so what we're actually drilling into right now, I
Speaker 4: think we're it's looking like cloud this out sometime in
Speaker 4: the next quarter, is that you're at we actually able
Speaker 4: to run vs code wholesale inside of the browser, including
Speaker 4: running just arbitrary extensions. And so so I think the
Speaker 4: ultimate solution we see to exactly what you're describing, because
Speaker 4: that is totally a really important point for us to nail.
Speaker 4: It's like, actually, you'll be able to install all the
Speaker 4: same extensions that you use today and configure it exactly
Speaker 4: how you want. And what's kind of cool about is like,
Speaker 4: because this is it is a cloud networked idea. It's
Speaker 4: it's using your brows to do the work. But that
Speaker 4: will sink automatically whether you use you're on your iPad
Speaker 4: or your laptop at your mom's house or whatever. Right like,
Speaker 4: it'll actually just kind of work out of the box
Speaker 4: because it's it's just like any other just like Big
Speaker 4: More or Google Docs. You know, your setting is just
Speaker 4: kind of by the fall, they're going to persist across.
Speaker 4: So yes, that's kind of that. That's that's how we're
Speaker 4: trying to address that stuff, and it's actually working. It's
Speaker 4: actual pretty cool. We actually literally just got vis code
Speaker 4: kind of fully mounted, like I think it's like last
Speaker 4: week or something on top of web continue.
Speaker 3: We haven't announced that yet, but like, but that's like
Speaker 3: so sneak sneak peak.
Speaker 5: Exactly exactly. That's really cool.
Speaker 2: How do you get around the browser security limitations? I mean,
Speaker 2: if you're going to open up a port for your
Speaker 2: next chain, and how does that actually work?
Speaker 4: Yeah, it's so that was actually kind of one of
Speaker 4: the key things that we had to figure out is
Speaker 4: so to be clear, it actually doesn't break out at
Speaker 4: the security sandbox at all, which is actually a big feature,
Speaker 4: right because there's actually to just do kind of a
Speaker 4: quick as side on that. It's like security is actually
Speaker 4: on the big things that we see as the benefit
Speaker 4: of this approach, right because what's what's going on in
Speaker 4: the market right now is that we actually have nation
Speaker 4: states that are attacking US and other companies countries and
Speaker 4: actually the weakest link right now because they previously they
Speaker 4: would try and brute force into your database or something
Speaker 4: like that. But that stuff's gotten pretty secure. The weakest
Speaker 4: link now is actually the developers who are writing the
Speaker 4: software for your bank's website, right because if you can actually,
Speaker 4: if you can actually get them to download a malicious
Speaker 4: package and then run that on their computer, then you
Speaker 4: have access to everything. So you actually have to brute
Speaker 4: force into the into the database whatever you usually had,
Speaker 4: you know, get one of the devs to install. You
Speaker 4: think about an MPM install, You're talking about thousands of dependencies.
Speaker 3: So how hard is it to actually do that?
Speaker 4: Well, the answer is not hard, and that's exactly what's
Speaker 4: happened with solar ones and all these other things going on.
Speaker 4: So but in stacklets, because it's actually not breaking out
Speaker 4: of the security sandbox, it actually gives this step function
Speaker 4: upgrade security because you can install the worst virus ever MPM,
Speaker 4: and is all you have to do is just hit
Speaker 4: command W and close your browser tack like they cannot
Speaker 4: go and scrape it can't go anywhere, it can't go
Speaker 4: and scrape your SSH keys. Because of the browsers built
Speaker 4: in network restrictions, you're you're not going to be able
Speaker 4: to like upload that to some random endpoint, right, So
Speaker 4: it actually gives you a really really amazing security guarantee.
Speaker 4: And this is actually stacklets as a business. What we
Speaker 4: sell is we actually sell stacklets that runs behind the
Speaker 4: firewall at these gigantic banks, fintech, government, healthcare, et cetera,
Speaker 4: that are the subject of these sorts of attacks right now,
Speaker 4: right and so anyways, so and so like how that's
Speaker 4: possible that we don't break out the standbox. And so
Speaker 4: for networking specifically, what we actually ended up building was
Speaker 4: this TCP networking, virtualized TCP networking stack inside of the
Speaker 4: browser where it actually maps the like no.
Speaker 3: Just TCP calls to the service worker API.
Speaker 4: So like when you actually spin up a server in stacklts,
Speaker 4: what's actually going on is that there's this virtualized TCP
Speaker 4: network stack that's actually translating that into service work or
Speaker 4: requests response, right, and so it actually what's kind of
Speaker 4: cool about that again from a security angle, like that
Speaker 4: is only accessible to that browser instance. So if I
Speaker 4: if you go to stacklets and you start an next
Speaker 4: JSS project, you take the URL of the dev server
Speaker 4: and put it into like Safari or Firefox, you can't
Speaker 4: actually access that server right, And that's another attack factor
Speaker 4: where people will actually when they install something on your computer,
Speaker 4: they'll actually start scraping your local host URLs to try
Speaker 4: and grab crudentials from your development life cycle. And so
Speaker 4: that's it's just like another angle of like by running
Speaker 4: it in the browser, it's faster, it's more secure, it's
Speaker 4: way more affortable. It's just like a much better development experience.
Speaker 5: Yeah, yeah, it's funny. I used to work at a
Speaker 5: hosting company and we had we we didn't do our
Speaker 5: development and our actual machines for those exact same security considerations.
Speaker 5: We would ssh into these Linux boxes where all our
Speaker 5: development stuff would run, just because it was an isolated layer.
Speaker 5: But obviously constantly having s sh into everything is also
Speaker 5: not the world's greatest experience. So I could see like
Speaker 5: some value of having like a standard sort of environment
Speaker 5: built in to get the security benefits and the developmental
Speaker 5: benefits as well.
Speaker 2: Yeah, when I think about like onboarding to a new
Speaker 2: like into a new gig, it's like usually three days
Speaker 2: or whatever to like get up on the code base
Speaker 2: but also get the development environment set up. And some
Speaker 2: folks have used like Docker for dev, which has made
Speaker 2: that a lot easier, right because everything's kind of all
Speaker 2: the right version of node and all that, and then
Speaker 2: this is even that much easier. You literally just go
Speaker 2: with your browser and it's good out.
Speaker 6: That brings up a question though, if you're doing this
Speaker 6: development in stacklitz, is their version control like you could
Speaker 6: get in GitHub if you accidentally delete something or is
Speaker 6: there or how how do I deploy this if I'm
Speaker 6: already accessing it in a browser? How do I change
Speaker 6: it from local hosts or whatever the development environment is
Speaker 6: to you actually put this out on the rest of
Speaker 6: the public web.
Speaker 4: Yeah, yeah, so that's we have a minimal get integration
Speaker 4: right now. It's like it's very alpha. We have like
Speaker 4: a very we have a huge update that's can be
Speaker 4: coming out next quarter where it basically because right now
Speaker 4: we're kind of in the phase of still solidifying the
Speaker 4: core technology, make sure all the frameworks out there kind
Speaker 4: of run properly on this thing, and you know, et cetera,
Speaker 4: et cetera. And the next step after this is like
Speaker 4: allowing you to actually integrate this with your production workflows,
Speaker 4: so you'll actually be able to just like open up
Speaker 4: a stat right now. Actually, if you on any get
Speaker 4: up URL if you just add the word blitz after
Speaker 4: get up, so get up blitz dot com slash repo,
Speaker 4: it'll you can kind of get an idea of a
Speaker 4: little taste of what is going to look like.
Speaker 3: But effectively, any git RepA you have.
Speaker 4: You're gonna be able to pull it in and mount
Speaker 4: it instantly and be doing you know, working and committing
Speaker 4: back and reviewing, poll recross and that sort of thing.
Speaker 4: And so that's like version controls actually be the really
Speaker 4: the most first class integration. And of course with that
Speaker 4: you have cis for things like now and other like
Speaker 4: hosting providers where you know, it'll whatever tool tools you
Speaker 4: have set up for hosting, it'll it'll kind of work.
Speaker 3: There.
Speaker 4: We even another integration we're going to be doing where
Speaker 4: well anyways, that's again in that but like that's I
Speaker 4: think the short of kind of how that stuff is
Speaker 4: going to work.
Speaker 3: And I think what's cool.
Speaker 4: So when you kind of talk about that, right, what's
Speaker 4: cool about being having this like white conaers be able
Speaker 4: to mount any get branch or repo is that you
Speaker 4: know on local one of the biggest pain points is
Speaker 4: like when when you have like a colleague that's like, hey,
Speaker 4: like you check out this branch really quick and like
Speaker 4: see if this thing works right, and you're like in
Speaker 4: the middle of something, you're like, oh my god, I'm
Speaker 4: gonna have to like stash all my changes or I
Speaker 4: committed up. It's like this whole thing right with this model,
Speaker 4: you can actually crack open a whole nother cop You
Speaker 4: can open up dozens of copies of your code base
Speaker 4: and be running them at the same time without having
Speaker 4: to switch branches locally. So it's kind of like the
Speaker 4: seamless workload. It's like, hey, can you check this thing out? Sure,
Speaker 4: click a lig boom, your boots up, you check the
Speaker 4: thing out. Ball, you can commit to that branch. Meanwhile,
Speaker 4: your work over here is still there and you don't
Speaker 4: have to switch branches, right, So it just it is
Speaker 4: this whole friction point around. You know, on local you
Speaker 4: really have to like it's a very manual task, kind
Speaker 4: of like making sure your get your your get situation
Speaker 4: is clean and like you're not losing work and like
Speaker 4: you're when you switch branches, where is that going. It's
Speaker 4: like that the whole workflow stuff really gets a lot
Speaker 4: easier when you can actually just have in fresh, isolated
Speaker 4: environments on demand that they're actually running on your local
Speaker 4: computer and not on like some cloud thing.
Speaker 3: Right.
Speaker 6: Yeah, that's a huge selling point for me actually because
Speaker 6: I do this, I have to do this at work
Speaker 6: right now if I want to look at somebody's changes,
Speaker 6: but at previous places that I have worked, We've set
Speaker 6: up these massive Jenkins flows which will when somebody pushes
Speaker 6: to a PR branch or to a feature branch, it
Speaker 6: will automatically pick it up and build it and deploy
Speaker 6: it into some dev or staging environment, so you can
Speaker 6: at least look around, but not having to pull down
Speaker 6: changes locally to actually make tweaks and see what it
Speaker 6: looks like and still be on my branch that I've
Speaker 6: been working on a story on would be awesome. That
Speaker 6: to me is a huge that would be that'd be
Speaker 6: really really cool totally.
Speaker 4: That's kind of what we're like what we're eyeing for
Speaker 4: as well, because I think that's like that's almost the
Speaker 4: that's like the to me, it's the most useful, like
Speaker 4: you know, other than just like it's it's a great
Speaker 4: development environment. It's like that's something where like even if
Speaker 4: I want to continue using my local environment as my
Speaker 4: primary way having just like you have a preview link
Speaker 4: for you know on netlifire or whatever on a PR
Speaker 4: want to be just as useful and sometimes even more
Speaker 4: so to have a dev environment live, like a live
Speaker 4: devon environment preview, we could pop it out and not
Speaker 4: only just preview but actually like make changes and just
Speaker 4: commit the back to the branch.
Speaker 5: Right.
Speaker 4: That's I think that's like it's kind of this crazy
Speaker 4: part of the workflow, right where if you think about it,
Speaker 4: a lot of like what get up does really well
Speaker 4: or just like these these Birge control providers now they
Speaker 4: actually allow you to do a lot of your workflow
Speaker 4: in the browser, right, And the main place where you
Speaker 4: have to kind of like where you have there's this
Speaker 4: sharp drop off of being able to work in the
Speaker 4: browser is when you have to open it up, review it,
Speaker 4: make changes, et cetera. So I think this is kind
Speaker 4: of like completing that workflow then because you can actually
Speaker 4: like do the development in the browser, make the PR
Speaker 4: in the browser, have the PRB reviewed in the browser,
Speaker 4: and ran in the browser, right, So it's like there's
Speaker 4: not this just hard context which every time you're in
Speaker 4: that part of the process. So yeah, I agree, our
Speaker 4: our team kind of agreece. We're like, God, we need
Speaker 4: this thing ourselves.
Speaker 5: I'm curious, so you say you do deployees of this,
Speaker 5: like internal deploys for companies. When you do that, do
Speaker 5: you ship like as an electron app or is it
Speaker 5: just more just like a privately hosted thing that still
Speaker 5: runs in the browser. And it's sort of a leading
Speaker 5: question because I could say that my still biggest remaining
Speaker 5: concern with online editors is I don't like how the
Speaker 5: keyboard shortcut conflict, like because when you're still running in
Speaker 5: a browser, the browser is still going to eat a
Speaker 5: lot of keyboard commands that I want the editor to
Speaker 5: actually get instead, and you can't really override those. So
Speaker 5: I'm curious how you've you've dealt with that in what
Speaker 5: your thoughts are around that.
Speaker 3: Yeah, so you actually can override them.
Speaker 4: So that's actually that was actually one of the big
Speaker 4: things that convinced us that this was that we could
Speaker 4: you know, because I agree with you, like that's always
Speaker 4: been the worst like all the previous online ideas that
Speaker 4: have existed. Of course they're using cloud vms to do
Speaker 4: this stuff with just slow and expensive whatever, but also
Speaker 4: the experience is like you hit command W and then
Speaker 4: like your editor goes away and you're like, oh, yeah,
Speaker 4: I did not mean to do that, but like my
Speaker 4: I'm trained, I have muscle.
Speaker 3: Ever it right.
Speaker 4: And so what actually the key thing that enables this
Speaker 4: is desktop PWAs. So if you actually install staflets or
Speaker 4: i mean any other desktop ped of BA when it's
Speaker 4: actually in the installed mode, you actually can override every
Speaker 4: key binding command W command, T command.
Speaker 5: And all of that.
Speaker 4: Actually just like a desktop app, and of course it's
Speaker 4: a desktop PWA, you lose the url bar, it looks
Speaker 4: and functions like a desktop app. You have an icon
Speaker 4: on your dock. So the delta actually between what you
Speaker 4: can do with a PWA and an electron app that
Speaker 4: that delta is like now approaching zero. And on top
Speaker 4: of that, the other thing too is like the Chrome
Speaker 4: actually shipped the native file system AP last year, so
Speaker 4: it actually gives web apps the ability to open a
Speaker 4: piece of your file system, whether it's a folder or
Speaker 4: a specific file or whatever, and give the web app
Speaker 4: read and write access to it. So one of the
Speaker 4: things with with web container and stack that's it's interesting
Speaker 4: is like part of the vis code rollout we're doing. God,
Speaker 4: I'm like just spilling the beans. But like basically the
Speaker 4: short of it is like to your point, like, if
Speaker 4: this thing can feel like a desktop editor and it
Speaker 4: can actually mount folders already on your computer, you could
Speaker 4: actually use this as your primary editor and you really
Speaker 4: wouldn't know the difference except for the fact that it
Speaker 4: automatically sinks all of your settings and it's like somehow
Speaker 4: way faster and you know, YadA YadA, YadA, Right, And
Speaker 4: so that's that's actually like kind of the key thing
Speaker 4: that we see is like really enabling this to like
Speaker 4: work in a meaningful way.
Speaker 5: Yeah, it took until I've long been a naysayer of
Speaker 5: web based editors, like for more than like for tinkering great, right,
Speaker 5: but it's a long time software developer, Like it was
Speaker 5: always like, oh but it's it's clunky and it's like
Speaker 5: my real editor. And it took vs code to like
Speaker 5: convince me that like, oh crap, like this is actually
Speaker 5: really good, really fast, and this is all web based,
Speaker 5: so there's there's no reason at this point this can't
Speaker 5: be done. And the browser like this, the speed is there.
Speaker 5: It's just solving these like last mile type of things
Speaker 5: to make it possible.
Speaker 3: Yeah, exactly exactly, and it's been a long time coming.
Speaker 3: I mean it's like and this is kind of like.
Speaker 4: You know, almost like the first minute where you could
Speaker 4: kind of be doing something like this because I mean
Speaker 4: a lot of the APIs that we rely on didn't
Speaker 4: exist a couple of years ago, and some of them,
Speaker 4: like with the web assembly threads and whatever, I mean,
Speaker 4: they're still kind of figuring out how to enable this
Speaker 4: in all browsers, right, So it's kind of like we're
Speaker 4: we're at this is like the I think this this
Speaker 4: is gonna be an interesting decade for this industry. I
Speaker 4: think because the web is i mean, the web is
Speaker 4: powerful enough to like write the web like that's kind
Speaker 4: of the key.
Speaker 3: That was the thing that blew our minds.
Speaker 4: We're like, this is the first time you can actually
Speaker 4: like that's kind of if you talk to people who
Speaker 4: have built, you know, stuff for platforms before. The two
Speaker 4: biggest stress tests of any platform is one video games, right,
Speaker 4: because you're talking about an incredible number of calculations that
Speaker 4: are happening right typically at that and you're seeing a
Speaker 4: lot of browsers supporting video games now right, like a
Speaker 4: lot of browsers starting to move into a lot of
Speaker 4: games and movies in the browser. And the second one
Speaker 4: is IDEs because you're you know, the platform has to
Speaker 4: be powerful enough and have sufficient API surfaces to actually
Speaker 4: let you use the platform to build applications for the
Speaker 4: platform itself, right, And so this is actually like the
Speaker 4: first time we've been able to do that for the web. Right,
Speaker 4: this is like a story thirty years in the making
Speaker 4: where you've never been able from a technical standpoint to
Speaker 4: use a browser to write applications for the browser without
Speaker 4: a server or something involved.
Speaker 3: Right.
Speaker 4: But that's like cheating, you know, because it's like that's
Speaker 4: it's like going to an IBM mainframe to compile an
Speaker 4: iPhone app or something. Right, It's like it's not it's
Speaker 4: not running on that same device. So anyway, so like
Speaker 4: that's that's I think what's kind of crazy is I
Speaker 4: think that that is historically that's an important moment for
Speaker 4: any platform because then that means there's going to be
Speaker 4: an explosion of new types of applications that weren't possible
Speaker 4: for right, and an explosion of applications period because the
Speaker 4: friction has gotten a lot lower. Yeah, anyways, interesting time
Speaker 4: to be in the web development space. I think it's
Speaker 4: I think we're just we're just getting started.
Speaker 2: So you mentioned education as kind of the impetus for this,
Speaker 2: and I'm a very interested in that myself. I've done
Speaker 2: a lot of work in like fourth grade classrooms, IoT
Speaker 2: type stuff. And then also, you know at high school level,
Speaker 2: I mean the issue always is they've got chromebooks, right,
Speaker 2: and what can you do on a chromebook? You know
Speaker 2: you can do the little IoT things for sure, dragon
Speaker 2: drop this and that, but like, can can this now
Speaker 2: work on a Chromebook? Can I go teach these kids?
Speaker 5: React? Because I'd love to.
Speaker 4: Do Oh yeah, oh yeah, absolutely absolutely right, Like I
Speaker 4: think that's like so we actually test against the worst
Speaker 4: of these devices, like you know, like, yeah, it's a
Speaker 4: no joke. I've got this six year old I think
Speaker 4: it's like I think it's like one point two gigahertz
Speaker 4: sort of mobile Intel process service, gig of ram maybe right,
Speaker 4: It's it's just this terrible absolutely, like it's difficult to
Speaker 4: just type in to sign into Google on the sort
Speaker 4: of like level, right, And and so we actually, you know,
Speaker 4: when we were building this, we had no idea, like
Speaker 4: you know, we like we work a lot with like
Speaker 4: the Crown team, and like Google's Ventures is actually an
Speaker 4: investor in our company. So we've got great relationship these folks,
Speaker 4: and even you know, the people we talked to, they're like,
Speaker 4: maybe it should work, like we really no one's ever
Speaker 4: done this, right, like you know, so and you know,
Speaker 4: that was kind of a big question for us, is
Speaker 4: like if this only is going to work on MacBook
Speaker 4: pros with sixteen gigs of RAM and YadA YadA, that's
Speaker 4: that's kind of that's not it's not gonna fit our
Speaker 4: solution criteria. But to our surprise, again because of the
Speaker 4: efficiency of the model of one copy of the A
Speaker 4: and a whole bunch of other stuff that we do
Speaker 4: to make it, you know, insanely fast and efficient. It's
Speaker 4: actually the first time you can even run these tool
Speaker 4: chains on those sorts of devices and and so you
Speaker 4: can actually run create react app, next gs, et cetera
Speaker 4: on these like just wimpy devices, and it's kind of
Speaker 4: kind of incredible and and you know, it's certainly slower
Speaker 4: than my back, but it's actually faster than the other
Speaker 4: online on used to use a vamp to do the work.
Speaker 4: So that's like been like that was for us. That's
Speaker 4: like the second we saw that, we're like, this is
Speaker 4: we're going all in on the strategy because you know,
Speaker 4: every every K tell you know, K through twelve school
Speaker 4: and even colleges can use this for free. And again
Speaker 4: that's always been the problem with schools is they don't
Speaker 4: have the money to pay for this stuff typically right exactly,
Speaker 4: and and we don't have to flip the bill, like
Speaker 4: all we're paying is the same, Like we have a
Speaker 4: million something developers that use Stack what's every month, and
Speaker 4: we pay I think like eight or a bucks total
Speaker 4: on our edile.
Speaker 2: Because the computing is all done on the edge.
Speaker 3: It's exactly.
Speaker 4: Exactly exactly, and so it's just this transient electricity cost
Speaker 4: users paying, which is effectively nothing. And so the model
Speaker 4: just works out really well. Where you know, from from
Speaker 4: people in K twelve who are just learning how to
Speaker 4: code all the way to like Fortune fifth, where they're
Speaker 4: like writing the software that you know we used to
Speaker 4: wire money, right, is like it kind of this this
Speaker 4: kind of technology can actually span that entire that entire category,
Speaker 4: which is kind of rare, Like it's not often that
Speaker 4: you see something that can kind of accommodate.
Speaker 3: All those use cases to allegany right.
Speaker 5: Yeah, when we talk education, our minds usually go to
Speaker 5: like fourth graders or young kids. But there are a
Speaker 5: lot of companies that spend a lot of money on
Speaker 5: training there they're not fourth grade employees to get up
Speaker 5: to speed in the technology. And would gladly welcome anything
Speaker 5: that cuts down on that, right, that that automates things
Speaker 5: that previously they had to teach and have processes around
Speaker 5: and all that sort of thing, or that twelve hours
Speaker 5: onboard somebody, right, yeah, yeah, exactly, and it might.
Speaker 6: Lower your your cost for actually outfitting a new employee.
Speaker 6: Because I can't do development except on a Mac. That's
Speaker 6: how I've learned, and that is what I will die
Speaker 6: in the grave knowing. I refuse to even try Windows
Speaker 6: or Linux. So one question that we have, in addition
Speaker 6: to all the devices that it can run on, can
Speaker 6: it run on different web platforms? Can it run on
Speaker 6: or yeah, Microsoft Edge? Can it run on Chrome probably obviously?
Speaker 6: Can it run on Firefox? Is it compatible across all those?
Speaker 1: Yeah?
Speaker 3: Yeah, good question.
Speaker 4: So yeah today it runs on Chrome and Edge like perfectly,
Speaker 4: and on Safari it requires a canfig flag not smart
Speaker 4: I'm fire Firefox actually, now Firefox Asafari requires a config
Speaker 4: flag like a run time can fig flag. And so
Speaker 4: actually the big issue that we built all this stuff
Speaker 4: on top of web standards and so like it should
Speaker 4: absolutely work on all these things. There's no platform specific
Speaker 4: APIs that we're using to make the core of this
Speaker 4: functionality work. There's actually what what kind of happened is
Speaker 4: after the spectrum meltdown stuff. You all probably kind of
Speaker 4: heard about this, like the shared ray buffers, and they've
Speaker 4: been trying to figure out how to bring them safely
Speaker 4: back to the web. And this is an application that
Speaker 4: has to use share a ray buffers. There's no other
Speaker 4: way to do what we're doing than having a shared
Speaker 4: memory with atomic right locket right. And so because of that,
Speaker 4: we're kind of blocked by the Chrome is kind of
Speaker 4: always at the bleeding edge of this stuff, and so
Speaker 4: you know them and therefore edge because edges, you know,
Speaker 4: kind of is chromium. Now that stuff works fine. I
Speaker 4: think Firefox Firefox is actually uh is darn close. Safari
Speaker 4: is just kind of doing their own thing, but they
Speaker 4: usually come around given enough time. But you know, so
Speaker 4: that's that's kind of where where it lays. But I
Speaker 4: think probably within the next six to maximum twelve months.
Speaker 4: I think it's like you're gonna be able to open
Speaker 4: this up on like your iPhone and like be elect
Speaker 4: you run an OJS on your iPhone in a browser,
Speaker 4: which is like kind of kind of insane to think
Speaker 4: about on our web page and it's like cool, like
Speaker 4: that's that's running on my phone.
Speaker 5: So I'm very curious how this works though, because you
Speaker 5: described it earlier as being like what you're shipping is
Speaker 5: like a rere almost like a way of communicating with
Speaker 5: the V eight that's already there, but in Firefox, VA
Speaker 5: isn't there, and your iPhone V eight isn't there, So
Speaker 5: how is that working on those browsers?
Speaker 4: So yeah, So basically what we've kind of done with
Speaker 4: that end of it is like all of these different
Speaker 4: like and if you look at like node and den
Speaker 4: and any of these alternative jobs for runt times that
Speaker 4: are out of the browser, right, what they do is
Speaker 4: they take the eight, which will provides you with all
Speaker 4: the stuff you need effectively to run a job is prevenure,
Speaker 4: but it does not include any of like the built
Speaker 4: in stuff you know that your browserships with, Like if
Speaker 4: you want to have a new date function that doesn't
Speaker 4: ship with the A you have to like provide your own,
Speaker 4: right or if you want to say new URL that
Speaker 4: you know you all these different things have to be included.
Speaker 4: And so essentially like that's actually the kind of the bulk,
Speaker 4: and there's more to it than that, but effectively like
Speaker 4: the bulk of when you actually look at NOE, it's
Speaker 4: like this stuff is already available in every browser because
Speaker 4: this stuff is standardized, right, and the stuff that isn't standardized,
Speaker 4: what we end up doing is compiling it out to
Speaker 4: web assembly or other and and allow it to run
Speaker 4: like that, right.
Speaker 5: Interesting, So then are there specific node versions you support?
Speaker 6: Then?
Speaker 5: Is that something you can like select with instat blots.
Speaker 1: Yeah?
Speaker 4: Yeah, So so today we're like, I think the version
Speaker 4: where is like version fourteen, I can't remember the subversion,
Speaker 4: but we've got at one pin version where we're kind
Speaker 4: of battle testing the tech ology on. And then once
Speaker 4: we're once we're out of beta on this thing, we're
Speaker 4: going to be adding I think we're the current planet
Speaker 4: that we're going to be doing LTS releases, So like
Speaker 4: every LTS release from fourteen on, you know you'll be
Speaker 4: able to use on stock puts. But yeah, so that
Speaker 4: that's kind of the idea, is that we're gonna have
Speaker 4: a list of versions of you that you'll be able
Speaker 4: to use here.
Speaker 5: Okay, nice. So how about end end testing?
Speaker 2: So if I am building my app and I've got
Speaker 2: my unit test running and all that, how do end
Speaker 2: end testing is gonna try.
Speaker 5: And hit those URLs?
Speaker 2: Is that is that going to sit on that same
Speaker 2: emahilation layer You mentioned that externally accessible outside the browsers,
Speaker 2: so that's an issue.
Speaker 4: Yeah, well so it depends on like we say, and
Speaker 4: then are you thinking like Cyprus something like that basically?
Speaker 5: Yeah, yeah, so.
Speaker 3: What's Yeah, what's kind of cool is that?
Speaker 4: And so this is part of part of the story
Speaker 4: that we're making the path really smooth for this because
Speaker 4: it's like that's it's a really good question, like unit
Speaker 4: testers are he's like just runs in white container today
Speaker 4: of course, like with no problem. But yeah, but yeah,
Speaker 4: like end to end test. Uh, it's actually kind of
Speaker 4: it's kind of cool because so they're in the sky.
Speaker 4: I think names glab over At he was at Cyprus
Speaker 4: when he was kind of digging into this. But because
Speaker 4: like all Cypress really does, right, is it just remotely
Speaker 4: controls the CROL instance, you know, to open a page
Speaker 4: and like do a certain action, whatever have you. So
Speaker 4: what's what's kind of interesting about that though, is that
Speaker 4: if you can actually run the entire deb environment into browser,
Speaker 4: then you can actually write end to end tests that
Speaker 4: not only are testing the end website functionality, but when
Speaker 4: you think of something like next JS that is again
Speaker 4: blurring the line between server and front end, you can
Speaker 4: actually use Cyprus to mock like like you know, intercept
Speaker 4: EPI data that is going to be server side part
Speaker 4: of next GAS and then run an end to end
Speaker 4: test against the entire full stack environment.
Speaker 3: Oh right, so this actually whoa, which is It blew
Speaker 3: my mind because I'd never thought of that. When Leb
Speaker 3: posts on Twitter, is like, holy heck, like that is ye.
Speaker 4: Yeah, because that's kind of like that that was the moment,
Speaker 4: you know, that was just one of those moments where
Speaker 4: it was like and there was like a month after
Speaker 4: you launched the thing he went posted that. I was like,
Speaker 4: holy cow, Like that's actually incredible because how else would
Speaker 4: you like in any sane way test out a server
Speaker 4: side rendered application where you want to mock the data
Speaker 4: and the database calls or whatever they're happening on the
Speaker 4: back end side and get the same reproducible result. Right
Speaker 4: right now, you can use cypress to do that effectively.
Speaker 4: Now how that ties in with all this other stuff?
Speaker 4: You know, I will kind of figure out, like how
Speaker 4: is it super easy because we can't necessarily call out
Speaker 4: to cypress and stacklets, but like we're working with their
Speaker 4: team on like a way to where we could potentially
Speaker 4: do that. But if you're actually running a locally or NCI,
Speaker 4: it's actually like this actually lets you enables this kind
Speaker 4: of crazy new capability that just wasn't possible before.
Speaker 5: That is super cool. Yeah, it's almost like you have
Speaker 5: to reconsider the mocking question altogether because right now there's
Speaker 5: all sorts of U search this on Google. You can
Speaker 5: find a million articles and best practices, But this gives
Speaker 5: you like another realm of possibilities. So I almost feel
Speaker 5: like it's a reckoning if this is in place that
Speaker 5: you have to reconsider best practices and what you because
Speaker 5: what you can do is changed, so now what you
Speaker 5: should do has to change as well.
Speaker 3: Yeah, yeah, exactly.
Speaker 4: That's kind of like a whole new, whole new world
Speaker 4: of like just kind of different like once you once
Speaker 4: you're going to run the you know, all these environments
Speaker 4: just inside of like the same tools that we're using
Speaker 4: today to write end and tests. It's like kind of
Speaker 4: like what does that mean and how does that allow
Speaker 4: us to write more reliable software?
Speaker 1: Right?
Speaker 3: It's like I think I think we're just kind of
Speaker 3: scratching the surface of some of the stuff that's going
Speaker 3: to be possible.
Speaker 6: So I think the next thing that people are going
Speaker 6: to start asking you about is can you support typescript
Speaker 6: and when are you coming out with the Python integration
Speaker 6: so we can start writing Jango and flask aps.
Speaker 4: Typeescript works, yeah, type script fully works, like and you
Speaker 4: can you can use these things like ts node where
Speaker 4: there's actually one that's kind of popped up reasoning called
Speaker 4: typescript run and basically you know, you can actually override
Speaker 4: the node run times to support typescript effectively, so like
Speaker 4: anything you do on local for no Jazz based stuff
Speaker 4: effectively will work there, yeah.
Speaker 3: Regarding other languages.
Speaker 4: So that's actually something that we're that's kind of the
Speaker 4: after we solidify support in this in just the no
Speaker 4: JS ecosystem, that's kind of where we're going next.
Speaker 3: And we I think we'll actually have some stuff to
Speaker 3: share by the end of the year.
Speaker 4: Actually, we've been kind of digging into Python and Rust
Speaker 4: and Ruby and things like that, so I think we'll
Speaker 4: actually have some some concrete updates from that and that
Speaker 4: are pretty cool, because yeah, I think this is the
Speaker 4: idea year is it's like this could really work for any.
Speaker 3: Language, not just like job script or not or.
Speaker 5: How though, because isn't something like because a lot of
Speaker 5: this is premise stuff being web based, right, because the
Speaker 5: fact that the browser has certain infrastructure in here. So
Speaker 5: I'm curious how other languages would play into this or
Speaker 5: even be like theoretically possible.
Speaker 4: Yeah, so this is this is the interesting stuff, Like,
Speaker 4: this is the stuff that we're still shipping away ad
Speaker 4: so we actually there's a group called the Bicode Alliance
Speaker 4: that is it's a contortion of companies, and stack Puts
Speaker 4: is actually one of the loving companies, whereas it's like Microsoft, Google,
Speaker 4: Fastly Arm, et cetera. And so they're actual really the
Speaker 4: kind of the point of this group is actually to
Speaker 4: solve this problem. And one of the key things that
Speaker 4: that's been put out from the Bicode Alliance is the
Speaker 4: Web Assembly System interface. You might have seen this over
Speaker 4: the past couple of years, but essentially it's a standardized
Speaker 4: interface that lets you do system level calls in web assembly.
Speaker 3: And that's really a lot of the problem when you kind.
Speaker 4: Of look at porting these different tool chains to run
Speaker 4: in web assembly is that they're they're using these native
Speaker 4: API surfaces that are are real estately not going to
Speaker 4: ever ship in a browser, nor should they. And also
Speaker 4: part of the deal is like, we need to improve
Speaker 4: the security of our software period because we're just we're
Speaker 4: in a really bad situation right now where deb environments
Speaker 4: are very easily exploitable and we've got to solve it right,
Speaker 4: and so web assembly provides a way to do that,
Speaker 4: but we also don't want to give up the security
Speaker 4: benefits that provides. So web the loss of the interface
Speaker 4: is actually really well designed to provide all those sorts
Speaker 4: of things that you need for filesystem, networking, et cetera,
Speaker 4: but actually in a way that's like a lot more
Speaker 4: secure than how it currently works locally. So that's kind
Speaker 4: of the current The current way that this is working
Speaker 4: is that, and there might be other stuff that comes
Speaker 4: along that kind of improves it, but that's you can
Speaker 4: actually run a lot of languages today in in web assembly,
Speaker 4: using LASSI as the primitive albeit without crazy support for
Speaker 4: like Jango would be a good example of like you
Speaker 4: could run Python US, but like Jangle requires and stuff
Speaker 4: that might not necessarily be working yet. But that's actually
Speaker 4: like kind of the long term plan. So we're working
Speaker 4: with all those folks to kind of help build the
Speaker 4: future of this thing out.
Speaker 5: So speaking of that, I guess what are like the
Speaker 5: short term plans? Right now? You have the beta flag
Speaker 5: and web containers. When do you expect this to be
Speaker 5: like production ready? Is this ready? If if your average
Speaker 5: developer working for your average company is listening to this,
Speaker 5: should they try it out? Are they ready to like
Speaker 5: just tinker for now and wait for production? What would
Speaker 5: you recommend?
Speaker 3: I think for now, like, I think there's actually like well,
Speaker 3: I think the using in production workloads we're shooting to
Speaker 3: land by the end of the year.
Speaker 4: Here, I think the interra what this is useful for
Speaker 4: today is interactive documentation, so rapid learning. Right, we see
Speaker 4: a lot of design systems actually use stack blits for
Speaker 4: this purpose, like because Bub's getting anty grady, but effectively,
Speaker 4: when you have a design system, your design system is
Speaker 4: only as good as how how easy it is to adopt, right,
Speaker 4: and so having interactive documentation makes that a lot easier.
Speaker 4: Also for bug reproductions, having a live environment is super
Speaker 4: useful for reprowing stuff, so we see a lot of that,
Speaker 4: and of course just rapid prototyping. This is like kind
Speaker 4: of like a codepen plus plus plus plus sort of
Speaker 4: thing like that use case totally works today, and so
Speaker 4: I think from those angles, right, I think that's that's
Speaker 4: where we're seeing a lot of pickup from Like next
Speaker 4: Gess is embedding this to their docks, Bite is using
Speaker 4: this for their issue tracker, et cetera. I think that's
Speaker 4: where people can really use this today, and that's actually
Speaker 4: helping us solidify the core run time stability by actually
Speaker 4: testing this across uh, you know, millions of different clients
Speaker 4: and whatever have you. And then when the new stuff
Speaker 4: comes out, I think you could go to like stack
Speaker 4: with dot Com slash P two. I think that's url.
Speaker 4: It's been a while since ide it out, but there's
Speaker 4: like a form where you can kind of sign up
Speaker 4: for the kind of the production grade workflows. We're gonna
Speaker 4: be starting to open up an alpha of that within
Speaker 4: I think the next couple.
Speaker 5: Of months here that is the ero and we'll put
Speaker 5: it in the show.
Speaker 3: It's been a minute, so I was like, I'm pretty
Speaker 3: sure that I hope that's I think.
Speaker 5: That's also ts run. We should drop that in there.
Speaker 2: And I was looking around and it's like, there's one
Speaker 2: ts run that's got like eighty two downloads a month
Speaker 2: or something.
Speaker 5: I'm like, that's probably not it.
Speaker 4: I don't think. I think there's a there's ts node.
Speaker 4: Tsh node is like probably the most popular run. And
Speaker 4: then I think there's typescript dash run. I think that's
Speaker 4: the Okay, I think yeah, I think that the creator
Speaker 4: I think tweeted about it the other day and now
Speaker 4: it's cool USES that was actually gonna be my peck
Speaker 4: is it usess Bill. It's kind of like what Dino
Speaker 4: does with best w C where all the type script
Speaker 4: files get stripped by w c is before they get evaluated.
Speaker 4: It's like that for NOE, so I know by the
Speaker 4: day it's kind of like, man, what's the value prop
Speaker 4: of Dino? You know, because it's like you can just
Speaker 4: kind of like I use something like that where it's
Speaker 4: just okay, types provide a fault and it just pops
Speaker 4: off the types and anyways.
Speaker 3: But yeah, so I guess I just said my pick.
Speaker 3: Darn it.
Speaker 2: Well that's a great segue. Actually, hope we have another
Speaker 2: we can, So let's go to the week's picks.
Speaker 5: TJ. You want to start us off. Sure, I'm going
Speaker 5: to pick a podcast episode I listened to just the
Speaker 5: other day. It's podcast is called Decoder. It's run by
Speaker 5: the people at the Verge, and they did an episode
Speaker 5: and the global chip shortage, which is great because it
Speaker 5: was like like one oh two level explanation. They had
Speaker 5: on a professor that studies the thing that was really
Speaker 5: good at explaining it. So if you hear new stories
Speaker 5: of the global chip shortage and want to speak intelligently
Speaker 5: about it at dinner parties or whatever, right amongst amongst
Speaker 5: friends and such. I found it found it to be
Speaker 5: a really good just like primer on where chips come from,
Speaker 5: which is something I don't think about very often, like
Speaker 5: how do chips? You know, all the supply chain around it,
Speaker 5: and then what's the drama behind it? Why is there
Speaker 5: a backup? What's being done about it? So I find
Speaker 5: it interesting. So if you do too, it's like an
Speaker 5: hour long prime run it, so check it out. Sounds
Speaker 5: fascinating page.
Speaker 6: My pick today is going to be something that I'm
Speaker 6: actually using for the first time, and it is a
Speaker 6: new mic. I'm getting ready to record a course for
Speaker 6: a company called new Line that does all sorts of
Speaker 6: different web development courses, and one of the things that
Speaker 6: they highly recommend is to use something better than what
Speaker 6: is built into your computer or your AirPods. So the
Speaker 6: MIC that I would recommend is called the Algato Wave three.
Speaker 6: It is it's probably about one hundred and fifty maybe
Speaker 6: two hundred dollars US if you buy it brand new,
Speaker 6: but actually on Amazon they have refurbished ones that come
Speaker 6: into about one hundred and ten one hundred and twenty
Speaker 6: depending on and it So I got it. It looks
Speaker 6: like brand new. I have ninety days to try it
Speaker 6: out and take it back if I don't like it.
Speaker 6: But between this mic and the software that they provide
Speaker 6: to make it really sound great, it's been fantastic so far.
Speaker 6: So in addition to whatever they provide in terms of software,
Speaker 6: you can set up noise gates and noise suppressors so
Speaker 6: you don't hear the keyboard clicks and the mouse movements
Speaker 6: behind it. So I would definitely recommend it if you're
Speaker 6: looking for a good mic. That's a step above maybe
Speaker 6: the blue yetty nice.
Speaker 3: That's pretty cool, all right, Eric Gosh, Yeah, a tight
Speaker 3: script around. I'm just gonna say that again. I think
Speaker 3: it's pretty cool.
Speaker 4: The other thing I actually I checked into the other
Speaker 4: day is like we enabled support for bide and I've
Speaker 4: heard a lot of good things about it, and so
Speaker 4: I actually was like reading through the docks and one
Speaker 4: the docks of that invite are really good, but too
Speaker 4: it's like Bite is like I was, actually I played
Speaker 4: around with a lot and it's actually really really solid,
Speaker 4: Like I get why people like love Mike. It's actually
Speaker 4: really well engineered, well designed, super.
Speaker 3: Easy to use. So I think I think my pick
Speaker 3: will go go to Mike and TS or Typescript. Note
Speaker 3: those are my two picks.
Speaker 6: Yeah.
Speaker 2: I was just doing a video on Solid jas and
Speaker 2: their standard outfitting is with vite and it is just
Speaker 2: bleasingly fast. I mean Solid is fast on its own,
Speaker 2: but viight is amazing cool. Well, my pick for this
Speaker 2: week is west World. We've started watching West World again.
Speaker 2: My daughter's into it and that's been it's really good.
Speaker 2: The second time around actually see a lot more and
Speaker 2: get a lot more detail out of it. So yet again,
Speaker 2: HBO is doing excellent, excellent work. All right, well, thanks
Speaker 2: everybody for showing up, Thank you Eric for your time,
Speaker 2: and we'll see you on the next react around that
Speaker 2: awesome thank you.
Speaker 3: Have a good one.