Noel: Hello, and welcome to PodRocket. I'm Noel. I'm an engineer at LogRocket, and today I am joined by Tomek Sulkowski. I said I would do as best as I could. That's what I have got. How's it going Tomek? Tomek Sulkowski: That's perfect. Hi, Noel. Yeah, I'm so happy to be here. I'm great, and I'm ready to talk with you. Noel: Awesome. Awesome. So Tomek is a founding engineer and dev relations at StackBlitz. So we will get into what that is and what that works, where that fits into the developer space. But I think before we dig in there, can we start by talking about WebContainers and what those are and why you guys are working on them? Tomek Sulkowski: Sure. Yeah. So WebContainers is a name we've come up to describe what you can... Probably the shortest way to describe it is open OS in a browser. So basically for example, if you have a Node.js application, typical backend stuff, you need to run it locally on your computer. And that's because the whole idea behind Node was that it can communicate with your OS, use the file system, open ports, things like that. So we've created our own very lightweight operating system so we can run all this stuff, file systems and things like that in the browser. And that's WebContainers. Noel: Nice. Awesome. Awesome. So how does that fit into StackBlitz? Why do you guys care about that? Tomek Sulkowski: Sure. So StackBlitz, initially it was created by Eric Simons and Albert Pai. Two all time friends who had a company that was doing Angular workshops, Angular was the super hot thing back then. And they realized what probably every other workshop trainers realizes is that setting up machines, setting up the projects themselves, take just painfully a long time for any workshop, whatever you teach in the developer space. So they've created StackBlitz to have that instant environment to run Angular apps. At first, that was basically Angular, JavaScript, things like that. Then we grew the capabilities to run other frontend libraries and frameworks. But JavaScript is not only about frontends these days, there's a lot of cool, interesting stuff in the backend too. So we needed a way to run backend stuff in StackBlitz, so hence WebContainers. Noel: Nice. Perfect. Cool. Yeah. So yeah, I want to dig further into WebContainers and StackBlitz and how all that's working. But to help lay the ground here, how did you find yourself working at StackBlitz? What was your background before you were here? Tomek Sulkowski: Actually, I was also running workshops for a long time and that's also... At this point we have probably seven or eight people in StackBlitz that are still running or used to be IT trainers of sorts, so this is very much a DNA of StackBlitz. So as I was running them and talking with a lot of experienced and beginner developers, I realized that there are a lot of things that are just outside of the reach of someone's experience or someone's knowledge. So a lot of very cool stuff in that broad space that a lot of people don't know about, even though it's relatively easy. Of course, easy is a subjective term, but reachable. So I started doing these tapes on Twitter that these days it's very popular way of gaining momentum, but I started doing them a lot and just teaching and out there. And once I decided to switch my career back to working on developer tuning and things like that, we found ourselves with StackBlitz. I was already also using StackBlitz at this point because of the teaching, so yeah, match made in heaven, really. Noel: Nice. I wasn't aware that there was so much of an education centric background too, with the founders and then with the platform as well, which I guess, it makes sense to me now, now that I'm hearing it. But how does that kind of background influence what you guys are working on and how you try to direct the product? Tomek Sulkowski: Yeah, good question. It's an interesting, because it very naturally and consistently evolved into other spaces because you can define education in very broad terms. Initial image you have in your mind is school, is workshops, boot camps, things like that, so that was our first focus. But then documentation, that's also education, right? So for a long time, we focused on making this as flexible and as universal tool for teaching and documenting JavaScript stuff as possible. So that was the second step. And once WebContainers became stable and we realized that we can run actual real life tooling, and then now we are working towards more real life scenarios, too. Noel: Nice. Like I said, what do you mean by WebContainer stability? What do you guys feel is the acceptable bar where it's safe for devs to start relying on and exploring building in this way? Tomek Sulkowski: Yeah, that's a great question because it's not a Zero One answer or status, so to speak. So deciding that WebContainers is a stable was a judgment call. First when we released them in May last year, we had a launch partner with Versal and by supporting Next.js, and I think that was the first one and we had couple more frameworks in the next couple of weeks. We started gradually adding them as we were testing them with the phemo creation, with the creators with the community. And at some point we realized that we support even more than we know. So people are actually coming to us and actually, "Can you add this starter for my library? Because it's working, we are actually using it for reproduction." Something like that. So once this become quite uniformly, supporting everything, we decide, "Okay, we can take off the beta label." And that's works fine. Noel: Nice. So yeah, while we're on the topic and digging into WebContainers a little more, can you explain in a bit more depth how that's actually working? How are we running Node apps in the browser? If I open up the StackBlitz editor and I have a new project, how is that backend actually running in my browser? Tomek Sulkowski: So basically if you think about Node, it's taking the browser engine, the car, and running it against the OS. So we needed to build this basic building blocks of an OS. So things like file system. We have our own file system written rust. We have our own networking layer that is working all within a browser. So to be honest to me and to many of our more frontend engineers, this is a black magic because our core tech has been working on this for pretty much, almost two years before we released it. At this point, it's more than three years. So they figured out very cool ways of solving very tricky problems, including things like... So for example, parts of the Node ecosystems are binaries that you need to compile against your architecture like your OS, and that will not run directly as is in the browser. So thankfully a lot of these kind of tools that provide these binaries also have now the Watson version that is compatible with the browser. So actually one of our engineers, Damico added that contribution to Node where you can opt into using that alternative version of a dependency if it runs, if it's possible. So besides just trying to solve these problems that are just technically difficult, we also needed to work with the community, in this instance with Node ecosystem to make this possible. Noel: Enjoying the podcast? Consider hitting that follow button for even more great episodes. Yeah, you spoke to more frontend centric devs. Let's say you're a dev and you're only really doing frontend development work right now, you're not typically running a local Node backend server. Are there still benefits to switching to something like StackBlitz? Tomek Sulkowski: I would say the first era of StackBlitz so to speak, was geared toward making the frontend as developer friendly as possible. So introducing WebContainers only made this more powerful, really, because as any frontend developer, you need to run a Node tooling. So for example, you can just as well as you do locally, you can use Netlify CLI to deploy your stuff from your browser in this case, to Netlify or use any other common line tools. Yeah, definitely. And why would you use that instead of local as frontend developer? One, that depends on who you are as a developer. What is your focus? But for me, for example, I do a lot of demos and in StackBlitz, I have... Let me check. So I'm exact, but I have 2002 projects. Multiply it by the average Node module size, and you might need some additional drives. That's the first thing. The second big thing is the security aspect. And if you just look for NPM security, that is like a Pandora's box waiting to be open because you run it against URLs. And even in VS code, when you open a new folder, VS code asks you, can we trust this thing? And you need to add- Noel: Pretty recently, right? That's last few versions that check has been introduced. Yeah. Tomek Sulkowski: Yes, exactly. And I must say, this gives me... Not sure if I can actually ask this thing that I'm running. I'm not checking all this NPR. So in StackBlitz, you run it all in the security of browser sandbox, so you're safe. So that's the security aspect. And third, it's similar to that content creator. Even if you're not content creator, sometimes you just need quickly to test out something. And instead of creating a new folders and PM in needs stuff, you can just go to Vit.new/react or whatever else and you have the running app, simple baseline app in literally two seconds. A lot of open source also uses for reproductions. So if you as a consumer of a library, you spot a bug, your StackBlitz tool make a reproduction and send it to the maintainers. And issues that are way more likely to be solved, to the point where in some projects, maintainers just don't accept issues without reproduction. Noel: Yeah. No, that makes sense to me. While we're on the topic of issue reproduction like that, how does that experience work? Say you're a maintainer on a project and you're trying to direct people as to how you want reproduction zone. How does StackBlitz compare to something like the CodePens or code spaces of old? The other online frontend code environments? Tomek Sulkowski: Yeah, so that's interesting. There is a lot of variety and in both the functionalities and how the computer model works, and this may seem like an implementation detail, but it's also crucial for the user. So things like CodePen, for example, or JSFiddle, they're more geared towards making these demos where you have several files and just focus on that. So it's wouldn't really be a copy of what you're experiencing on your main project, on your actual project. So I think they're definitely useful, especially with the... I know that with CSS [inaudible 00:16:25] so to speak, CodePen is very highly regarded because they have really nice previews for it, but it's for visual demos. And if you want to reproduce CSS stuff, definitely, I think it's not a bad choice. As for other StackBlitz looking things so to speak, where you have the whole file tree and even maybe terminal, the difference between StackBlitz and exactly any other solution is that we run all this stuff on the frontend. So your project uses your browser's computing power to run everything. We just pretty much store the text files, including containing the code. So what it means for us is that we don't pay for running your project. In other playgrounds like this, or online code editors, they run on remote visual machines, and that means that it costs. So at some point, this cost needs to be paid by someone. So you either get a low free tier, or you have to pay for seconds of compute power. Noel: Yeah. That makes sense to me. So, yeah, let's talk about that juxtaposition in a little bit more detail of these container VM based cloud development environments versus a local but browser based development. So I feel like the obvious comparison would be something like Codespaces. I think that's the GitHub one, that's what it's called, Codespaces. So in that world, you're running VS code locally still, or in the browser, but either way, however you want to do it. And then all your execution is then happening in a VM or in a container that's managed another infrastructure. And I feel like a lot of the promise there was in you don't have to deal with interoperability stuff like weird machine nuances, things like that, or performance bottlenecks on the local machine. You can have this whole big thing. Are there certain projects then that are better suited towards local or remote development on a container versus projects that are well suited to StackBlitz running locally on your machine? Tomek Sulkowski: I think it might come down to capabilities because with the remote machine, you're getting pretty much a Linux deal. And I think you can run all the stuff, all the languages that you can run on Linux. So basically everything, while WebContainers only support for now only... Well, that's not actually true as of last month, but by design it supports Node ecosystem. So that's point towards remote Vms. I'm just joking about not only supporting Node ecosystem because Astro, folks manage to run PHP and Astro in StackBlitz. So you actually can run now a PHP using JavaScript in the browser on the frontend sides, which breaks my mind. But the big I think, difference on our side besides the cost and actually also performance, is that we can run if you have network issues. So we can actually run offline. That's why I tend not to use the online IDE name for first StackBlitz, but more like a browser ID. It works in browser, but it doesn't have to be online. Emily: It's Emily again, producer for Podrocket. And I want to talk to you. Yeah you, the person who's listening but won't stop talking about your new favorite frontend framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you are really important to us as a listener. So what do you think of Podrocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi's out? I don't know, and that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us. Links are in the description. $25 gift card. Noel: Yeah. There's some interesting challenges there probably in naming and what we mean when we say certain things, because you're like browser IDE I think does imply remote development right now for better or worse. So I feel like that is a hard thing. Because I imagine most devs coming into this that are not aware of the StackBlitz model, that's always the assumption, right? It's like any code editing I'm doing in the browser is always running externally. How do you guys dispel that? What's the easiest way to explain this especially to someone new? Again, they're trying to come into web dev, they're trying to figure out a million things. How do you also explain to them? "Okay, but you should use an IDE that's in the browser, but technically running locally because then you get all of these benefits?" Tomek Sulkowski: Honestly, we don't. Especially if you're very new, it's all so confusing. And I've been in this space for almost 20 years, but I've been talking with people that are new all the time. So hopefully I'm not losing that perspective. But with all the server sites rendered or generated, or is it single page app? Why is it single page? Even these concepts are actually usually flying above your head and you get a grasp of it in a while. So if you add the craziness, to be honest, what we do in StackBlitz, it's probably counterproductive. So what we focus on is speed, basically. So with using StackBlitz, you have zero latency because even if you run your code locally, it's still going through your actual TCP network tag. Noel: Oh, local host locally, right? Yeah. Yeah. Tomek Sulkowski: Yeah. Yeah. And here we have this virtualized, so it's actually even faster than local. To me, that was always the most enticing thing about frontend in general. The speed that you have, the fast feedback loop. So to us it's all about speed and security. Once you know more or less what's happening, what's going on as a beginner, you start to ask these questions and we already have the answer that this is more secure. In practice, there is also one important difference, is that oftentimes things just hang, right? And there's not much you can do about it. If this is a remote VM, if you reconnect to it, you are reconnecting to a hang VM. In our case, you just refresh the page and everything just starts anew, including even in starting NPM dependencies. So you'll get super fresh environment on each page reload. Noel: Got it. So let's say I'm just... I haven't used StackBlitz a ton and I'm sure there's a large subset of listeners who haven't either. So say I'm doing local dev with StackBlitz and I've got my web app open, do I still get those benefits of the browser? Not needing to go to the local host network interface to do communication if I'm developing into separate windows? For instance, the question I'm getting at is can I refresh my app that I am developing without refreshing the environment that is running it? Tomek Sulkowski: Yeah, definitely. You can actually run it in a separate window. In several windows, in fact. So you can do your own responsive layout setup when you have several windows and they all automatically update. You can definitely even opens different pages. Whatever you do on local, you can do it here as well. Noel: Gotcha. Gotcha. Okay. Yeah, that makes sense to me. And I think I could totally understand the difference in responsiveness, especially when developing against an external machine or whatever, a VM in the cloud. Does that speed increase? You said it's even faster than going over local hosts through the actual network interface. That speeding increase, is that tangible for most people? Because I feel like locally, my requests are still instantaneously fast still. Are there cases where it's oh, that is measurably, performantly different? Tomek Sulkowski: Yes. So there is an interesting angle to it because if I... Just honest question, how do you feel when comparing a web app to the same desktop app? Which is faster? Noel: I've used web apps I would say historically, that have felt as responsive as desktop apps. Not all, but I think some more focused less bloated ones do, but a lot not... I would say that's not the norm. There's usually web overhead. Yeah. Tomek Sulkowski: Yeah, exactly. So that's the intuitive answer I think, or a feeling that a lot of us have. And thankfully, as you say, a lot of these tools or the frameworks I mean, are focusing on performance as the first priority and that's great, but that's one aspect of using StackBlitz that we were surprised ourselves because some of our users that use very low powered machines were reporting to us that they are using StackBlitz because it's faster than their local setup. And here's why, because your typical local setup as a frontend or JavaScript backend developer consists of VS code probably, some Node running at least a dev server spinning up different processes and browser, right? And each of these have their own V8 engine running. So VS code is of course using electron, so it's running within its own browser. Node again, and browser again. So instead StackBlitz runs in the browser, so it uses the same browser engine, the same instance. Instead it uses a thing that's called V8 isolates, that makes dividing the tasks very, very fast and safe and secure. So it is actually noticeable. Even without measuring, it's noticeable with a naked eye on lower powered machines. But also if we measure it, we actually have noticed differences, even in things like NPM installs, our engineers are doing a really groundbreaking work with how to speed up installing things. So if you install NPM install locally and StackBlitz is often oftentimes faster, especially once it's cached by browser, then it's instant. Noel: Yeah, I was actually... My next question was what is cached? If I refresh my IDE page with StackBlitz, what is cache? What needs to be rebuilt when the page finishes loading? Tomek Sulkowski: Just the external resources are cached. But the most important part is the MPM dependencies where as you know, it's usually megs of code. So this part is cached, but besides that your app is rebuilt from scratch. So when you refresh StackBlitz project that is WebContainer based, you'll see NPM installs and it will be just 24 times faster and then running NPM start. And that takes the same amount of time that it would on the first start. Noel: Gotcha. Gotcha. Is that the same... Say there's some issue with a Node modules folder... I'm thinking of cases that typically in local driver, I've got to blow away the Node modules folder and rebuild. Is that ever an issue in StackBlitz? Do I have to tell it to clear its cache or is that not a problem that arises? Tomek Sulkowski: We haven't noticed that, but that's basically... I think in our introductory post for WebContainers was that this is instead of RF Node modules, you just do a page refresh and that does the deal. Noel: Gotcha. Gotcha. So is the caching then of the Node modules folder and its structure or is it the resources that go into building the end state modules folder that ends up getting used? Tomek Sulkowski: No. If I remember correctly, it's the resolved resources. Noel: Nice. Yeah, that makes sense to me. Yeah. So you touched briefly on teams using this in production and just users in general. For devs out there who are on a team that maybe isn't using something like this now, they're just in a more traditional environment, is it possible for... If you bring your own IDE, say you're in an org where there's no opinions on that, is it possible to use StackBlitz with a typical Node project that may not have been designed with StackBlitz in mind around it? Tomek Sulkowski: To be honest, it's a golden path thing, so you might be able to do it. For now we are focusing more on teams that work on design systems. For example, eight our enterprise clients use StackBlitz for maintaining their design systems for libraries. But if you have more typical crude database connecting app, that's not yet our guarantee, so to speak. We are working on making that happen... I internally think about it as third age of StackBlitz and that should... Yeah, I will want to talk a bit more about upcoming ViteConf path. We will be announcing some interesting stuff around that in two months, actually. Noel: Oh, nice. Nice. Yeah, we'll wrap our conversation with upcoming and future stuff. So let's say though that you have a GraphQL API, that's serving all of the data, but say you've still got a backend server that's a rails app or Django app or something, right? But you've got the GraphQL API, that's an intermediary layer that's actually serving all the requests that the browser is consuming. Is it possible then, or is it feasible, or have you maybe seen people doing it where they still run that old service, spin up the GraphQL API in the StackBlitz and then have their frontend dev work still happening in that manner? Or is that not really very easy right now? Tomek Sulkowski: At this point, it's not possible because how WebContainers work, it's not yet possible to connect to the browser from the outside world, so to speak. Yeah. Noel: Yeah. So is the hard membrane there, data support at all? Or is there any way... Does the whole app need to be contained in that backend piece for this to work or is there any hybrid system that one can get running? Tomek Sulkowski: That's the idea. I think you can connect to... If you have your developer and database, if you're using Firebase, which a lot of developers use and things like that, that's totally doable, we have been doing a lot of demos like that and we have people using it like this. But besides that, it's best if it's contained within WebContainer. You can actually use a slite in WebContainer, we do support it because it comes with Watson version. So yeah, that is doable. Noel: Nice. Yeah. To take a step back, I do think the security argument is a very compelling one and all the benefits of local development, but without being able to lean on the membrane of the browser to keep you isolated. That to me, seems super beneficial to your point of as increasing number of vulnerabilities are introduced through known modules and everyone has these fears and the native IDEs are coming up with warnings every time you open a new project now. Tomek Sulkowski: And if you think about it, if you zoom even more out, it's ironic that we as web developers can't use web browsers to build web stuff. As we are talking me and right now, we are using a web app to do it, we didn't have to install a thing. And now people use Figma to design stuff. People use various stuff to produce music. Of course, you have Google suites to do your taxes or your- Noel: All of the business, everything, any normal business operations [inaudible 00:37:03] Tomek Sulkowski: And it seems like it's only us left on the field, which as developers, we can't use a browser. So it's definitely something that needs to... It's due to happen. And yeah, we hope that... It is actually already happening on some levels, especially if you are an open source maintainer, you can certainly use StackBlitz for not only reproducing stuff, but also doing PRs from it and want to make it way, way more feasible first, before we jump into this, your typical crowd app. Noel: Yeah. On that note, how do you guys test? What's that process look like when you push a change to have something works in either the WebContainers flow or in the editor itself? How's that testing process look? Tomek Sulkowski: It's a podcast so people won't see my face, but we've been talking today hours and this week, several hours about that. We have especially around web container because it's tricky to notice, we have series of tests, but we probably will soon transition into something that... And you can look it up how Vid team is doing it. It's a very clever setup, when they are running Vid against various frameworks that are some of their built in. Some of them are external, so you can actually... This is whole community's effort and we are working very closely to both help them, but also use some of their best practices to help us, because this is basically the very similar use case. We don't want to push anything to a WebContainer that breaks let's say, it's felt GIT or something. Right? Noel: Right. Totally. We had Patta Matias on... I was talking to him two weeks... Not two weeks. A couple months ago. Yeah. Listeners, go back and find that episode if you want more, because we talk about it at length and it does sound like a very cool testing system. Yeah, we'll try to get a link to that episode in the show notes too so people can find it easily. On that note, what's upcoming? What do you want to steer listeners to? What's on the roadmap? What should people check out? Tomek Sulkowski: So what is on the roadmap? We are working on something really big that is on the scale of introducing WebContainers, pretty much. And so I can't tell much about all of the pieces, but what I can say specifically is that one of the things that we are working on is better GIT implementation. Basically right now, when you use StackBlitz you can create a new repository from your StackBlitz project. You can push to it, you can change branches, so you can put it the changes down. So it's cool because you are not tied to StackBlitz, you can keep pushing stuff to your projects from local or however you feel like. But that GIT implementation is very minimal. It's basically what I just said, that's it. That's not the whole GIT, right? So we are working on pretty much full-fledged GIT implementation, which on its own gives you way more real life production ready workflows. Besides that, we are working on... We've had a lot of people asking us about supporting extension for the editor and I've seen many extensions this week, it's all I can say, working in browser. Yes, and we actually have... So I can't be much more specific about that, but I can be specific about the date because we have a deadline for it. We will be announcing it on ViteConf. Yes, so it is something that we organize with the Vit team and it happens on October 11th and 12th. Noel: Gotcha. Nice, nice. Looming deadlines are always a little bit anxiety inducing, but motivating often. Yeah. Tomek Sulkowski: So open- Noel: Cool. Anything else you want to plug? Anything else you want to send listeners to? Tomek Sulkowski: Take a look at our documentation, especially the part about SDK. Some people that we've talked to are using SDK in very novel, interesting ways, doing different types of tutorial. Especially you can look at the news feltkit tutorial, it uses web container API. So this basically gives you an... It is like a library for having an OS in your browser. So imagine all the possibilities that your web app can do having that resource, right? So SDK, especially if you are documentation maintainer for your project, take a look at our docs and you can either create projects on the fly, or you can import some examples from a GitHub repository. So lot of people have the examples further in their GitHub and there's bunch of examples. So you can use that and yeah, I think that's it, besides that you can always talk to me. I'm sulco, S-U-L-C-O on Twitter and ask, complaints, suggest everything about StackBlitz. I'm happy to talk. Noel: Awesome. Yeah. Again, we'll be sure to give links to everything we could find in the show. It's probably Vidcon, Twitter handle, all that stuff. Cool. Well, thank you so much for coming on and talking with me, Tomek. It's been a pleasure letting me dig in a little bit. Yeah. Thanks so much. Tomek Sulkowski: Likewise. I'm always happy to talk to another enthusiastic developer. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome Podrocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.