Eric Simons from Stackblitz joins the JSJ panel to discuss the game changing technology announced at Google.io this year. What they demonstrated was their ability to run NodeJS in the browser using new technology called Web Containers. However, the implications go well beyond the realities of running Node in the browser. Eric and the panel dive into the implications of what this new way of working could mean for the web and application development.

Contact Aimee:

Contact AJ:

Contact Charles:

Contact Dan:

Contact Steve:

Special Guest: Eric Simons .

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another JavaScript Jabber. This week on our panel, we have Dan Shapir. 

DAN_SHAPPIR: Hey from Tela Viv. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo from the sunny, beautiful, pleasant, pleasant Grove. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: Steve Edwards.

STEVE_EDWARDS: Hola from a very sunny and warm Portland. 

CHARLES MAX_WOOD: I'm Charles Max Wood from devchat.tv. And this week we have a special guest. Welcome back, Eric Simons. 

ERIC_SIMONS: Thanks for having me. Yeah. Hello from, from San Francisco. Actually just the sun just came out. It was, you couldn't see, I couldn't see the apartment complex in front of me. It was that foggy this morning and now it's completely clear. It's like, it never happened. 

DAN_SHAPPIR: In other words, San Francisco. 

CHARLES MAX_WOOD: Yeah. Well, it's great to have you back. I do want to ask kind of, I guess a little more publicly about your partner in crime real quick. We usually see you with Albert. 

ERIC_SIMONS: Yeah, Albert. Yeah, Albert is doing good. Albert's the CTO of, co-founder and CTO of StackBlitz. And he's doing good. He's actually, he lives, I think like maybe three or four miles from me in San Francisco. So we back four years ago, we decided that if we were going to be a remote company, we kind of needed to be remote as well. You know, we couldn't cheat and be working out the same office. So we work remotely four miles away from each other. And, but Albert's good. And now that the team's grown a lot, I think the last time we were on this podcast, I mean, it must've been like four years ago is then I think, you know, you're probably talking to Albert and I, which was the entire company. 

CHARLES MAX_WOOD: Yeah. 

ERIC_SIMONS: And now we're, now we're at 12 people. So there's, there's a, there's a lot of folks working on the operation behind the curtains now. 

CHARLES MAX_WOOD: Yep. And I just missed seeing you guys in the astronaut suits at NGCOM. 

ERIC_SIMONS: Who knows? Maybe this year, maybe this year we'll be back. We'll have even crazier costumes.

CHARLES MAX_WOOD: Yeah. All right. Well, let's kick this thing off. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps. First thing I figure out how to deploy them. I get them up on the web and then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. The other thing is, is that sometimes I miss stuff. I'll run things in development, works on my machine. We've all been there, right? And then it gets up into the cloud or up on a server and stuff happens, stuff breaks, I didn't configure it right, AWS credentials, something like that, right? And so I need to get the error reporting back. But the other thing is, and this is something that my users typically don't give me information on, is I need to know if it's performing well, right? I need to know if it's slowing down because I don't want them getting lost into the Twitterverse because my app isn't fast enough. So I put Sentry in, I get all of the information about what's going right and what's going wrong, and then I can go in and I can fix the issues right away. So if you have an app that's running slow, you have an app that's having errors, you have an app that you're just getting started with, go check it out, sentry.io slash four, that's F-O-R slash JavaScript, and use the code JSJABBER for three months of their base team plan.

 

DAN_SHAPPIR: So I actually wanted to ask a question upfront. I actually requested the Chuck that I get to ask the first question. And the thing is this, like a couple of weeks ago was at the time of this recording was a Google IO and that's usually when Google make all of their exciting announcements and really looking forward to see what's going to come out. And then along came you guys and you kind of upstage Google in my opinion. And you came out with this announcement that was more exciting to me than anything they announced. So I really wanted to ask who are you guys and how did you upstage Google in their very own conference? No less. 

ERIC_SIMONS: I, I appreciate it. I mean, well, I think the, to be clear, right. So what we announced is built on just a decade of work that Google has been doing. Right. Making browsers more powerful and more capable. And so we we may have, I think that we got to have an exciting announcement, but we're kind of standing on the shoulders of giants in that sense. And we're pretty, we work a lot with Google. They're our biggest customer and our biggest partner. And they're actually, through Google Ventures, they're one of the larger investors in our company. But so we're an independent company though. We're a small startup of about a dozen people at this point. And kind of the short of it is that we do a lot of work on you know, making stuff work in a browser that shouldn't work in a browser, which kind of relates to what we announced. And so we work a lot with like the Chrome team and et cetera over at Google. And they were very awesome. And they actually they let us they put our product on display during the Google I O keynote, because making use of I mean, the API, so the Chrome is shipping are just unbelievable. Like they're so cool. Like it kind of blows the lid off of what you can do with just a web application. Like the line between a web app and a native app is blurring to a point where it's indistinguishable. So I don't, I hope that's the answer to your, to the question you were asking, but like, but yeah, that's kind of our relationship with Google and kind of how, how we ended up being there. 

STEVE_EDWARDS: So I'm always one about establishing the basics here. So we're talking about we, and who you are with Google. Could you, for those of us who may not be familiar, could you explain who Stackblitz is and what you do and how this fits into what you guys are doing? 

ERIC_SIMONS: Yeah, totally.

CHARLES MAX_WOOD: Steve they're the cool kids.

ERIC_SIMONS: Yeah, I know that 

CHARLES MAX_WOOD: they're always the cool kids at the car. 

DAN_SHAPPIR: He looks like the cool kid. I have to say, 

CHARLES MAX_WOOD: I know, right? 

STEVE_EDWARDS: Emphasis on the cool or the kid. But anyway, 

ERIC_SIMONS: dang, is this is this a roast? Is this a roast? 

DAN_SHAPPIR: He's like, I'm just like, I see it. That's it. 

CHARLES MAX_WOOD: The roast is next week. 

AJ_O’NEAL: I'm the official roaster. Don't take that away from me.

DAN_SHAPPIR: Hey, I'm sure you'll get your chance. AJ, 

AJ_O’NEAL: I don't know. I'm excited about this. I don't think we'll see. Is it wasm? That's what I want to know. I'm just cutting in with my question. Is it wasm? What is it? 

ERIC_SIMONS: Which part, which part? 

STEVE_EDWARDS: Okay. Yeah. You're stepping on my question here. Yeah. Let's talk about Stackblitz. Let's hear from it and go from there. 

ERIC_SIMONS: Yeah, I'll kind of, I'll give the short of, of Stackblitz, but so your stack puts is an online ID, right? So you like can crack open your browser tab, start coding. And there's a lot of these things. So, you know, when we launched Stackblitz four years ago, when we first chatted with you all on this podcast, actually Stackblitz was one of the first products that entered the market that kind of spawned. There's a ton of these now with like a, get ups got code spaces. There's code sandboxes, a million of these things. Right. And the problem, and actually, you know, if you date, it dates back to like 10 years ago, like cloud nine was like the first online IDE and they got bought by Amazon, I think like five or something years ago. But the problem that they've always had is that they, they provide a worse experience than your local environment. Right. Like, have you ever tried any of these things, but they actually run your entire dev environment on like a remote server and the pro and then they stream the results back across the internet to your browser, right? So the problem is that you're inherently adding latency to development. And when you're talking about web development, you want to like write code, see your changes instantly. So it's just in time to stream that back across the internet, a huge pain. Usually the VM you're connecting to is like less powerful than your computer using to connect to it in the first place. Right. So in just about every way, it's actually a worst experience in your local environment. So how Stackblitz was is different is that we actually mount the entire development environment inside of your browser itself. So it's actually using your CPU, your memory, right. Your disc to run these, these dev environments and they boot in milliseconds. Like you can actually, if you go to Stackblitz with.com and just like click on like the next JS starter project that is booting a web assembly based operating system inside of your browser, running the entire next JS, your dev tool chain and doesn't NPM install like seconds, right? On demand, just entirely in your browser. So the benefits of this, right? There's no latency because it's again, it's using your computer. It works entirely offline and it has all the benefits of local, except it's actually even faster. Like your execution of Node.js tool chains in StackBlitz V2 here is actually 20% faster than what you can even achieve on local for kind of a variety of reasons. But that's the short of it. It's the fastest, most secure dev environment on the planet. It's the first time anyone's been able to run a dev environment within the browser security sandbox, which is pretty crazy, because browsers are like the most secure runtime ever invented by humans. And so being able to run your dev environment that is hugely beneficial, especially if you're talking about Fortune 100 companies, but even for open source maintainers who have to take in bug reproductions and execute code that someone submitted, right? This is a very fast, secure way to do that. 

