Bring Node.js into your browser with WebContainers

Rate this content
Bookmark

In this talk, I'd love to inform and inspire the community to push the limitations of web development running Node.js inside the browser. I will cover how and why we developed WebContainers, what our roadblocks and limitations were and are, how we've worked with the community to make the technology better and what has already been enabled and built with WebContainers.

21 min
17 Apr, 2023

AI Generated Video Summary

This Talk discusses bringing Node.js into the browser using web containers. It covers the history of Node.js and the internet in the early 2000s, the possibilities of Node.js in the browser, and approaches to achieving this. It also explores Stackbits' journey and growth, innovation in web container design, and the functionality of web containers. The Talk emphasizes the importance of open source and collaboration in improving the web ecosystem.

1. Introduction to NodeJS in the Browser

Short description:

Welcome to my talk about bringing NodeJS into your browser with web containers. We'll discuss the history of Node, browsers, and web containers. Web containers from StackBits allow running NodeJS apps in the browser. This is the first public discussion of this topic. I'm Silvia Vargas, a front-end developer and developer relations at StackBits. The roadmap covers the early 2000s, bringing Node.js into the browser in the 2020s, and the present times and future. Check out node.neo, a disposable Node.js playground powered by web containers. Let's begin by going back to the early 2000s.

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?

2. Node.js History and Internet in Early 2000s

Short description:

Node.js, created by Ryan Dahl in 2009, brought server-side JavaScript to the mainstream. It was built to handle a large number of simultaneous requests and was made possible by the release of Chrome with the V8 JavaScript engine in 2008. V8 compiles JavaScript to machine code for faster execution. Node.js became an event-driven server-side framework that could handle I/O operations in a non-blocking way. This idea was presented by Ryan Dahl at JsConf in 2009. In the early 2000s, when the internet was less powerful, Ryan Dahl was excited about the progress bar when uploading files.

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.

3. Node.js in the Browser Possibilities

Short description:

In the early 2000s, browsers were less powerful, with only 5 average pages totaling 11,000 lines of code. Now, with the advancement of technology, browsers are capable of edge computing, real-time collaboration, and AI. Bringing Node.js to the browser opens up possibilities for education, documentation, testing, client-side tooling, employment, and experimentation. However, it's important to note that Node.js is designed for server-side APIs.

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.

4. Approaches to Bringing Node.js to Browsers

Short description:

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. 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. Another example would be playgrounds that don't rely on cloud, but require custom 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. In May 2021, Stackbrite announced web containers. Stackbrite pulls Node.js from the source to enable running Node.js apps inside the browser. Even though it was announced in May 2021, the web containers were already working well a bit before.

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.

5. Stackbrite's Journey and Growth

Short description:

In 2018, Stackbits was conceived by childhood friends Eric Simons and Albert Pai. They aimed to lower the barriers of learning to code by leveraging the power of a browser. With a small team, Stackbits grew and developed with containers, now operating in 14 countries.

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.

6. Innovation and Future Design

Short description:

Let's talk about how we figured out this innovation, including writing the entire file system, implementing ES modules, the event loop, the V8 serialization API, creating Turbo, and integrating Git. Working on web containers meant designing for a sustainable, open, and collective future. StackBlitz supports the web ecosystem, makes bold decisions about emerging technologies, and uses shared array buffer for parallel processing. They joined Bytecode Alliance to improve the whole ecosystem and are active contributors to open source. They worked with the SvelteKit team on the Web Container API, released in February 2023.

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.

7. Web Containers and Open Source

Short description:

Improving the whole ecosystem is not only about spotting bugs. We are also huge fans of open source. In May 2022, we worked with the SvelteKit team on making Web Container API. It's free for open source and small scale for-profit projects. Web Containers are used in education, documentation, tutorials, experiments, and client-side tooling. Web containers work by creating an iframe for the web container to operate, providing an additional level of security and isolation.

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.

8. Web Container Functionality

Short description:

Once the web container is booted, dedicated workers function as processes for your program. Web containers optimize dependency installation, making it faster than local. If your app features a web server, web containers provide a virtualized TCP networking stack and allow opening URLs that are securely isolated from other browser instances. Web containers are fast and handle dependencies efficiently. If you experience any issues, please inform us.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.