And so these web containers, I think, are what are enabling this project tutorial kit. Is this on top of web containers? At least part of it is, right? Yes,

exactly. It kind of consists of two very cool technologies. We can dive into it in a second. But I think also interesting thing is how we got there. Because basically, a piece of web containers development was dictated by tutorials about two years ago, I think, or even longer. But let's start from the beginning. So you might have seen, even if you're not into Svelte, you might have seen a Svelte tutorial. It was basically the primary way for people to learn Svelte since its inception in like over five years ago. That was created, primarily by Rich Harris, who is a great communicator and educator. So he built that, I think, inspired by Knockout. Knockout JS, yeah.

I know Knockout.

Yeah, me too. That was so cool to remember these things. But anyways, so he built this amazing tutorial. And if you look at any of his talks, actually the YouTube recordings, like any demos, he's using that tutorial himself as a starting point even to demo specific parts of the framework. So it's not only for beginners and people who are just onboarding into the technology, but it's also for an advocate himself. So it's a very, very cool concept, cool tool. But now, if you know anything about Svelte, the most common way of using Svelte is by using SvelteKit right now, right? And SvelteKit has a very significant back end player. So now we're kind of coming back around to web containers, because it was kind of impossible to build a new tutorial for SvelteKit without having the node aspect. So reach Harris, reach out to us and ask if there is some way of using web containers outside of stackpits.com. Okay. Yeah. So basically, that was our design partner for creating Web Container's API. And now, so you can use this technology, this engine, on your website, building whatever you want to build, if you imagine if you had an OS on your website. So people started building very interesting projects on top of it, like their own code editors and playgrounds. And there is a project that provides you with details on any package, something like bundlephobia, but it's using web containers to actually download the package in the browser and provide you with the proper information about the structure and what it downloaded. So the direct inspiration for Web Continuous API were the tutorials built by Eric Harris, but then it became a very universal tool. And since Svelte Kit tutorial was such a big success, people from other teams, from other frameworks, were also inspired by it. And there is now, I think, since beginning of this year, there is an Angular, interactive Angular tutorial. If you go to angular.dev, they have a cool new documentation and an interactive tutorial that looks very similar in structure and functionality to SvelteKit and There's also a very cool tutorial in progress built by Antoni Fu from the Naxx team You can see that in His stream that I think there was like 10 video series you can find it on YouTube, where he actually built the tutorial app from scratch. And again, if you look at it, like it takes him like a lot of time, a lot of hours and you know, it's not a trivial app. But you end up with something similar to Sveltekit tutorial, similar to Angular tutorial. we took a look at this, and it's kind of not something that we usually do anymore as developers, like building the same structures from scratch. We usually have a framework for everything right now. So that's what gave us the ultimate push to create a framework for building tutorials. So cool. That's tutorial kit in a bit, maybe with a bunch of history. Yeah,

the background was interesting to know. And if anybody has seen us felt tutorial, I haven't seen the anger, the one specifically, but they're powerful learning tools. They're interactive. Like you said, these aren't simple apps. There's multiple panes, the panes are interacting. There's code execution going on. There's reflections, all kinds of things that are going on that have to make that happen. So I love that less people need to worry about that in order to get awesome tutorials out into the world and in the browser, which is so powerful, right? Because there's no curl this and pipe it to that and download this or fire up Docker. It's just like, if you can run it in the browser, that's a huge win. And we've seen a lot of different playgrounds and tutorials moving into the browser, traditionally backend tools, right? SQLite in the browser, Vowasm, there's people putting Postgres in the browser, all these different things. You guys have node, a full node environment in the browser. How does the, just briefly, how does the web containers thing work? Is it similar to WebAssembly? Is it completely different? Are you downloading everything into a browser like a Docker container? Or...

Yeah, this is like the name might be implying something like this, but it's way... we have a way easier work because if you think about it, Node itself is already a wrapper around the browser engine, right? So a ton of when you download Node, a ton of what you're downloading is basically like a kind of copy, let's say, of your browser. And since we're already running in a browser, we can already use this engine. So it's done to us only to implement the missing parts. So that's why it's way more, it's actually more performant. It's kind of non-intuitive if you think about it, because we've all used a bunch of native apps and like desktop apps and browser apps and very often the native apps are like you think of them as faster or more performant you don't have like a heavy weight like video editing apps in the browser yet. Maybe you do already but it's not something that you think about this way but we've heard from a lot of people who are on like low-end, that they're using stack leads. Because they're, let's say, like traditional setup of VS code, which has built on top of Electron itself. So you have already one engine. Then you have Node, another engine. And then you have the browser. So it kind of sometimes kills lower end computers, while in stack this, we use just one browser. There's one less browser

because there's no local mode. You don't need local mode. You have the in browser.

Kind of like two even, because the editor itself is also using this.

Oh, I see. So VS Code unnecessary. So you have just a browser. Free for the price of one.

Yes, exactly. And it wasn't, in fact, as you asked, it wasn't placed a big part. Actually, that's both the, let's say, limitation or the rules that web containers has to play by. And what is possible in web containers is basically if there is a wasm version of such a specific binary, then we can run it. That's, for example, why the Python support was possible because there is a Python, a wasm version of Python. And besides that, yeah, we do have to implement some of this stuff on our own. Our web container engineers are high-level specialists in the node spec at this point, because if you've ever seen a URL parsing spec, you know. I have.

Unfortunately, I have seen a URL parsing spec.

Yeah, so you know, like it's funny because there are some things where actually browser kind of implements it differently than the node, for example, and then you have to do an exception for this. And it's interesting, like the event loop also is something that we spend like weeks of work on just this and like different version of it to make sure like it's it's airtight.