DAN_SHAPPIR: And I want to point out that you are comparing yourselves to various other development environments in the browser. So some of them were, like you said, were a pure remoting type solution, in which case you were running a standard development environment on some server and then just remoting the UI. Others were actually building the UI on inside the browser and just remoting the processing, but then the UI looked nothing like the development environment that you were used to using in your local system. You're actually running something that looks exactly like VS Code, right? Essentially, there's no real difference in terms of the user experience from running VS Code within your environment and running VS Code on my local computer, correct? 

ERIC_SIMONS: That's correct. Right. But I, so the flip side of it though, I mean, if you look at get up code spaces, right? Like the VS code team actually, like it's, it's, they've got VS codes UI in a browser. And, and the difference though, is that even though the UI could boot up instantly, when you go to that terminal and try and run a command, that's when you notice it, when you try and open up a file, edit and hit save. That's when you're going to notice substantial lag and run into tons of issues. Oftentimes if you start up a server you'll get bad gateway errors, right? Cause it's really hard to instrument those containers that they're running on a VM to run as reliably as your local machine would. And if something does go wrong, right? If that container gets worked, which happens all the time, oftentimes, you go and reach for the refresh button in your browser, but what all that does when it's on a VM is it actually just reconnects you to that broken VM again. So unlike every other web app using these online IDEs, it's not clear how you get to, how you can kind of refresh the entire thing and start from scratch. By running it entirely in the browser, because on every page load, we're mounting that container from the ground up, you can completely screw up your environment and you just hit the refresh button and you're back to a working environment. So it's really fast, really reproducible environments. So the big thing really is, it's not necessarily even the UI because we're definitely running all of VS code there. But it's actually all of the commands like that shell you're interacting with on stack blitz. That's not touching a server. That's all happening. That's all executing using your CPU, your memory, et cetera. And that's the thing that's where there has been no prior art on doing something like this is actually creating an entire operating system from scratch. That's designed to work inside of a browser. 

DAN_SHAPPIR: So you effectively implemented some sort of a Unix system kind of running within the browser. 

ERIC_SIMONS: Yeah, exactly. Exactly. 

AJ_O’NEAL: So is this open source or is it patented or what's? 

ERIC_SIMONS: Yeah. So we've filed patents on certain parts of it. Like one of the key things is you can actually start HTTP servers inside of the browser itself, because we've, we have a virtualized TCP stack that is mapped to the service worker API. So you can actually just like start a new node project, create a new server, and it'll actually like spit up a live URL that you can actually go to it, right. And like a new browser tab or whatever. Our, our intention with this is that we, we want to help. We want to actually create some sort of standard ultimately around how web assembly containers kind of like Docker's OCI initiative, something akin to that. And I think there's a handful of other things that we've built here that make a lot of sense to be in the public domain instead of just like closed source. And so we've got a core repo where we're currently tracking issues and we're going to be rolling out like core pieces of the technology. So that's in the open source domain and people can use it and that sort of thing. 

AJ_O’NEAL: Well, what makes sense to remain closed source for this? I mean, what, what's your? What's your money play on this? 

ERIC_SIMONS: Well, so the way that stack was makes money is, uh, pretty interesting. And that was actually, you know, from four years ago, we, we really had no idea kind of where, how we can trade, uh, the stuff, you know, the, the cool stuff we were making for monetary value. But what we ended up finding out was when you talk to the largest companies in the world, they have very genuine security, very genuine security problem and that they are willing to invest in things that will be more secure. And they certainly will invest in things that will make the developers more productive. And so for us, you know, StackBlitz core business is actually working with like Fortune 100 companies and actually putting StackBlitz behind their VPN, because they can't use the public version of StackBlitz. It has to run, you know, air gap behind the firewall. And by actually being able to use the browser, like every Fortune 100 company has approved Google Chrome as a secure runtime that everyone at the company can use. So instead of like, you know, again, if you're looking at something like GitHub code spaces, right, for that to run behind your firewall, you have to talk about how secure is the virtualization layer of these VMs, right? And how they're being provisioned, which is a huge nightmare. Whereas with StackBlitz, it's a huge security upgrade by doing the compute in the browser. And it's way faster. Like you don't have to set up a local environment. Like if you want to check out two branches at the same time, you can't even do that on your local machine without cloning the repo separately. But in StackBlitz, you just, crack open in a new tab. You can have every branch of the repo open at the same time independently. And certainly for like learning and rapid prototyping, bug reproductions, et cetera. So I think for us, as far as what do we wanna, what does it make sense for us to put out there as open source? I think things that help advance this general direction of the technology, cause we don't really, I think that this is an inevitability that I think, from our view, we think the entire world should be running on web assembly based tool chains. And so we wanna help facilitate that process. Um, and so we kind of view our core technology as something that's going to be kind of this ever receding proprietary ness and will be continually moving into open source. 

DAN_SHAPPIR: From my perspective, just second, AJ, from my perspective, it, uh, looking at your, uh, uh, initial blog post slash press release, you know, the, the thing that you were mentioning there is node, but from, from the way that I'm looking at it and it kind of resonates off of something you said is that the key thing really is that container that you've built. The analogy that you gave to Docker, I think that's really key. I mean, okay, great, you're running Node within it now, but essentially you could run more or less anything that you can compile down and that's sufficiently compatible with the operating system that you're effectively running within the browser. So it's no today, but tomorrow it could be essentially almost anything else. That again, that you can compile down, I guess, to WebAssembly.So, and I think you're calling it web containers that, that like Docker thing. Correct. 

ERIC_SIMONS: Yeah. Yep. Yeah. And you hit the nail on the head. Cause I think that's, that's exactly where, if you kind of look at our road map here and the R and D that we're doing is today, we're starting with Node.js and we have pretty broad support. We're in beta and there, there are certain things that are missing right now, but in the next 90 days, I think it'll be hard pressed to find things that are not implemented or, or, or just wouldn't be possible, you know, to do in a browser or something like that. And I think beyond that, it's, it's absolutely right. Like enabling other languages to compile down and be able to access the web container, your core interfaces, right. And like something that can be standardized and is something that will enable not just like Node.js devs to use such a thing. And there, there's a lot of interest, like one of the core people in the Python community or, you know, one of the core developers of Python tweeted out, you know, when we announced this thing, he was like, this is why, you know, the Python community needs to need to really focus on web assembly because we need to be able to run it in something like web container, right? So it seems like there's a lot of interest and momentum for other languages to really start, to start thinking about this in a serious way. 

CHARLES MAX_WOOD: So here's, I guess, where I'm wondering what, what the limitations or what, what the pros and cons are, right? Because what we're talking about here is you're talking about being able to run certain things on a web container and other things, not so much, right? And Dan's talking about kind of operating system level things, but it's limited by what WebAssembly can do, correct? 

ERIC_SIMONS: In a sense, yeah. So WebAssembly is definitely a key piece. I think the other thing that it's limited by is just browser capabilities. And so this is one of the things that, like the key insight that we had a couple of years ago that kind of led us down this path, it took us years literally to build this thing. And the key insight that we have was that browsers had gotten a lot more powerful than we or anyone else had seemed to realize. Because with the advent of WebAssembly and WebAssembly threads, where you can have shared memory being shared across different threads. On top of the Fugu initiative from Chrome and Microsoft, these other folks are like the file system API. I don't know if you all saw that, right? But like web apps can now actually request read and write access persistently to a portion of your hard drive, right? And we're like, holy crap, this changes everything. Because now you're talking about APIs being available that would allow you to write an operating system that isn't just like some science project thing, but like actually would allow you to open a browser tab, mount your Next.js app from your development folder on your computer with Read&Write access and run an entire OS inside of the browser tab itself, running node, running MPM, without even needing those things on your computer. That's crazy, right? Like you'll actually having this Read&Write back to your real file system, acting as like this bridge to this operating system that has all the stuff you need, like this super fast development OS that you can take anywhere. And so it's like, and so there's kind of like a web assembly is a huge piece of this, but there's what they're doing on the Fugu side of this bridging the, essentially the gap between what's an electron app versus what's a web app or what's a PWA or whatever. That's really made this possible in a, in a realistic way. So there's kind of a handful of things at play here.

DAN_SHAPPIR:  I just wanted to mention that if anybody's who's listening is interested in project Fugu, we actually had Thomas Steiner from Google on episode 450 talking about the details of that project. So yeah, the fact that Google is opening so many APIs for access from within the browser is incredible. And it's also excellent that Microsoft is following suit because effectively Edge is the same as Chrome these days, or almost the same, but it can do all this stuff. Now we just need Apple to do it. 

