Eric Simons joins the roundup to discuss the latest advancements made by StackBlitz that enables you to run NodeJS in the browser. Eric expands that to the work they've done with the NextJS team to run NextJS in the browser without the need to have a server in the background.

Welcome to React Roundup, the podcast where we keep you updated on all things React related. This show is brought to you by Envoy and Top End Devs. Envoy provides high quality design and software development services on a client friendly business model. Unlike all other software agencies, Envoy allows clients to only pay after the work is delivered and approved. Visit envoy.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 unvoid.com. And Top End Devs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topendevs.com to join their AI Dev Boot Camp, weekly community meetups, and access expert tutorials. I'm Lucas Paganini, founder of Envoy, 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. I'm here with my co host, TJ Van Toel Hey, everybody. And Paige Naderinghaus.

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 on React Ground Up? Well, I think probably probably a couple of things, but I think probably the the most interesting thing is some stuff that we've been working on with, the Next. Js team and the Google Chrome team that lets you, like, run Node. 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 the current trend of, you know, React is really kind of, you know, blurring the line between what is server code and what is front end code. Right? And so this actually kinda this allows you to actually have a much faster and better development and debugging experience for that. And we can kinda dig into that, but I think that's probably the most interesting thing. I mean, it's called web containers, the the technology we made for it.

And so I don't know. Maybe you saw it on Twitter at some point, maybe it didn't, but, you know, we can kinda we can kinda dig into it. No. It's super cool. And you say you can run Next.

Js in the browser? Yeah. Yeah. And so and it's actually so it's, like, basically well, I can I can kinda back up? I kinda give the context of why that how we ended up doing this thing.

Yeah. Go for it. So back 5 years ago now, as of this month, actually, my cofounder of the company, his name's Albert, he and I actually grew up down the street from each other, literally here. So I guess people can't see the video, but I'm in Chicago at my parents' house right now visiting that. And Albert grew up, like, literally Florida House and Stout.

His parents are still there. And so we grew up and, you know, learned how to code together when we were in high school, and we ended up going out to Silicon Valley and starting some companies. But, 5 years ago, I guess about 6 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 it'd be like, hey.

React says I'm out of file launchers. We're like, that is not React. That is just the stuff that broke on your computer for, like, no good reason. Right? So we're like, okay.

Well, how do we how do we, like, solve this problem? Because, like, we're we're 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 etcetera are just, like, they're written in JavaScript. Right?

And so theoretically, wouldn't it be possible to, like, copy pasta Webpack and then slap it into a browser tab and, like, just kinda 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 6 months and built out essentially, it's kind of like a CodePen plus plus where it had MPM built into it.

It had, like, webpack loaders. You could, you know, do all this cool stuff. And so we launched it and kinda, like, took off like a rocket. And so that's stackless.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 GitHub code spaces or, like, code sandbox, run stuff on servers. If you ever use 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 cost them money. And and there's a lot of latency, etcetera.

So, usually, the experience is worse than your own local environment than when you're using one of these online things. But, anyways, the short of it is that we ended up figuring out, like, you know, a couple 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 in WebAssembly from the ground up where you could actually run Node. Js entirely in the browser, which then opens up, the ability to run Next. Js, bytes, all these different tool chains, and you can just npm install them, npm run star, and it's running all on your computer, so it actually works offline, etcetera. And so we actually that's, that technology is called web container.

It's we actually rolled that out out back in May. And so StackWiths is, in fact that makes, you know, StackWiths just, like, the fastest, most secure IDE on the planet because it's all being done inside the browser security sandbox, etcetera. So that's how, like, that's, like, probably information overload. But that's kind of the short of, like, kinda how we started off, kinda how we got here today on stuff we're 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 Node 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, well, 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 on my computer or runs on some server somewhere. And the idea of going out to a browser and writing something with Node and running it is kind of like at 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 foots.com/webcontainers 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 kinda add to the to I I think I kinda I missed the punch line, which is actually that running Node. Js in stacklets.com is faster than your local environment.

Like, execution speeds are 20% faster. When you go to stackit.com and, like, start a Next. Js project, you can kinda get you can actually literally see how fast it runs. Right? And the npm installs are, like, 5 x 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 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 8 out of Chrome to bring it to local. Right?

