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