CHARLES MAX_WOOD: I guess the piece that I'm trying to pick at here though is as you mentioned, yeah, Python needs to get on board with Web Assembly and, and things like that is that it's not going to run all of the native programs that I'm used to seeing run on my machine through the, the browser on these web containers, but it is going to allow me to virtualize certain aspects of the things that I'm writing, not even necessarily in JavaScript, but in anything that will compile down to WebAssembly or that will run in a browser under certain contexts. And, and so anything that can take advantage of some of these powerful features and then reach through the browser into file systems or other systems that are available to my machine through Bluetooth camera, GPS, et cetera, et cetera, et cetera, et cetera, right? Any of this stuff I can package up into a web container and take advantage of this stuff that comes with what's here. And yeah, I can run it on my machine. And so I'm just curious, like what kinds of things can I put into it? What kinds of things will I not be able to put into it? And then as some of these languages come around to the point where maybe I do a bunch of Ruby, but Ruby, or maybe even like C compiles to Wasm or something like that. What are the capabilities that I'm going to have with web containers in the future as we see some of these things come around? Are we going to see some DevOps capabilities for this? I don't know. 

ERIC_SIMONS: Yeah. No, it's a, it's a really good question. Right. And I think so like today, right. It's if you're doing our kind of the first target audience that we're trying to, to provide a real development experience for is like web developers. And it kind of makes sense. Like if we're, if we're making an IDE that is, that runs on the web, like web developers should be the first folks that get what we're up to, right? Like they should understand the value prop of a web app that allows you to make web apps and and so today it's like, you can, you can run full stack tool chains entirely in this thing, like next JS, et cetera. You can write your own custom scripts and et cetera, right. So very broad support for node JS. I think after that, right. It, you kind of entered this interesting and there's a lot of work happening on this. So there's the web assembly standard interface work and there's a company called Wasmer that's been doing stuff in this, but essentially they're trying to bridge the gap of like making it easy for developers of these other, these other languages that need a binary, right? Cause like when you, when you run Python or Ruby, you have a, a binary that is, that is interpreting that code or compiling that code, right? We need those compilers to be actually distributed as web assembly modules. So you'll have web assembly modules that take Python code in and then output web assembly modules. Right. And so that's kind of an active area of work that all these other languages are starting to do right now. You know, cuts to varying degrees, right? But I think that's kind of big change that we're going to need. And so like, yeah, could you do DevOps stuff in this? Like, absolutely. Right. There's, there's, there's a lot of pavement that's got to get laid here in order for it to be simple to do these things. And there's going to be new types of workflows and certain stuff isn't going to just work one for one, but once you kind of get a taste of the future here, it just seems, it just seems rather obvious that like, dang, this is, this is how software development should be done. It's super fast. I don't have to install anything. It's, it's incredibly secure. It gives you the strongest security guarantees of any developer environment on the planet. And so I think that there's certainly a lot of work that we're going to have to do here. And even just in the, in the Node.js ecosystem, there's a kind of a movement to, for like bundlers, people are utilizing lower level languages like Rust or Go or whatever to write things like ES Build that are incredibly fast. But yeah, and a big part of what needs to happen though is that instead of just compiling native binaries, they need to be available as WebAssembly binaries. And like ESBuild is available as WebAssembly binary, right? And so like people need it. You know, we have this universal, secure, fast runtime format called WebAssembly. And it's time the world that just starts adopting and really treating it as the canonical runtime target. 

CHARLES MAX_WOOD: Yeah, I have one more follow-up question. I know everybody else wants to ask questions about this too, but I'm trying to figure out where this fits into the ecosystem with everything else that we have, right? Because we have web apps, we have mobile apps, and then we have sort of dev tools that live on our machines as kind of command line utilities. And then we have like IDEs that are kind of more desktop apps that this is kind of subsuming some of that, right? And then we've got kind of the spectrum of all kinds of other things that we grab, you know, we have Docker containers that get deployed to the cloud. It seems like this can kind of live in some of that space, take over some of that space to a certain degree, or maybe just kind of live alongside some of that space. So where do you see this fitting in with some of these other pieces that we've already kind of engineered to solve some of these problems? 

ERIC_SIMONS: Yeah, I think, yeah, time will tell. I think there's a lot of opportunities. There's a lot of benefits that you gain from taking this approach. And I think off the bat, I think for developers, because there's kind of two different variants here, where you have like, this is technology that enables new types of developer environments and even like production applications you can make, right? So I think on that side, I think that there's the most immediate value that at least that we see is using this to create instantly booting secure by default environments for developers that can be shared in a URL. That's I think that's like, that's kind of the first very tangible use case that we see in it seems like people are adopting it rather quickly at this point too. And I think beyond that though, there's a question internally right now that we're kind of pondering, we've gotten some demand for this already, which is using this to actually build, as a baseboard to build really powerful applications that normally you would need to use something like Electron to do because out of the box, yes, the web does give you web workers and et cetera, but it doesn't give you a nice interface to just seamlessly be, it's much easier to write a multi-threaded Node.js application than it is a multi-threaded web app, right? So what would it mean if we released this as something that you could just npm install and now you can build a desktop-grade application that's delivered in a browser, right? That's one angle. What does it mean to use this in a similar way as Cloudflare workers uses V8 to run their workers platform? What would it mean to be able to run like a web container at the edge instead of having a Lambda actually spinning up Node.js, right? What if you're actually just spinning up a WebAssembly based environment that again, boots instantly, is incredibly secure, signed to be multi-tenant, right? Like there's kind of a lot of interesting implications here. Some of them will pan out to be gangbusters, some of them will pan out to be dead ends, but it definitely seems, it seems like there's a lot of potential in a lot of different areas for this thing. 

STEVE_EDWARDS: So, I had a question just in terms of resources and you know, obviously to run an application, you're gonna have to have resources to run node and run everything, you know, from memory and CPU and so on. So moving it into the browser on the surface, it just seems like it's six to one half dozen of the other. In fact, you're taking all your resources that you need on your computer and you're moving it into the browser. So is the benefit, if I'm understanding correctly, that basically your browser is able to do this much more efficiently than a normal local development environment. And that's why it's faster. I mean, cause it seems like, okay, I need 50% of my CPU, I'm moving into the browser. You're still going to use 50% of your CPU and your computer, but apparently that's not the case. It's because the browser is much more efficient. 

ERIC_SIMONS: Yeah, great. Yeah, really good question. So basically, like, this is one of the things that, like one of the kind of the key things that we identified that we're like, this seems crazy, but it actually should be faster theoretically, which is that when you look at your local development environment today, for web development that is. If you look at Node.js, like there's kind of three things you're really using at a high level. You're using Node.js to run your scripts. You're using VS code to edit your, you know, your jobs profiles or whatever. And then you have Chrome open and previewing your application. Right. So if you break that down though, you're actually using three, three different copies of V8. One is in Node, one is in VS code because they bundle Electron right together. And then you have the copy of V8 that's in Chrome. And actually with Node.js on local, if you're running a script that's using a dozen processes, you have 12 different copies of V8 running at the same time. And so you're paying this multi-process overhead that your operating system inherently puts on when you spin up a new process. But the reason web apps are able to boot so fast is that you're sharing one copy of V8 across your entire browser. And so in V8, it's called isolates. Essentially the analogy to like a typical operating system process called an isolate in V8. It provides really fast, really secure context switching. So by actually bringing Node.js into the browser, right? And bringing VS Code into that same browsing environment as well, and previewing the app all in Chrome, instead of having dozens of different independent copies of V8 where they cannot share any isolates between each other on your local machine, you're only running one copy of V8, where all of your isolates are coming from the same context essentially of your browser. So you actually cut out a huge amount of process overhead that you incur on your local machine by this incredible inefficiency of ripping V8 out of Chrome and then slapping it in a whole bunch of places. Right. And so that's kind of the, for the runtime performance, that's the big thing. And then on the NPM side, it's actually substantially faster to install the stuff in your browser because browsers are, you know, have gotten really good at making network requests and caching those. So every time you load the page, we actually do a fresh NPM install. Cause it only takes a couple of seconds. And it guarantees you get a fresh new... 

DAN_SHAPPIR: Yeah. 

AJ_O’NEAL: You're telling me that downloading a gigabyte of NPM modules, that's... Sorry, I don't believe that. I'm calling BS. 

ERIC_SIMONS: You can try it. 

AJ_O’NEAL: You don't have to have a gigabit connection for that to only take a couple seconds. 