But Google Chrome and all these other browsers, they have their own JavaScript engine, whether it's v 8 or SpiderMonkey or whatever. And so if you can actually write, like, a a a compiling toolchain that can take Node. Js from source, rip out v eight, and actually use the existing JavaScript engine, right, in your browser, you don't have to drag along a lot of the the 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 8 with every release of Node. And so if you're using Node 8, you're using a version of v 8 that is incredibly old and has lots of security vulnerabilities at this point. But by actually coupling it, you're with Stackblitz, right, your environment actually gets faster and more secure while you're sleeping. And so what that actually kinda gives you, right, is, like, with one copy of VA, there's actually a huge inefficiency on local. Because if you think about web development, like, what does it kinda look like?

Usually, you have Node JS processes running webpack or whatever have you. Some end number, let's call it, like, 5 to 10, like, processes that are running. So that's 5 to 10 copies of v 8 there. You add Versus Code open, which is electron, which is therefore Chrome and has its own copy of v 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 v eight running, which is hugely inefficient. And so by actually collapsing it all into say, more than the browser, there's a there's a gigantic performance gain you get from doing that. And so that's actually the main thing that that allows StackUp to be faster than your than your local machine is that it's using one copy of VA instead of dozens kinda scrawled 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 Stackblitz 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 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 a pre react app with a a separate because if you actually go to stacklist.com, you don't even because it it's running on your computer, we don't we don't make you log in either. So you can literally go there now, start a Next. Js app or start a GraphQL app, and and you actually see a terminal that pops up. So you can actually run multiple processes at the same time just like you would on local.

And And so you can be running pre React app and a GraphQL server where they're, like, talking to each other and everything entirely inside of your browser. And so, like, all of the the sort of common workflows that you would be doing about development app 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. Js team. Have you talked to them at all? Because I could totally see, like, embeddable demos. Like because, like, right now with Next.

Js, if you wanna 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 they could share a GitHub repo, but the that's always a pain, right, to download a GitHub 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 Stackblitz instance. Here's the 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 drop down work or something like that. Yeah.

Yeah. Absolutely. Yeah. And they so I think in their 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 in in in GitHub, there's on a lot of them, they have, like, these open and stacklets buttons where you could actually pop them open, and then you can actually embed this stuff too. And so, like, I think that the Node. Js documentation site actually, I think, just they they've started embedding this via, like, Stackblitz projects because, again, like, compared to, like, there's these other online things that use VMs, like Replit or Glitch, but sandbox, the problem is that when you actually embed them, you they're they typically don't let you edit the code because they don't wanna provision a VM for every person who's just browsing by the page. Right? Because it's gonna be way too expensive and they 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, what 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 paywalled or, like, you had a whole bunch of hoops you have to go through to try and use it. You should be able to just be able to be browsing. If I wanna learn Node.

Js, 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, 2021. This should be fixed by now.

Right? So that's that's actually a really a really key thing that, you know, 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 setup?

Because I know that everybody who has their Versus code instance has, like, you know, their prettier formatting, their ESLint setup, their git ignore, git 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? Yeah. Really, it's a very good question. That's actually what we're working on now.

So, basically, today, we've got kind of this stripped down version of Versus Code. This is we designed to be very fast from the get go, and this is actually the same editor we've launched with, like, 5 years ago. And so this is before we had the ability to just execute arbitrary Node. Js programs in the browser. Right?

Now, actually, what's what's kinda cool is that if you can run Node. Js in a browser, when you actually look at Versus Code and what, like, what makes the Versus Code extension like, technically, like, what what is a Versus Code extension? They're all actually just Node. Js programs. And so what we're actually drilling into right now, I think we're it's looking like we'll have this out sometime in the next quarter, is that you're we actually are able to run Versus Code wholesale inside of the browser, including running just arbitrary extensions.

And so so so I think the ultimate solution we see to exactly what you're describing, because that is is totally, a really important point for us to nail, is, 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 kinda cool about it is, like, because this is it is a cloud network ID. It's it's using your browser to do the work, but that will sync 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 kinda work out of the box because it's it just like any other just like Figma or Google Docs.

