Bring Node.js into your browser with WebContainers

Hello NodeJS Congress, welcome to my talk about bringing NodeJS into your browser with web containers. We'll talk about the history of Node, about browsers, and finally about web containers.

Web containers are a technology from StackBits that enables you to run NodeJS apps inside your browser. This is really the very first time that we are talking about that in public, so thank you for having me here. My name is Silvia Vargas and I'm a front-end developer but I also run developer relations at StackBits.

So this is the roadmap for the next 20 minutes. First we'll talk about the early 2000s and the attempts to take JavaScript out of the browser. Then we'll move back to the 2020s where we will talk about bringing Node.js into the browser. And finally, we'll take a look at the present times and the future. As you see, this talk really starts and ends with browsers and so you will see a lot of those in this talk. If you're a person who likes to try things out immediately, go check out node.neo which is a disposable Node.js playground powered by web containers. Meanwhile, while you are experiencing the future, we will move back in time to the early 2000s. Are you ready?

Node.js was created by Ryan Dahl in 2009. You need to keep in mind that JavaScript was created to be executed inside the browser. In one of his talks, Ryan explained how he was looking for a way to build a network application that could handle a large number of simultaneous requests. So before Node.js, there were some attempts to run JavaScript outside of the browser. For example, one of such attempts was Rhino. But they never managed to bring server-side JavaScript to the mainstream. Node.js changed that. So let's look at how that happened.

In 2008, Chrome was released with V8. V8 is a JavaScript engine. It is an open source project designed to execute JavaScript code as fast as possible by employing JIT, just in time compilation. That means that JavaScript is compiled to machine code and not interpreted. So here is the announcement blog post from 2008. We will not read it in its entirety, don't worry. But let's take a look at one fragment. So no one likes big quotes, so let's take it apart. Here are some prophetic words. As web applications grow, we believe that suite will be representative of how web developers write JavaScript code. Chrome really did change how JavaScript is written, but also where. And now the second part of the quote. In the second part, here they are mentioning their mind-blowing benchmark suite consisting of five average JS apps. A total of 11,000 lines of codes, 11,000. I will leave you with this number. So in this context, Rayon Daal pulls the source of V8 and spends six months on creating Node.js. Node.js was designed to be an event-driven server-side framework that could handle Io operations in a non-blocking way. Now Js could be really run everywhere. And here's a talk from 2009, JsConf, where Rayon Daal presented this idea.

To understand our problems better, the problems that we are facing today, let's take a look at the history one more time, or one last time. How was the internet like back then, back in early 2000s? Back then, the browsers weren't too powerful. So for example, in one talk, Rayon Daal mentions how excited he was about the progress bar when uploading files.

So for example, in one talk, Rayon Daal mentions how excited he was about the progress bar when uploading files. Like, just to remind you, this is what the progress bar looked like. I mean. So fast forward 15 years, and we see that browsers grew in power. Now, actually, let's look at the comparison. So in 2000s, 5 average pages were just of 11,000 lines of code in total. Right now, when you run a Create React app, that alone generates 30,000 lines.

In 2005, that's when Google Maps and Gmail was launched. Now we are talking about edge computing, real-time collaboration, and AI. Back then, the top three websites in 2005 were Wikipedia, Flickr, and iTunes. Or in 2008. Right now, it's Google, Facebook, TikTok. If you look at those three, actually, those pairs, they are kind of similar, but only in terms of how they are used and not really the technology. And in 2000s, we need to remember that that was pre-ES5, whereas now we are so many iterations of ECMAScript ahead. We have the web sockets, service workers, and so on. So given how powerful browsers are nowadays, maybe we could really run JavaScript, including Node.js, everywhere. So let's talk about bringing Node.js to the browsers.

The fact that you can do something doesn't mean that you should. So let's look at what could be enabled with Node.js running in the browser. For example, there's a use case of education. From courses, to blogs, to demos, your audience could just experience what you are teaching them right there in the website. Documentation, showing is always better than telling. Testing, creating reproductions. Client side tooling, like bundlers, task runners, and code generators. Employment, like interviewing platforms or onboarding platforms. And finally, experimentations. We, ourselves, don't know how you can really use Web Containers to its full power. We'll see.

So now it all sounds great, but, well, there's a but. Node.js is designed to work with server-side APIs, such as file systems, network sockets, and HTTP servers.

Its big portion is also written in C++, which can't be run in the browser because browsers only speak two languages, which is JavaScript and WASM. Then browser environment is designed to work with APIs, which allows JavaScript code to interact with user interface, I don't know, handle events, and so on.

Browsers are also isolated environments. They are sandboxed. That means that they have no way to, I mean, they can't just access your local machine. This is for security reasons. So it is clear that there is an API mismatch. So even if you compiled Node.js to WASM, even if they spoke the same languages, that still wouldn't work because they don't have the same tools.

So there are some approaches of solving this issue of bringing Node.js to the browsers. One of such examples would be virtual machines in the cloud, running them to execute user code. However popular this approach is, there are some drawbacks. First of all, it's costly. Your users pay per minute of connection and also per storage. And then there's also the environmental cost. Secondly, VMs depend on the internet connection. So no internet, no service. What if you lose Wi-Fi while working? And third, it's also dangerous. This approach is popular among Bitcoin miners, but also phishing websites and so on. Then another example would be playgrounds that don't rely on cloud, but require custom patching for every single framework. StackViz had one of such playgrounds as well with a technology called EngineBlock. This approach was not scalable because there are so many different frameworks out there. The most important point though is that it just doesn't emulate Node.js. It only emulates its very limited capabilities. Like you have to provide patching for every single framework.