ERIC_SIMONS: Yeah. Well, I mean, if you're on terribly slow internet, your results may vary, but fundamentally, once it ends up in your browser cache, it's not going to network to download a gigabyte of node modules. So that's like on your first load, it might take you, I don't know, 10 seconds or something. I mean, depending on, 

AJ_O’NEAL: a gigabyte? 

ERIC_SIMONS: Oh yeah. This stuff's fast. And on top of that, so, but the benefit of actually being able to own the containerization layer is that we can also be very smart about not downloading things that are not on the critical path of execution. So we can actually, 

AJ_O’NEAL: Okay, that I can believe that, that I can believe you've got some smarts there, but I, you can't download stuff faster than the person's internet connection. And you don't have to have a slow internet connection. I mean, a gigabyte's a lot of stuff. That's, 10 hundred megabytes. So if I can download 10 megabytes per second, it's right. 

ERIC_SIMONS: Well, it depends on the project, I suppose. But I mean, I think you're probably talking about the unpacked size of a kind of a typical Gatsby project or something at that size. Right. 

AJ_O’NEAL: Create React app. 

ERIC_SIMONS: Yes. So when you talk about Create React app, right, the size on disk is not the size over network. Right. Like, you know, Brotli and Gzip are very popular ways to compress this data down to something pretty reasonable. And again, so I think there's a difference between on the first hit, you're going to pay a bit of a, you know, if you try it on statpix.com, you know, because we're not using servers for any of this stuff, you can just try it without logging in, right? But you can kind of get an idea of what we're talking about where it's actually quite fast download even on the first run. But if you hit the refresh button, sometimes you'll even see it in like a couple hundred milliseconds complete, right? 

AJ_O’NEAL: How is that possible? Because if I just call, now it's been a long time since I've done this, but if I call VM.compile from the private node API on some code, it takes time to parse the code. If everything's already available and all NPM is doing is just relinking from its global cache, it still takes several seconds to install something large and then it has to run it. And that VM.compile step is not fast, it's slow. It's slower, much slower than the fetching it from the disk speed is. And it's been years since I've done this. So maybe VM.compile is now almost instantaneous or they're using those tricks where it's half scripting, half compiling, and then delaying the JIT further or whatever. 

ERIC_SIMONS: Yeah, well, I'm not sure exactly what it would be compiling because I think they're kind of two separate steps, at least, where you're talking about essentially scaffolding out the node modules folder, which is kind of during the installation. And then any execution would be getting triggered through like the command line, right? Or something akin, right? Where it's actually just loading that stuff in and evaluating it. You know, wild, right? 

AJ_O’NEAL: Yeah, yeah, yeah, yeah, yeah. That's the evaluation steps. I just, like, I'm, you're telling me that it's faster. I'm not quite grasping this all. Cause when you say that you created an operating system, basically what I'm imagining is WSL for Wasm. You're running Linux node on WASM through a WSL one like interface or a wine like interface. That's just emulating sys calls. And I would imagine that there may or may not be overhead with that. I could see how there might not be overhead. And you're saying that it's because the sys call to create a process is actually not creating a process, but creating an isolate it's allocating less memory. But like, what about garbage collector fighting? Cause cause when they originally wrote Deno in Go, the reason that they didn't continue and switch to Rust was because the garbage collector would fight against itself. So if you've got a garbage collector in V8 and then you're emulating an operating system and then emulating, well not, you're emulating an operating system and actually running V8 again that has garbage collection, isn't there a problem with garbage collection fighting against itself? 

ERIC_SIMONS: So that, yeah, that's actually kind of the beautiful thing about, about the model and the other people who have tried to do this did exactly what you're describing and hit that exact issue. Right. So, so the key, the key thing here is that we're not bringing another copy of V8 to the browser. We've actually ripped V8 out of Node and are using the built-in copy of V8. 

AJ_O’NEAL: You said that. You're doing something mind-bendy that I'm not quite sure of how to put this in a frame of reference with what I know about operating systems and Wasm. And granted, I have not dug into Wasm deeply. I've watched several presentations at local meetups on it. And so I kind of get you know, some, some reference for it, but I'm super interested in this. 

DAN_SHAPPIR: I have a question about that. So you just said that you ripped V8 out of node, which makes total sense because you want to, there are so many benefits of using the V8 that's built into the browser. Just as an example, you can debug the JavaScript code that you can, that you write using the built-in browser Chrome DevTools and I've actually done that with with your demo environment, I downloaded it, I put in the debugger statement and I had the dev tools open and it works. So that's pretty freaking amazing from my perspective. So yeah, but it does mean, I guess, that you had to construct your own version of Node because you had to rip out the stuff. So you're not running standard Node, you're running your own version of Node. So my question then becomes, how do you maintain compatibility with Node going forward? I mean, you know, they keep releasing new versions of Node. Does that mean that you kind of have to run after the official Node version and constantly update and upgrade your own version? 

ERIC_SIMONS: Yeah, yeah, absolutely. Yeah, and that's exactly it is that, you know, we've built a tool chain that takes Node from source and applies our own OS level calls and et cetera, and parts of V8, right? Like own wrappers around that stuff. And so yeah, when new versions of Node come out, it'll be part of our job to run that tool chain and verify compatibility kind of et cetera, et cetera, right? The- 

CHARLES MAX_WOOD: You guys are crazy. 

ERIC_SIMONS: It's, you know, it might sound like, I mean, it's been an incredible amount of work building this like WASM OS and like, you know, this is definitely the, there's not a lot of prior art for a lot of what we're doing. So which makes, you know, whenever you- You talk about doing something like that. It's you spend an incredible amount of work figuring things out that other people will, will be able to kind of just kind of reuse, um, after the fact. But the benefit, right. Of, you know, we, we spend years making sure that we built this in a way that would be actually pretty straightforward for us to, to maintain and grow. So it's actually a lot of the groundwork is really laid here at this point. And so when it's, when we talk about switching from adding another version of node, It's as simple as in our workbench just saying, cool, node version 16.blah, pull source and run compile runs against our test runners. We see what breaks, et cetera. It's actually, it's not, it's not like we have to like go and kind of pluck through their source code piece by piece or anything like that. 

 

This episode of JavaScript Jabber is brought to you by DigitalOcean. DigitalOcean recently announced their new app platform service, which is a solution to build modern cloud native apps. With app platform, you can build, deploy and scale apps and static websites quickly and easily. Simply point your GitHub or GitLab repository and let the app platform do all the heavy lifting. As it has support for Node.js, Python, Go, PHP, Ruby, static sites, Docker, and container images, DigitalOcean runs their app platform on their own infrastructure, so your costs are significantly lower than the other products. Plus, they build this new app platform on top of DigitalOcean Kubernetes, providing a smoother migration path so you can take more control of your infrastructure setup. As a listener of JavaScript Jabber, you can get started for free. Better than free because DigitalOcean is giving you $100 of free credit because DigitalOcean is giving you $100 of credit when you go to do.co.jabber. Again, go to do.co.jabber to get your $100 free credit on DigitalOcean's new app platform. We want to thank DigitalOcean for sponsoring this episode of JavaScript Jabber.

 

DAN_SHAPPIR: And so you've effectively created your own version of Node. You mentioned before that you have your own version of NPM that's kind of different than the standard NPM because you mentioned that it's, it's kind of optimized to run in your specialized environment. I guess there's also other reasons for having your own version of NPM. Maybe you can describe them. I assume you also have your own version of Git or a Git client because you need to be able to do Git and your own special version of VS code. Does that mean really that anything that I'll want to put inside the web container I'll need to create my own special custom version of? 

ERIC_SIMONS: No, no, and so I think that it's less that we've created a version of Node. I mean, it's the Node.js binding source code. Like you view source on it. Like you can actually kind of, someone on Twitter did this, they compared it against the actual Node.js source code and they're like, holy crap, this is actually one to one. Right what the only things that are swapped out are the parts that are done with like C++ and like, et cetera. And all of those are done to spec, like not even, they don't even have specs for this stuff. We had to like step through exactly what's, what was going on the C++ side to figure out exactly how it needed to work to be 100% parity. So you're really, what you're doing is you're using a version of node that is operating identically to the version. Like right now it's like 14.6 or something like that, I think that we've got on prod operating identically to how that works in your local environment. Right. 

AJ_O’NEAL: So both first Mozilla and then later Microsoft, I think of Mozilla tried to get Jaeger Monkey in Node and Microsoft was getting Chakra in Node and both of those projects were abandoned and now the entire Microsoft browser has been abandoned. So did you use their work? I know at least with Microsoft, they actually kind of paved an inroad to have a better binary API to be able to swap out the C++ code. So were you able to step stone from that prior work with Mozilla and Microsoft's attempt at replacing V8? Or was this a completely different path and you had to just trailblaze something utterly different? 