You know, your settings just kinda by default, they're gonna persist across. So, yes, that's kinda the that's that's how we're applying to to address that stuff, and it's actually working. It's actually pretty cool. We actually literally just got Versus Code kinda fully mounted, like, I think it was, like, last week or something on top of WebKit. We haven't announced that yet, but, like, but that's, like so sneak sneak peek.

You did it here first. Yeah. You did it here first. Yeah. Exactly.

Yeah. Exactly. That's really cool. How do you get around the browser security limitations? I mean, if you're gonna open up a port to for your Next.

Js, like, 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 aside on that is, like, security is actually one of the big things that that we see as the benefit of this approach.

Right? Because what's what's going on in the in the market right now is that we actually have nation states that are attacking US and and other, companies' countries. And the, actually, the 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 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 don't actually have to brute force into the into the the database or whatever. You just need to, you know, get one of the devs to install. Think think about an NPM install, you're talking about thousands of dependencies. So how hard is it to actually do that?

Well, the answer is not hard. Yeah. And that's exactly what's happening with SolarWinds and all these other things going on. So, but in Stackblitz, 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 for MPM. And it is you all you have to do is just hit command w and close your browser tab.

Like, it it cannot go anywhere. It can't go anywhere. It can't go and scrape your SSH keys because of the browser's built in network restrictions. You're you're not gonna 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 Stackblitz that runs behind the firewall at these gigantic banks, Fintech, government, health care, etcetera, that are the subject of these sorts of attacks right now. Right? And so, anyway so so and so, like, how that's possible is that we don't break out sandbox. And so for networking specifically, what we actually ended up building was this TCP network a virtualized TCP networking stack inside of the browser where it actually maps the, like, Node.

Js, TCP calls to the service worker API. So, like, when you actually spin up a server in Stackblitz, what's actually going on is that there's this virtualized TCP network stack that's actually translating that into service worker request responses. Right? And so it actually what's, like, kinda cool about that, again, from a security angle, like, that is only accessible to that browser instance. So if I if you go to Stackblitz and you, you know, start Next.

Js project, you take the URL of the the dev server and put it into, like, Safari or Firefox, you can't actually access that server. Right? And that's another attack vector where people will actually when they install something on your computer, they'll actually start scraping your local host URLs to try and grab credentials 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 portable. It's just, like, a much better development experience. Yeah. Yeah. It's funny.

I I used to work at a hosting company, and we had we we didn't do our development on 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 to SSH into everything is also not the world's greatest experience. So I could see some, 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 3 days or whatever to, like, get up on the code base Yeah. 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 kinda all the the right version node and all that.

And then this is even that much easier. You literally just go in your browser, and it's good to go. That brings up a question though. If you're doing this development in StackBlitz, is there 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 host or whatever the development environment is to actually put this out on the the rest of the public web? Yeah. Yeah. So that's we have a minimal Git integration right now. It's it's, like, it's very alpha.

We have, like, a very, we have a huge update that's coming out next quarter where it it basically because right now, we're kind of in the phase of still solidifying the the core technology, making sure all the frameworks out there kind of run properly on this thing and, you know, etcetera, etcetera. And 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 a stat yeah. Right now, actually, if you on any, GitHub URL, if you just add the word blitz after GitHub, so gitubblitz.com/repo, it'll you can kinda get an idea of a little taste of what this is gonna look like. But, effectively, any Git repo 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 pull requests and that sort of thing.

And so that's, like, version control is actually be a a really a the most first class integration. And, of course, with that, you have CIs for things like Netlify and other, like, hosting providers where, you know, it'll whatever tool tools you have set up for hosting, it'll it'll kinda work there. We have another integration we're gonna be doing where well, anyways, not to get in that. But, like, that's, I think, the the the short of kinda how that stuff is gonna work. And I think what's cool so when when you kinda talk about that, right, what's cool about being having this, like, YPD here's to be able to mount any Git 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, can 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 commit it up. It's like this whole thing.

Right? With this model, you can actually crack open a whole another you can open up dozens of copies of of your code base and be running them at the same time without having to switch branches locally. So it's kinda like the seamless workflow. It's like, hey. Can you check this thing out?