So what I'm trying to say is that the patching, if any, should be kept to a minimum to emulate Node.js behaviors to the most accuracy. So, what if I told you that there's actually a better way? Well, in May 2021, Stackbrite announced web containers. So just like Randall pulled the source of V8 to enable JavaScript to run outside of the browser, Stackbrite pulls Node.js from the source to enable running Node.js apps inside the browser. So, Stackbrite emulates the behavior of Node.js to run in-browser with WASM and with SAMREST to the highest accuracy possible. So, even though it was announced in May 2021, the web containers were already working well a bit before. For example, here is a podcast episode where Dom and Eric demonstrate web containers.

So, how did Stackbrite actually managed to do that? Well, the story goes back to 2018, actually 2017, where Stackbits was just conceived. Before that, Eric Simons and Albert Pai, they were two childhood friends. They were running a platform where you could learn to code. They noticed that their students usually struggled with setting up the environment. So, in 2018, they thought that they would leverage the power of a browser to lower the barriers of learning to code. So, the very first two years were very frugal. It was just them and two engineers, Dom Elm and Tomek Sulkovski. So, Stackbits was growing the team and also developing with containers. Here's, for example, our team right now. We are in 14 countries.

So, let's talk about how, actually, we figured out this innovation. This meant, for example, writing the entire file system, which actually took three iterations until it was finally scalable and fast enough. It was about implementing ES modules, which included, for example, circular imports and how modules were instantiated, implementing event loop, implementing the V8 serialization API, creating Turbo, which is our own package manager, which actually we are sunsetting right now because we have native support for package managers, and then also figuring out how to run shell commands and how to integrate Git. But working on web containers also meant designing for the future, a future that is sustainable, open, and collective.

From the beginning, StackBlitz was about supporting the whole web ecosystem and taking bold decisions about emerging technologies. So, for example, even though the spec for Wasm threads has only recently reached phase three in its path to becoming a standard, this technology has been the bedrock of web containers since a very long time, allowing the incredible speed. Connected to that, StackBlitz uses shared array buffer, which is a modern JavaScript feature. It allows for parallel processing and faster execution times. Choosing it meant initial limited support for Safari, but not anymore. In January 2023, SafariTP was announced with shared array buffer support, and many of the frameworks just work in web containers. But building for the future also means a commitment to making the whole ecosystem better.

Because of that, we joined Bytecode Alliance, which is a cross-industry partnership accelerating the world's transition to secure-by-default computing. But improving the whole ecosystem is not only about spotting bugs. We are also huge fans of open source. On our journey, we submit PRs to the tools we use. For example, WASPAC, parking lot, PMPM, Git isomorphic. Or like this one to Node.js, which paved a path to universal packages. But we also support Wit not only by sponsoring it or sponsoring Wit.conf, but also by hiring its core maintainer who works full-time on Wit. All this is to say that we do love open source. In May, 2022, we worked with the SvelteKit team on making Web Container API so that everyone could use this tool to push the boundaries of the web with us. In February, 2023, we released it and it's free for open source as well as small scale for-profit projects.

But improving the whole ecosystem is not only about spotting bugs. We are also huge fans of open source. On our journey, we submit PRs to the tools we use. For example, WASPAC, parking lot, PMPM, Git isomorphic. Or like this one to Node.js, which paved a path to universal packages. But we also support Wit not only by sponsoring it or sponsoring Wit.conf, but also by hiring its core maintainer who works full-time on Wit. All this is to say that we do love open source.

In May, 2022, we worked with the SvelteKit team on making Web Container API so that everyone could use this tool to push the boundaries of the web with us. In February, 2023, we released it and it's free for open source as well as small scale for-profit projects. If you want to learn about it, you can go to webcontainers.io. And on there, you can actually see a small web container running. You can also try it yourself. You can just go to a webcontainers.new.

So let's see what has been built with Web Containers so far. For example, education. Web Containers are used in Total TypeScript, the amazing course. They're used in Docs, for example, and Embedded Demo from the Node.js Docs. They are used as back reproductions. They are used in Tutorials, the Sveltekit Tutorial. They are used in experiments, for example, this visual programming app, Nano. Here is also an app that generates, that uses AI to generate other apps. And finally, I mean, there is also the client side tooling. For example, Cloudflare Wrangler that is a tool to develop Cloudflare workers. And maybe this is also a good time to talk about how web containers work. So first, Web Container Boots App. This is when an iframe is created in which the web container will operate. This is yet another level of security. As you remember, the browser is a Sandbox environment. In the browser, there is the web container running in its own iframe so that it has no access to any information on the page on your website. So it's double isolation.

Then once the web container is booted, dedicated workers come into play. They will function as processes for your program. If you are installing dependencies or like if there's any package manager, you know, situation happening, web containers will make requests to start this domain, which serves as a proxy to package registries thanks to which the installation is optimized. So usually, actually the dependency installation goes faster than locally. If it's not, let us know.

And if your app features a web server, web containers include a virtualized TCP networking stack that's mounted to your browser's service worker API. So if your Node.js app runs a dev server, you'll be prompted to open a URL that points to an external domain that is actually powered by a service worker locally inside your browser. Because of this connection, you can open this URL in another tab, and it is securely isolated from another browser instance. That also means that even if you lose the internet connection midway, you can still see that this URL works as long as the service worker is registered. So web containers are actually fast, faster than local because of how we handle dependency. Here is a demo of PMPM, up to four times faster than local, and of Node.js. Again, if something takes longer than locally, please let us know.