ERIC_SIMONS: Yeah, unfortunately it's the latter. I wish there were, yeah. If we could have used something prior art for nearly any of the stuff we would have, but this that no one had ever really tried to do anything quite like this, you know, is very different. 

AJ_O’NEAL: You're keeping V8, but what you're replacing is the the operating system binding bits. So that's why this is particularly different. 

ERIC_SIMONS: A bit. So it's actually what's kind of crazy about this, though, is that this is actually the first time that the Node.js runtime actually can run natively on top of Firefox and Safari the JavaScript, the respective JavaScript engines inside of those browsers. Because the way we design this is that we, when you can assume that you have a spec-compliant JavaScript engine, then you can actually just rely on that instead of like internal, like V8 APIs or JavaScript core APIs or chakra APIs, whatever, right? And so this is actually, this works cross-browser. We've, we've got behind a flag, at least for like, so far it needs to ship web assembly threads, but Firefox has everything we need. We just need to get a couple of our end-to-end tests fixed there, but that's what's kind of fundamentally different here is that, is that we're making, you know, we're relying on the existing JavaScript engine inside of the browser itself. 

AJ_O’NEAL: Okay. So it's, that's, yeah. It's okay. So you're not so, okay. So this does sound kind of similar to the Microsoft chakra thing. Okay. And then what about NAPI is that that's just not relevant at all because NAPI is all about C plus plus node modules from the user space and, and your, your downstream of that. So NAPI is not relevant to you guys, right? 

ERIC_SIMONS: Yeah, yeah. At least, yeah, it's not something that we see, I guess that we're initially targeting, I guess, for things that we wanna support. You know, internally like, my role in George's. 

AJ_O’NEAL: Oh, so NAPI modules presently won't work? 

ERIC_SIMONS: Yeah, anything that's gonna need to like, touch binaries, right, that are not available as WebAssembly modules will not work. That's like a key limitation here, is that it has to be available as a WebAssembly module. So, and there's a lot of people switching stuff over to WASM at this point. 

AJ_O’NEAL: Okay, so NAPI might, die to give way to Wasm because I've heard about you can, I think at least with Rust, there's actually a presentation I'll have to put in the show notes, but with Rust, you can compile Rust and Wasm and get it to run something in Node if I understood correctly. And so that's what you guys are kind of relying on. So in API, it sounds like as a project may just die because Wasm is so much more fluid and delightful. 

DAN_SHAPPIR: And secure 

ERIC_SIMONS: and which is a huge thing, right? And so I think back when Node.js was invented, like, and so our kind of viewpoint on this, right, is like Ryan Dahl pulled V8 out of Chrome and brought it to local so that because JavaScript is awesome and we want to use it to write native tool chains in the sense we want to access more than the browser would allow us to, because browsers have to take a long time to implement things because they have to be incredibly fast. They have to be incredibly secure. Right. 

CHARLES MAX_WOOD: But by taking that- Backward compatible.

ERIC_SIMONS: And they have to be backwards compatible. But if you look, compare that to how the Node.js ecosystem has turned out, I don't think you could find a person that says that it's incredibly fast and incredibly secure. If anything, it's actually one of the worst offenders of security vulnerabilities of any of these things that have popped up in the past decade, right? 

AJ_O’NEAL: Well, we're talking about NPM specifically, right? Like, you know, the ability to get one of 10,000 modules infected with something and then that be brought in. 

ERIC_SIMONS: Absolutely, right? I mean, NPM and there's the security model around Node.js itself could be improved, right? And I think a big problem- 

DAN_SHAPPIR: In fact, Dino exactly does that. That was one of the motivations for Dino. 

ERIC_SIMONS: It's exactly right. And so the reason, right, that, you know, we talk about like NAPI or like, you know, just using binaries and having post-install scripts, which is this huge unmitigated, you know, security threat in the NPM ecosystem. The reason all of that was done in the first place is that we didn't have a secure binary format like WebAssembly at the time, right? The future wasn't here yet, but we, as the development, the web developer ecosystem, needed something right where we could write JavaScript for our tooling to actually compile stuff for the browser. And but we're not using the 

DAN_SHAPPIR: I'm using me enough. We did have the JVM but nobody wanted to use that. 

ERIC_SIMONS: Yeah, yeah. Like no Jess has been great. I mean, and it's been explosively popular. It's just we live in a different day and age today, right? Like we have we have affordances that we that we didn't used to when these original design decisions were made. And so this coming coming back to, you know, I was on a podcast earlier this week where they were, we were talking about with the ripping the V8 out of Chrome thing. And you're like, well, isn't that, don't we want these, don't we want Node.js to be coupled to a specific version of VA? And it's like, why would we want that? Right? Why, why would we want to like, isn't it more ideal in the same way that I wake up and open my browser and it automatically installed and updated and it's faster and it's more secure every day. Right? Why do we not want that for our developer environment? Why do we want to be coupled to a specific version of V8 that's going to be outdated the day after Node publishes the thing and is going to be sitting there forever when we can actually have evergreen dev environments that just are continually getting faster and more secure? Right. Well, I think that's the benefit of leveraging what all the billions of dollars, Google and Microsoft, these other guys are pouring into making browsers the fastest, most secure evergreen runtime environment on the planet. 

AJ_O’NEAL: I also think that there is, I don't know if it's if it's budding or wilting, but there has been some buzz around the idea of evergreen servers, which may be in the age of Docker and you know, things that you've got low reliability, high availability things where the stuff's going to die off anyway, and then you're just going to get a new one and you're never going to know. So I guess maybe that's not maybe that won't come to be a budding concept, but I think it's cool. The idea that that you could hot well. I guess, I guess we already have tools that solve this problem in other ways. So it's probably won't come to fruition, but I think it would be cool to have hot swappable server-side stuff as well. 

DAN_SHAPPIR: Well, it's called serverless. 

AJ_O’NEAL: Well, that's not the same because you aren't really getting access to things and everything's an API and that's a completely different design architecture.

DAN_SHAPPIR: Yeah. Well, that's the way of the future, I guess. You know, everything's supposed to be an API, the JAM stack and whatnot. 

CHARLES MAX_WOOD: Well, and what's interesting is, is that a lot of the things that we end up with start out with an idea like this. It's kind of this, this big, but big idea. And then we wind up somewhere where there's a benefit or at least a trade-off that makes sense for a certain segment of the community. Right. And so, yeah who knows where that will wind up taking us? 

DAN_SHAPPIR: It will blow my mind, for example. And I guess Eric, you probably guys thought about this possibility as well of, let's say instead of doing a Docker, I could put puppeteer on the server side and then run a web container within puppeteer. If I can, if I can then expose an outbound address, so I've got myself a server. That would be a very interesting proposition.

ERIC_SIMONS: Yeah, definitely. I think that that's one of the opportunities that we're probably going to explore. Once we hit general availability of web containers just as dev environments, I think production environments, like running it on a server is rather compelling because your browser is designed to be multi-tenant by default. Like every web app is a separate tenant and it has to be secure multi-tenant. And if you take that and use that to run back end servers, right? You can have incredible multi-tenancy with really strong security guarantees, but with a full OS interface. This is what like, you know, Cloudflare did exactly this with Cloudflare workers. They ripped V8 out of Chrome and they let you run service workers at the edge, but, but you don't get all the things that makes Node.js actually really great. Like running real servers, running real back-end code, being able to actually shell out and having multiple processes, right? Because there's just never been an operating system that could securely run within browser contacts, right? So totally, I think that this is, this future has already started with like what Cloudflare is doing. I think it's just going to continue to ramp, especially with this sort of thing. 

DAN_SHAPPIR: So I have a technical question and a more general question. So I'll start with a technical question. So you were talking about how Project Fugu with the file access APIs enables, gives you access to the local file system that, so that you can effectively actually open a local file off of your file system and then start developing that way. And also obviously you've got the built-in file system so that, like you mentioned, you can do an NPM install, like just when you launch the web container, do you actually have like three layers? Because I'm thinking you have that external file system and then in the context of the internal file system, it might be persistent or it might not be persistent. So how do you kind of decide what goes where? 

ERIC_SIMONS: Yeah, so we actually have a standard, for the file system specifically, part of Web Containers operating system includes a postage-compatible file system, which is designed to be pluggable and can, so you don't have to connect a folder on your computer or whatever to StackBlitz. You can actually just like save it to the cloud or just like commit directly to Git. Like you don't have to read and write from your local disk, right? But you can actually plug that file system interface, you know, like when you click, Hey, mount this to my computer. We're actually mapping that into the web container post six file system interface. Right. So it's actually, you can plug it in and with any number of different sources essentially. 