Sure. Click a link. Boom. It boots up. You check the thing out.

Bala. 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 removes this whole friction point around, you know, on local, you really have to, like, be it's a very manual task of kinda, like, making sure your Git your your Git 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, 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 wanna 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 huge. That would be that'd be really, really cool. Totally.

I think that's kind of what we're, like, what we're buying 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 wanna continue using my local environment as my primary way, having just like you have a a preview link for, you know, Netlify 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 dev environment preview. We could pop it open, not only just preview it, but actually, like, make changes and just commit them back to the branch. Right? That's I think that's, like, there it's kind of this crazy part of the workflow.

Right? Where if you think about it, a lot of, like, what GitHub does really well are just like these these version control providers now. They they actually allow you to do a lot of your workflow in the browser. Right? And the main place where you have to kinda, like where you you have there's a sharp drop off of being able to work in the browser is when you have to open it up, review it, make changes, etcetera.

So I think this is kinda like completing that workflow then because you can actually, like, do the development in the browser, make the PR in the browser, have the PR be reviewed in the browser and ran in the browser. Right? So it's like there's not this just hard context switch every time you're in that part of the process. So, yeah, I I agree. I our entire team kind of agrees.

We're like, god. We we need this thing ourselves. I'm curious. So you you say you do deploys 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 I it's sort of a leading question because I could say that my still biggest remaining concern with online editors is I I don't like how the keyboard shortcut conflict, like, because because when you're still running in a browser, the browser is still gonna 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 and 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 IDEs that have existed. Of course, they're using cloud VMs to do this stuff, which is 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, I did not mean to do that. But I, like, my I'm trained by my I have muscle memory.

Right? And so what actually the key thing that enables this is desktop PWAs. So if you actually install StackBlitz or, I mean, any other desktop PWA, when it's actually in the installed mode, you actually can override every key binding, command w, command t, command n, all of that, actually, just like a desktop app. And, of course, as a desktop PWA, you lose the URL bar. It it 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 is, like, now approaching 0. And on top of that, the other thing too is, like, the Chrome actually shipped the native file system API last year. So it actually gives web apps the ability to to open a piece of your file since it's in both 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 just interesting is, like, part of the Versus 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 syncs 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 the key thing that we see is, like, really enabling this to, like, work in a meaningful way. Yeah. It took until I've I've long been the a naysayer of web based editors, like, for more than like, for tinkering, great. Right? But as a long time software developer, like, it was always like, oh, but it's it's clunky and it's not like my real editor.

And it took Versus 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 in the browser. Like, the the speed is there. It's just solving these, like, last mile type of things to make it possible.

Yeah. No. Exactly. Exactly. And it's been a long time coming.

I mean, it's like and this is kinda like, you know, almost like the first minute where you could kinda 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 and some of them, like, with, web assembly threads and whatever, I mean, they're still kinda figuring out how to enable this in all browsers. Right? So it's kinda like we're we're at this is like the I think this this is gonna be an interesting decade for for this industry, I think, because the web is I mean, the web is powerful enough to, like, write the web.

Like, that's kinda the key. That was the thing that blew our minds. We're like, this is the first time you can actually like, that's kinda if you talk to people who who have built, you know, stuff for platforms before, the 2 biggest stress tests of any platform is, 1, video games. Right? Because you're talking about an incredible number of of calculations that are happening, right, typically, in that.