DAN_SHAPPIR: And you also mentioned the TCP stack that you built on top of a web services. Could you elaborate about that a little bit? 

ERIC_SIMONS: Yeah. So, I mean, part of web development, right? Like it's pretty, pretty important to spin up dev service servers, like webpack dev server, like whatever have you. And so this was, again, one of these things where there's not a prior art that was pretty difficult to do was like, how do you, your browsers actually have a built-in proxy server with service workers and you can spin them up on demand, right? And so essentially, I mean, the, the short of it is that we have a, a TCP layer that, you know, Node.js, you know, on local is interacting with and in, in StackBlitz web containers are doing the same thing and that's actually getting mapped to like the service worker API and the web socket API and et cetera, et cetera. So you can actually spin up like, you know, GraphQL, JSON endpoints, like entirely inside of your browser. 

DAN_SHAPPIR: So you're not really spinning up a TCP connection, you're spinning up a TCP, an emulated TCP connection on top of a web socket or something like that? 

ERIC_SIMONS: Yeah, it's a virtualized TCP network stack, right? Cause like, you know, obviously the, well, there are standards being pushed forward for like actual TCP access in like browsers. But in this context, right, like you have a virtualized TCP network stack that is, again, supporting all of the same calls that noted would be doing under the hood on your computer, but actually mapping it to the service worker API request response, life cycles and web socket APIs and things of that nature. 

DAN_SHAPPIR: So if I want to be, if I want to develop a web application that has a front end and a backend, I would effectively, I guess, open two tabs, I guess, and they're coming from the same domain, which is the StackBlitz domain. So so they see the same service worker, I guess, so they can talk to each other. And I could run the server within one instance and a client within another and have them communicate with each other and debug them that way or something like that. 

ERIC_SIMONS: Yeah, you could run them in the same StackBlitz project. You can have thousands of HTTP servers running in a given StackBlitz workspace, right? Just like you could on your local. You can just define a different port number and have two different commands that you're running in the terminal to run or have a single command that starts them both or whatever. Right. So you can actually run multiple at the same time, 

DAN_SHAPPIR: but I could also communicate between tabs if I wanted to as well, I guess. 

ERIC_SIMONS: Yeah. I think right now for security reasons, we actually don't allow it, but you know, in the future, you'll be able to say enable access between this project and that project and that sort of thing. Right. Cause again, like a security is like one of the number one things that we focus on like speed and security or the you know, kind of the key things that we always look at and which is in this context, it's actually pretty crazy because it actually provides one by using service workers to actually give you the responses for your dev server. It actually has less latency than local host. Cause you're never actually reaching outside of the browser. You're just, you're going, you're completely routing that request in memory. So it's faster to load this stuff than your own local host development is. But the second thing is that it's actually more secure because if you have some daemon on your computer that's scraping your local host URLs, trying to get your development data out of it, you're actually not going to, when you curl that URL that you're seeing in stack, but you're not going to get anything because it's actually only serving within that Chrome security sandbox. Right? So it actually provides you a stronger development security guarantee than using local host would. And it's faster than local host, which is like mind blowing. 

AJ_O’NEAL: So I, I completely believe you on both points. I I'm following you. I get it. Just curious, other than the cool factor, is there a pragmatic? I'm just like, if it's a development environment on a development machine, what what harm would it be if some rogue process is accessing local hosts? Like what are they going to it seems like that would have to be such a targeted attack that increased security would not prevent the attack because you'd be dealing with an organization that has the type of funds and competence that they would find some way to social engineer. I mean, if they can attack your machine and your development process that specifically, it seems like they basically be in the office building and you're just like waiting for them to find the right moment to get somebody's computer almost. 

ERIC_SIMONS: Maybe 10 years ago. Supply chain attacks are incredibly common in the solar winds, right? I mean, this stuff is happening at a really rapid clip. What's going on is people are sneaking in software through the dependency chains and et cetera. And especially again, with the unmitigated risk of post install scripts, when you install, they can install anything on your computer. 

AJ_O’NEAL: I get that, I get that. No, I'm with you on that. I'm with you on the NPM install process. I was talking specifically about this. You're saying it's more secure that the local host doesn't, is basically a socket rather than, well, a private socket, a read, a user, but in this case, even more specific than that, a process, I guess. I guess it'd be like a C group in Linux, maybe. Anyway, like nevermind. It's not that important. 

ERIC_SIMONS: It's, I guess to answer the question, for the average developer, maybe not, right? But I think when you're talking about the people that are writing the software that glues together the fabric of our society, like the guy who's writing the UI. 

AJ_O’NEAL: I think that's called the human heart, brother. Well, I get what you're saying. I get what you're saying. 

ERIC_SIMONS: You know, the guy who's writing the UI that you use to send money to your grandma for health. cost or whatever, right? It's important that we give these people developer environments that are secure by default, where when you're doing development, you have test data and credentials you don't want to have leaked out, especially when you're talking about Fortune 100 orcs that are dealing with finance and healthcare data and governments and things like that, right? So this stuff matters. And on the flip side, even for someone who's just learning how to program, we want to I think we want to give people environments that are incredibly fast, incredibly secure so that they are well positioned to go create the Fortune One, or whatever they want to build. I think on flip sides of the coin, I think focusing on security is a good thing and trying to make it something that by default is way better. 

AJ_O’NEAL: Okay. So next question, why can't I find StackBlitz on Robinhood?

ERIC_SIMONS: Yeah, maybe someday, maybe someday soon, probably not too soon, but we're not public yet, at least. 

AJ_O’NEAL: Okay. Well, send like tweet it out when you, I'm going to follow you on Twitter, tweet it out when you are. I want to, I want to pick some of this stuff. Like I give you a hard time. I give everybody a hard time. I, maybe if I don't remember last time we spoke, but, but this is really cool stuff. Like I'm super impressed. This is one of the few projects where I'd say, man, I wish that I was involved in this. I'm probably not smart enough for it. But I wish that I had been there because you're doing some really cool stuff. And I just like, this is really awesome. 

ERIC_SIMONS: Thanks. Yeah. I think, I think everyone, we had no idea how to do any of this stuff when we started the company, right? So it's like, it's a couple of years and focusing on something for awhile intensely. You know, I think, I think, I think everyone here in private listening could, could, could work on this stuff, but it's been a lot of fun. We've learned a heck of a lot and we're still learning a ton.

DAN_SHAPPIR: I just have the one, if I may. I'm like, like AJ said, I'm like really blown away by the stuff that you're describing. So my obvious, and, and, you know, I'm still processing a lot of what you're saying. So my obvious question is what's next. I, what are you planning going forward? What are your next big things or what are the hills that you're looking to, to conquer next in the context of this?

ERIC_SIMONS: Yeah, I think the immediate stuff is that we're really, we're pretty laser-focused on nailing runtime compatibility of Web Container, like making it, you know, today there's there's certain packages will try out that will use an API that's not fully implemented or has a bug or something. And so we're trying to hammer out the bugs as fast as we can. And I think I might have mentioned this earlier, but like, you know, helping the ecosystem flip over things that are currently, you know, local native binaries over to WebAssembly, right? And there's actually, it's been kind of amazing since we launched. There's, I think, all of the major bundlers are now actually either have a PRs landed for web assembly support or are in progress. So I think the big thing is like helping, helping get the world moving in the direction of flipping stuff to web assembly, I think is probably probably one of the longer running tasks we've got here. But I think towards the end of the year, we're going to be rolling out, you know, kind of the full stack, let's be two experience. And it's going to be pretty crazy because it's, if you can kind of imagine like what does it mean to be able to open up a dev environment in a link, especially when you're talking about building web apps, like on your, you know, you have a blog and you write it with Next.js and at the bottom of the blog, it says, edit this page and you click that. And then it takes you to this live environment that's got the markdown file, that blog open, it's got the dev server preview of that blog post on the right. You make your changes, you click open pull request, and then it goes live on prod cause you know, Vercell redeploys it, right? It's kind of like a developer CMS or something, the sort of experience we're talking about. There's kind of a handful of cool things we're gonna be rolling out with that. But it's, so I think that just for the web development world, there's some pretty crazy workflows that I think are gonna get enabled. Like I don't think we've even seen the tip of the iceberg at this point of like what this stuff can do just for web development. 

DAN_SHAPPIR: Well, Chromebooks might be popular again. Ha ha ha. 

ERIC_SIMONS: Totally, they finally have an OS interface now.

AJ_O’NEAL: Do you think they'll make it so that you can print a PDF as a four up in a Chromebook? Because until that happens, no. 

CHARLES MAX_WOOD: I was going to ask what was coming next for StackBlitz the editor. And I think you kind of answered that. So that's interesting. I was also curious, will this work on my phone? 

ERIC_SIMONS: If there's, if you have an Android phone, it totally will. I think that on iOS, we're still waiting on Apple to ship web assembly threads. I imagine it probably depends on how much memory the tool chain you're using like requires. You could certainly run a hello world, no JS application though. Like something like that. If you're, if you're writing something that's like production-grade, maybe not, but on iPad, like once they ship web assembly threads, we're excited to get our hands on the latest there because iPad should have more than enough horsepower to handle real development workloads here. 

CHARLES MAX_WOOD: All the Android users just went, yes, finally. Everything ships for the iPhone first. I mean, I have an iPhone, but it's just funny because I'll be talking to people and they're like, like clubhouse, right. And ship for iPhone first. And yeah. And I'm like, I'm on clubhouse and blah, blah, blah. And people are like, 

DAN_SHAPPIR: historically and from experience, because I was actually working at a company that did remote access solutions from within the browser. So we were facing, you know, it, the architecture was obviously totally different, but some of the similar challenges and one of the bigger things that you, you actually have to face when moving applications that were designed for desktops into the mobile form factor is the form factor. I mean, you're talking about VS code. VS code was not designed to run in a phone with a small screen and a touch interface. So that's obviously going to be... So theoretically, you could get it in there. It's just that the user experience could be terrible. Now, on an iPad, especially the new ones with the big screen, well, go for it. Although as I I don't know, maybe Apple changed that, but they weren't, they, they intentionally don't have virtual memory. So you could run out of memory if you're, if you're like too aggressive with what you're doing within, within the browser. But I guess, you know, the new ones probably have a lot of memory. So that might not be such an issue either. 

ERIC_SIMONS: Yeah, we'll see. And we're still, it's hard to, hard to test it just cause they haven't shipped the stuff yet, but yeah, I think it seems it looks positive at least from the testing that we've been able to do. 

CHARLES MAX_WOOD: So Dan stopped bursting my bubble. Eric said someday. And so someday somehow on my iPad. All right. The other question I was just wondering about and I guess it kind of depends is headless browsers. But I guess if the headless browser will run VA with WASM and WASM threads and all the stuff we're talking about, it'll work fine. Right?

ERIC_SIMONS: Yeah, absolutely. Like, I mean, I, and you could even do it today with our stuff, right? Like I think it's because the stuff all, you know, it just, it runs on any browser engine essentially, rather than that has the spec-compliant at least, which before it takes a while to get there. But yeah, absolutely. 

STEVE_EDWARDS: I guess you can say it's not true that it's all in your head, Hunter. 

CHARLES MAX_WOOD: It's always all in my head, man. All right. Any other questions? Anything else we want to dive into here? 

DAN_SHAPPIR: I'm still processing. 

CHARLES MAX_WOOD: I have to say, I know I'm, I'm going to go to bed tonight and I'm going to be like, I should have asked this. 

ERIC_SIMONS: So totally. I mean, we have a blog post that we put together on this too. If you like, I think it's over at like blog.stacklives.com. Yeah. That kind of goes into some of the more details, like some stuff that I think Dan, you mentioned about like the debugging and whatnot. It's pretty crazy. Like be able to use Chrome dev tools to debug node JS code. It's pretty wild, but yeah. So maybe it was interesting. They can check that out. 

CHARLES MAX_WOOD: Yeah. I've been looking at it and it's been, it's been fun to nerd out on this stuff. 

ERIC_SIMONS: Totally. 

CHARLES MAX_WOOD: All right. Well, let's go ahead and do some picks.

 

Did you work your tail off to get that senior developer gig just to realize that senior dev doesn't actually mean dream job? I've been there too. My first senior developer job was at a place where all of our triumphs were the bosses and all the failures were ours. The second one was a great place to continue to learn and grow only for it to go under due to poor management. And now I get job offers from great places to work all the time. Not only that, but the last job interview I actually sat in was a discussion about how much my podcast had helped the people interviewing me. If you're looking for a way to get into your dream job, then join our Dev Heroes Accelerator. Not only will we help you get the kind of exposure that makes you attractive to your dream employer, but you'll be able to ask them for top dollar as well. Check it out at devheroesaccelerator.com. 

 

CHARLES MAX_WOOD: Steve, why don't you start us out this week? 

STEVE_EDWARDS: Okay, continuing with my story of history of dad jokes related to work history. 

CHARLES MAX_WOOD: Practicing my laugh. 

STEVE_EDWARDS: Yeah, Dan's been practicing his groan, so I told you before, I think we need to get a sound effect that you just hit the button. So one of my jobs that I had before is I got a job as a bullet, but I was fired immediately. Oh gosh, I just lost my second one here. Oh yeah, that's right. I had, and when I was back in college, I think I had a job as a scuba diving instructor, but I quit it after my first lesson because I figured deep down, I realized it wasn't for me. So there's my contributions for the day. 

AJ_O’NEAL: Thank you, Steve. Let's have a moment of reference. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_O’NEAL: All right, so I already picked a bunch of things in the episode, so I'm just gonna recap what those were. So there's a, and I picked this one recently anyway, but there's the Utah Rust November 2020 meetup that was on Wasm and Rust and the state of Async Await. And if you're interested in building stuff for V8 and Wasm, that is an episode to watch. Basically, anything you're gonna do with Wasm, you're gonna wanna no rust because I think that's what everybody's doing because it's the language that's the really the best tool for the job. Then I yeah, I mentioned, oh no, I didn't mention but I looked this up. I put it in the show notes. The solar winds attack a masterclass and novel hacking techniques. Interesting article from NPR. That's my title for it. That's not what it's actually called, but that was like the clickbait that they should have used except it wouldn't be click bite because that's what it's about. But because we mentioned the solar winds attack, I wanted to throw that in there. And then there are, I thought there was one other thing I put in there, but there's, there's a couple of things that I found out about this week or improved on this week that I think are worth mentioning. One, the buzzword that I've been looking for, for CSS that quote-unquote, just works TM is called classless CSS. Classless CSS is where if you just have an HTML page, like a blog article, something that you would use like a blog or like a very simple type of page that doesn't require any appiness to it, mark down blogs, HTML blogs, etc. Classless CSS is the search term for being able to find CSS that just works without a bunch of newly fangled news. And, 

DAN_SHAPPIR: or you could use a tailwind and then everything 

CHARLES MAX_WOOD: I was going to say, I thought it was, 

AJ_O’NEAL: but then I'd have no, no, no, no, no, no, no, no, no. No, I don't, I don't like CSS. I don't want to build the CSS. I want to find CSS that is down to my level of stupidity and classless CSS is it to the T. So I got a link to one of the GitHub projects that list a bunch of the classless CSS. They're not framework, but I don't know what to call it, styles, style sheets, single page style sheets, or site style sheets. And the one that was really cool was something with an S down at the bottom that I might start using. I don't remember it off the top of my head right now. Also, if you, and this is something we should talk about at greater length at some point, but we've got Express. Everybody uses Express, right? I think even with Koa and with that other one that I don't remember the name of right now, and then Happy, we've got like three or four different web frameworks, but pretty much everybody's using Express, right? Am I right on that? Nobody knows? 

DAN_SHAPPIR: I'm- You know, occasionally. I try not to make a habit of it, I have to tell you. 

AJ_O’NEAL: Well, what are you using then? 

DAN_SHAPPIR: I'm using Wix. 

AJ_O’NEAL: No, I mean, when you're doing node development, duh. That's cheating. Talking about the node development.

DAN_SHAPPIR: Uh, yeah, I guess. Yeah. 

AJ_O’NEAL: Well, anyway, there, I, the, the modules that are out there to add promise and async support are ludicrous. And I finally found one that turned out to be insanely tiny and is, is what I would have done if I had known exactly how to do it or spend the time on it. It was called express promise of fire router, but it had a bug where, and this is project is years old and it had like one star when I came across it, but it's perfect. It's a drop in replacement for the express router that does almost everything you need. I just made one change to it and republished it as at root slash async router, which is that now it supports error handling functions properly because error handling functions have a different signature than handler and middleware functions. But this simplifies express development, the modern express development so much because you don't have to have all of these dot catches or try catches. You don't have to have the promise chain of hell or the try catch pyramid of doom. You can just use the old school express error handling, but basically upgraded. And then all your routes become a lot simpler. This is just a better way to do it. So I got a link for that. And then lastly, about a year ago. 

DAN_SHAPPIR: Just to say, or just bite the bullet and go with Dino. 