And and you're seeing a lot of browsers supporting video games now. Right? Like, a lot of browsers are moving a lot of games are moving in the browser. And the second one is IDEs because you're you know, the platform has to be powerful enough to 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 30 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 main, mainframe to compile an iPhone app or something. Right? It's like it's not it's it's not running on that same device. So, anyway so, like, that's that's I think what's kinda crazy is I think that that is, historically, that's an important moment for any platform because they're then that means there's gonna be an explosion of new types of applications that that weren't possible before.

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 I'm very interested in that myself. I've done a lot of work in, like, 4th grade classrooms, the 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, drag and 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 that. 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, 6 year old I think it's, like, I think it's, like, 1.2 gigahertz sorta mobile Intel processor with a gig of RAM, maybe. Right? It's it's just this terrible, absolutely like, it's difficult to just type in to sign in to Google on that 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 Chrome team and, like, Google's, venture is actually an investor in our company. So we've got great relations with these folks. 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, and so and, you know, that was kind of a big question for us is, like, if this only is gonna work on MacBook Pros with 16 gigs of RAM and yada yada, that's that's kinda that's not it's not gonna fit our solution criteria. But to our surprise, again, because of the efficiency of the model, one copy of V eight and a whole bunch of other stuff that we do to make it, you know, insanely fast and efficient, it's actually the 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 JS, etcetera on these, like, just wimpy devices, and it's kinda kinda incredible. And and, you know, it's it's certainly slower than my back, but it's but it's actually faster than the other online IDs that use a VM 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 tel you know, k through 12 school and even colleges can use this for free. And, again, that's always been the problem with schools. They don't have the 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 a like, we have a 1,000,000 something developers that use Stacklets every month that we pay, I think, like, $800 total on our AWS. Yeah. Because the computing's all done on the edge. It's exactly It's all on your machine.

Exactly. Exactly. And so it's just this transient electricity cost the user's 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 burning out of code all the way to, like, Fortune 50, where they're, like, writing the software that, you know, we use to wire money. Right?

It's like it kind of this this kind of technology can actually span that entire that entire category, which is kinda rare. Like, it's not often that you see something that can kinda accommodate all those use cases so elegantly. Right? Yeah. When we talk education, our our minds usually go to, like, 4th graders or young kids, but there are a lot of companies that spend a lot of money on training their their not 4th grade employees to get up to speed on the technology and would gladly welcome anything that cuts down on that.

Right? That makes that automates things that previously they had to teach and have processes around and all that sort of thing. Or that total hours to onboard somebody. Right? Yeah.

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 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 of us? Yeah. Yeah. Good question. So, yeah, today, it runs on Chrome and Edge, like, perfectly.

And on Safari, it requires a config flag or, say, not Safari. On on Fire Firefox well, actually, Firefox and Safari requires a config flag, like, a runtime config flag. And so, actually, the big issue that we we built all this stuff on top of web standards. And so, like, it it should absolutely work on all these things. There there's no platform specific APIs that we're using to make the core of this functionality work.

There's actually what what kinda happened is after the Spectre and Meltdown stuff, you all probably kinda heard about this, like, shared array buffers, and they've been trying to figure how to bring them safely back to the web. And this is an application that has to use shared array buffers. There's no other way to do what we're doing than having shared memory with atomic, write logic. Right? And so because of that, we're kinda blocked by the you know, Chrome's kinda always at the bleeding edge of this stuff.

And so, you know, them and and therefore Edge, because Edge is, you know, kinda is Chromium now. That stuff works fine. I think Firefox Firefox is actually, is is is darn close. Safari is just kinda doing their own thing, but they usually come around, give it enough time. But, you know so that's that's kinda where where it lays.

But I think probably within the next 6 to maximum 12 months, I think it's like you're gonna be able to open this up on, like, your iPhone and, like, be able to actually run Node. Js on your iPhone in a browser, which is, like, kind of kind of insane to think of that. Like, I'm gonna have a web page, and then it's, like, cool. Like, that's that's running on my phone. So I'm very curious how this works, though.

You described it earlier as being, like, what you're shipping is, like, a re almost like a a way of communicating with the v eight that's already there. But in Firefox, v eight isn't there, and your iPhone v eight isn't there. So how is that working on those browsers? So yeah. So, basically, what what we've kinda done with that end of it is, like, all of these different like and if you look at, like, Node, Andino, and any of these alternative job is for runtime that are out of the browser.

Right? What they do is they take VA, which provides you with all the stuff you need effectively to to run a JavaScript engine, but it does not include any of, like, the built in stuff, you know, that your browser ships with. Like, if you want a a new date function, that doesn't ship with VA. 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, like, kind of the bulk. There there's more to it than that, but, effectively, like, the bulk of when you actually look at Node, 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 WebAssembly 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 within Stackblitz? Yeah.

Yeah. So so today, we're like I think the the version we're on is, like, version 14. I can't remember the subversion, but we've got a one pin version where we're kinda battle testing the technology on. And then once we're once we're out of beta on this thing, we're gonna be adding, I think we're the current plan is that we're gonna be doing LTS releases. So, like, every LTS release from 14 on, you know, you'll be able to to use on Stackblitz.

But, yeah, so that that's kind of the idea is that we're gonna have a a list of versions, though, that you'll be able to use here. Okay. Nice. So how about end to end testing? So if I am building my app and I've got my unit test running and all that, how do end to end testing is gonna try and hit those URLs?

Is that gonna is that gonna sit on that same emulation layer? We mentioned it's not externally accessible outside the browser, so that's an issue. Yeah. Well, it depends on, like and when you say and then are you thinking, like, Cypress, something like that, basically? Yeah.

Yeah. So what's, yeah, what's kinda cool is that and so this is part of part of the the story that we're we're making the path really smooth for this because it's a like, that's it's a really good question. Like, unit tester, he's, like, just runs in white container today. Of course. Yeah.

Like, no problem. But yeah. But, yeah, like, end to end test, it's actually kinda it's kinda cool because so there this guy, I think his name's Glab over at at, he was at Cypress when he was kinda digging into this. But because, like, all Cypress really does, right, is it just remotely controls a Chrome instance. You have 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 dev environment in the 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 Cypress to mock, like like, you know, intercept API data that is going to be server side part of Next. Js and then run an end to end test against the entire full stack environment. Oh. Right?

So So this actually Woah. Which wait. It it blew my mind because I'd never thought of that. When Glenn posted it on Twitter, I was like, holy heck. Like, that is insane.

That is kinda mind blowing. Yeah. Because I did that that's kinda like that that was the the mo you know, that was just one of those moments where I was like and it was like a month after we launched the thing. When post that, I was like, holy cow. Like, that's actually incredible.

Because how else would you, like, in any sane way, test out a a server side rendered application where you wanna mock the data and the database calls or whatever that are happening on the back end side and 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 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 it locally or in CI, it's actually, like this actually lets you enables this kinda 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 you search this on Google, you can find a 1000000 articles and best practices. But this gives you, like, another realm of possibility. 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 change. So now what you should do has to change as well. Yeah.

Yeah. Exactly. That's kinda like a whole new a whole new world of, like, just kinda different like, once you once you get a run, then you get all these environments just in inside of, like, the same tools that we're using today to write and then test. It's, like, kinda like, what does that mean and how does that allow us to write more reliable software. Right?

You know, it's like I think I think we're just kinda scratching the surface of some of the stuff that's gonna be possible. So I think the next thing that people are gonna start asking you about is, can you support TypeScript? And when are you coming out with the Python integration so we can start writing Django and Flask apps? TypeScript works. Yeah.

Yeah. TypeScript fully works. Like and and you can you can use these things like ts node where there's actually one that's kinda popped up recently called TypeScript run. And, basically, you know, you can actually override the node runtimes for TypeScript effectively. So, like, anything you do on local for job Node.

Js 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 Node. 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 end that are pretty cool. Because, yeah, I I think this is the idea here is it's like this could really work for any language, not just, like, JavaScript or Node or whatever have you. How, though? Because isn't some like, because a lot of this is premised of being web based.

Right? Because the 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 that this is this is the interesting stuff.

Like, this is the stuff that we're still chipping away at. So we actually there's a group called the the bytecode alliance that is it's a consortium of companies, and Stackblitz is actually, one of the loving companies. So it's, like, Microsoft, Google, Fastly, Arm, etcetera. And, so they're actually the 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 the Bicode Alliance is the web assembly system interface.

You might have seen this over, you know, the past couple of years. But, essentially, it's a a standardized interface that lets you do system level calls in WebAssembly, and that's really a lot of the problem when you kinda look at porting these different tool chains to run-in WebAssembly is that they're they're using these native API services that are are realistically not gonna 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, dev environments are very easily exploitable and and and we've got to solve it. Right?

And so WebAssembly provides a way to do that and but we also don't wanna give up the security benefits that provides. And so WebAssembly interface is actually really well designed to provide all those sorts of things that you need for, you know, file system, networking, etcetera, 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 that this is working is that 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 WebAssembly using WASI, as as the primitive. I albeit without crazy support for like, Django would be a good example of, like, you could run Python on this, but, like, Django requires stuff that might not still be working yet.