AJ_O’NEAL: Sure, sure. I mean, I'm not gonna argue against that. It's just a lot of us, when we need to throw something up real quick. We're using Express. I think that's still the most popular framework. It hasn't had a push in two years, which is fine. It's a complete project. Version five never came out and probably never will come out even though it was halfway done. I think no, it was halfway done like two years ago and whatever doesn't matter. But the other thing is, a while back, I like a year ago, I talked about how I figured out how to do time zones using the for a project that now has been updated and redirects to this project. But then I didn't actually go and finish that project and it turned out there were other problems that I encountered, but I finally just gritted, hunkered down and put the grit of teeth or whatever the idiom is into it. And I created xtz.js, which is about 150 lines of code. If you subtract the comments, maybe a little less, maybe a little more, but about that, that just does because INTL is so stupid. Ugh! Why did, when people standardize things and then you can't use, uh, anyway, just puts some wrapper that shouldn't have to be there around INTL date, time format, so that you can actually get back a date object in the time zone rather than a string that you can't guarantee will be parsable on any other system because of the way that, format or, anyway, so I got that. And then of course, you know, if you want to follow me beyond code for, uh, tech learning stuff, I got the links there for that. So sorry, that's long winded, but these are good things. It's worth it. 

CHARLES MAX_WOOD: All right, Amy, what are your picks? 

AIMEE_KNIGHT: Okay. Sorry. It's pretty quiet again today, but I'm going to go with, since we're talking about last of a bunch today, something I saw last week that I started and you can now run Jupyter notebooks in the browser, which Jupyter notebook is typically a way that. Python developers run a lot of their code. So it's something that I started kind of wanted to look into. So that'd be my pick. 

CHARLES MAX_WOOD: Yeah. On the adventures, the machine learning, a lot of the folks talk a lot about Jupiter notebooks for their insights. 

AIMEE_KNIGHT: Yeah. So I thought it was pretty cool. You can do these in the browser now. 

CHARLES MAX_WOOD: That is very cool. I will have to check that out as well. Who haven't we hit? Dan, have you done your picks yet? 

DAN_SHAPPIR: Yeah. So I've got two. 

CHARLES MAX_WOOD: I got lost in AJ's rant. I can't remember.

DAN_SHAPPIR: It's okay. We all get lost in AJ's rants. Anyway, so, uh, I've got two picks. So first of all, let's start with the fact that I, as I said, at the beginning of the show, I live in Tel Aviv and you know, we've had some interesting times here as if Corona wasn't enough. If you're, if you're interested in kind of what happened between, uh, Israel and Hamas and Gaza and this latest round and you want a pretty good overview, but fairly short. So there's this excellent, well, I have to say it's really good podcast episode by the New York times, they're the daily podcast. So it's titled why Hamas keeps fighting and losing. And I'll, I'll, I'll publish a link to that. I, I'm Israeli, so I can't claim objectivity, but I actually thought that this episode was, was fairly balanced and positioned in a way that I think both sides would not object too much because you can't please everybody certainly in this conflict. And on a lighter note, so I've watched the first episode of Jupiter's Legacy. It's interesting that so many superhero shows are coming out that are taking this sort of a dark twist. So there was the Boys and the Umbrella Academy, and now we have Jupiter's Legacy. I think that of the three it's like I would rank this as number three. I think that I found, I think the boys was the best from my perspective. The, the umbrella Academy came in second, although I know that some people put it in the reverse order. And I think that this would, this would be the third, but I still found it to be quite enjoyable. So I can recommend that this as well. It takes an interesting look at this whole thing about superheroes not wanting to kill anybody and how that kind of limits their ability to safeguard the world and actually even safeguard themselves against their enemies, the supervillains. So it was pretty interesting and I enjoyed watching it. So that would be my second pick. And those are my picks. 

CHARLES MAX_WOOD: Awesome. I'm going to throw a few of them out there. I'll try and be fast. So the first pick I have, I'm just going to follow on to the SolarWinds pick that AJ threw out there. Jeffrey Groman and I actually had a discussion. He's a cyber security expert, one of our hosts on adventures in DevOps. We had a breakdown of the solar winds attack and he explained it all very clearly, uh, cause I didn't have any idea what was going on with that. And, uh, he made it very understandable. So I put a link to that in the picks as well. The other pick that I have. So yesterday was Memorial day as we're recording this. Um, I know we're several weeks out this will probably come out around the 4th of July. But growing up, we always went out to the cemeteries and visited all of the grave sites of my dad's family. Mostly my mom's family is also her, her parents now, but her grandmother was, is buried up in Provo, Utah. And so we always went up there and then we always went out and saw my dad's family. And so we spent a bit of time together as a family. And then my mom took us around cause my dad's not with us anymore. And amazingly, she remembered where all these family members were buried. And it was just really great to connect with the past. And so I just want to kind of shout out about that. And I guess just encourage people to connect with your past, to figure out where you came from. I was talking to somebody earlier today and one of my coworkers. And it's really interesting because on my mom's side, you go back three generations and you're in Europe, right? My, either in France or England. And on my dad's side, as you go back, it's kind of this progression of settling the West and then American history, right? I mean, all the way back, I have ancestors that came across on the Mayflower. So it's just, it's really interesting travel through American history. I have ancestors that fought on both sides of the civil war. I have ancestors that didn't fight in the civil war because they were Mormon pioneers and left before the war broke out. And so anyway, it's just this really interesting thing. So I encourage you to take some time in there. Terrific resources on ancestry.com, familysearch.org, and a lot of other places where you can find out about your ancestry. So I encourage you to go check those out. I'll put links to all that in the show notes. But yeah, and then for the Fourth of July, again, there are just some really, really terrific places to go learn about where we come from as a country, what some of the motivations were founding the country. And I encourage you to go and look at some of that why some of the decisions were made in putting together the constitution, why they were looking at breaking away from Great Britain. You know, you hear a lot of things, but what can actually be substantiated? You know, what were these men actually writing about when they tried to break away from Great Britain? There are a lot of things that are said that can't be substantiated, and there are a lot of things out there that can be. And so what was actually written by these people? And what were they actually fighting for? But yeah, there are a lot of opportunities that are offered by us living in a country like the United States. There's a lot of rich heritage in a lot of countries, including ours, including others. So learn about where you come from, not just in your ancestry, but in the country that you live in. And yeah, so I'm going to shout out about all of that and go check out devinfluencers.com and those are my picks. Eric, do you have some things you want to shout out about?

ERIC_SIMONS: Good question. I think the one thing I'm pretty excited for is Next.js comp, which I think is happening in like a week or two, maybe two weeks, something like that. But I mean, they've been doing a pretty, pretty amazing job across the board. I mean, I guess for cell just in general, but I think that they've, uh, I think they're going to announce something that, that's going to be pretty, pretty big for the, at least, you know, certainly for like the react ecosystem, I think, cause I mean, it's an interesting point in time. I guess it for where we're at. Yeah. I think next chance is pretty quickly becoming the default thing that people reach for when they want to start a new react app. And I think I'm excited to see what they would, they roll out there. It's they're doing some pretty cool stuff. So I'd say, you know, and the conference site they made for is really cool. Like it's like this like real time multiplayer thing. So, uh, it's like just maybe next JS conf.org or, you know, I don't know what the URL is for, but yeah, nextjs.org slash comp. But yeah, it's pretty cool. So I'm, I'm, I'm attending. Seems like pretty legit. I highly recommend everyone else do it too. 

CHARLES MAX_WOOD: Cool. And if people want to connect with you, how do they find you online? 

ERIC_SIMONS: Yeah, I'm on Twitter. My handle's ericsimons40. That's probably the main place on Twitter. And then our StackBlitz account is just at StackBlitz on Twitter. And you can check it out over at StackBlitz.com. Do it in one click and don't blink because it'll boot in like milliseconds. You can do it all yourself. 

CHARLES MAX_WOOD: Good deal. All right, well, thanks for coming, Eric. This was cool. 

ERIC_SIMONS: Yeah, thanks for having me. This is awesome. Great questions.

DAN_SHAPPIR: Yeah, it was, it was really excellent. Thank you for sharing all this information with us. And I'm playing around with it. I'm sure I'll play with it a lot more. It's just so cool. 

ERIC_SIMONS: Awesome. Yeah. We'd love to hear your feedback too. 

DAN_SHAPPIR: We'll do. 

CHARLES MAX_WOOD: Absolutely. All right, folks, we'll wrap up here and it's the next time Max out. 

STEVE_EDWARDS: Adios. 

DAN_SHAPPIR: Bye. 

AJ_O’NEAL: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.