But that's actually, like, kind of the the long term plans. We're working with all those folks to kinda help build the future of this thing out. So speaking of that, I guess, what are, like, the the short term plans? Right now, you have the the beta flag on 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 should they try it out? Should 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 workflows, we're we're shooting the land by the end of the year here.

I think in the interim, what this is useful for today is interactive documentation, so rapid learning. Right? We see a lot of design systems actually use Stackblitz for this purpose, like because well, that's getting integrated. But, effectively, when you have a design system, your design system is only as good as how how easy it is to adopt. Right?

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 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. Js is embedding this to their docs. Vite is is using this for their issue tracker, etcetera. I think that's where people can really use this today and that's actually us solidify the core run time stability by actually testing this across, 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, stackbooks.com/p2.

I think that's the URL. It's been a while since I checked it out, but, there's, like, a form where you can kinda 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 URL, and we'll put it in the show notes as well. Just to confirm.

It's been a it's been a minute since I was like, pretty sure that I hope that's I think that's still up. I hope so. Also, TS run. We should drop that in there. I I I was looking around, and it's, like, there's one TS run that's got, like, 82 downloads a month or something.

I'm, like, that's probably not it. How would I don't think that I hope that's not it. I think there's there's t s node. T s dash node is, like, probably the most popular one, and then I think there's typescript dash run. I think that's the Oh, okay.

Typescript dash. I think Literally. Yeah. I think the the creator, I think, tweeted about it the other day. Now it's cool.

It uses ES dot. That was actually be my pick. It's it it uses ES build. It it's kinda like what Deno does with SWC where all the types of files get stripped by SWC is before they get evaluated. It it's like that for Node.

And so, I don't know, by the day, it's kinda like, man, what's the value prop of Deno? You know what I mean? Because it's like you can just kinda, like, use something like that where it's just, okay, types are by default, and it just pops off the types and anyways, I digress. But yeah. So I I I guess I just said my pick.

Darn it. Well, that's a great segue, actually. Hopefully, you have another week we can do. So let's go to the week's picks. TJ, you wanna start us off?

Sure. I'm gonna pick a podcast episode I listened to just the other day. Its podcast is called Decoder. It's run by the people at The Verge. And they did an episode on the global chip shortage, which is great because it was like like one zero 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 wanna 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 primer on it. So check it out. Yeah. Sounds fascinating. Paige?

My pick today is going to be something that I'm actually using for the first time, and it is a 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 Elgato Wave 3. It is it's probably about a 150, maybe $200 US if you buy it brand new.

But actually, on Amazon, they have refurbished ones that come into about a 110, a 120 depending on and it it I so I got it. It looks like brand new. I have 90 days to try it out and take it back if I don't like it. But between this mic and the, the software that they provide to make it really sound great, it it's been fantastic so far. So it 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 Yeti. Nice. That's very cool. Alright. Eric?

Gosh. Yeah. No. TypeScript run. I'm just gonna say that again.

I think it's pretty cool. The the only thing I actually that I checked into the other day is, like, because we we we enabled support for Vite, and I've heard a lot of good things about it. And so I actually was, like, reading through the docs. And, one, the docs of that of Vite are really good. But, 2, it's like, Vite is like I I was actually I played around with it a lot, and it's actually really, really solid.

Like, I get why people, like, love Vite. It's actually really well engineered, well designed, super easy to use. So I I think I think my my pick will go go to Vite and, TS or TypeScript Node. Those are my my two picks. Yeah.

I was just doing a video on Solid JS, and their standard outfitting is is with Vite, and it's just blazingly fast. I mean, Solid is fast on its own, but Vyte is amazing. Cool. Well, my pick for this week is Westworld. We started watching Westworld again.

My daughter's into it, and that's been it's really good. The second time around, actually, you see a lot more and get a lot more detail out of it. So, yet again, HBO is just doing excellent, excellent work. Alright. Well, thanks everybody for showing up.

Thank you, Eric, for your time, and we'll see you on the next React roundup. Awesome. Thank you. Have a good one.