WebContainer API

node.js executing in the browser with all of the browser safety restrictions?

Much appreciated!

It's an irritating name, like PlanetScale. It both makes it sound more official (it's not official at all) and more high-tech than it is.

What WebContainers doesn't do is provide container tech. WebAssembly is similar to a Docker container, so much so that Docker now supports WebAssembly. WebContainers also uses a subdomain and the browser's security model. In fact the browser is the main thing that limits what stuff inside the WebContainer can do in WebAssembly. WebContainer runs whatever JavaScript the WebAssembly code spits out. Like DotCloud one of the great things about WebAssembly is that it can run a wider variety of code performantly than a JavaScript engine can - not just code that can compile to JS but anything that can be compiled to its bytecode. This is what WebContainer takes advantage of - not the sandboxing of a WebContainer, which is also excellent but isn't the right fit for a code sandbox like jsbin/CodePen/CodeSandbox/etc, which needs to be able to run whatever can be run in a browser tab.

What WebContainers does is use some hacks to sort of run node apps in the browser, so instead of using something like the browser version of rollup, you can use something like vite. You can also see the console output that vite would provide.

When vite installs esbuild I think it probably specifies the non-WASM esbuild. So it's likely running patched vite and running WASM esbuild.

It uses a fake npm and yarn and shows npm and yarn in the output. This explained in this FAQ under "Do you support yarn or only npm?": https://github.com/stackblitz/webcontainer-core#faqs

It has an iframe sandbox with same-origin which means in order for it to be contained, you need a subdomain. This is something other major sandboxes do like jsbin and CodeSandbox. This is why IMO it doesn't provide container tech.

That's lucky, because custom container tech on the web winds up being like Google Caja which was a marvelous accomplishment but not nearly as robust as Docker, MicroVMs, WASM, or the browser security model (<iframe sandbox>, CSPs, and more): https://en.wikipedia.org/wiki/Caja_project https://devd.me/papers/LeastPrivileges.pdf

I believe due to CORS and native code being used you would need a service to download NPM packages and compile binaries to WASM.

You could offer self hosting of those and no licensing for commercial products, but you then wouldn't have a financial strategy to develop the technology in the first place. Not quite as much at least.

A big draw is you don't have to give access to a 3rd party all of your code if the technology is client side. Since the server side is just managing/proxying 3rd party dependencies.

All that being said, I'd appreciate a more forthcoming statement of this, as it is confusing, bordering on misleading.

I love the technology though and I do have plans to use it.

For free?

I'm not familiar with node.js, but don't most JavaScript libraries already run in both the browser (including Electron) and node.js?

Is it a matter of significantly different system APIs and standard libraries, and this offers a bridge for applications expecting to run in Node, providing that environment in the JavaScript context of a browser? (Or does it actually run Node in WASM?)

It's very reassuring to see that this is going to be open standard with working group behind it!

I was a bit confused when writing my previous comment. I kind of meant client-side vs server-side part, but I see it may be (or should be) both. I'm impressed you answered in person, please let me elaborate.

webcontainers.io/api describes client-side ECMAScript interface (e.g. `WebContainer.boot().spawn('ls', ['src', '-l'])`). The "StackBlitz WebContainers client" is not the only existing in-browser implementation capable of providing such interface. For example, there is "WebVM" from Leaning Technologies, that "runs unmodified Debian binaries in the browser" using "x86-to-WebAssembly JIT compiler" and "Linux syscall emulator". It can run everything from WebContainers examples, like `ls src -l` or `npm run dev`. One could easily make adapter that uses WebVM to implement WebContainer API. This is what I thought "WebContainers API" should encompass.

But as I learned today, WebVM just like WebContainer also requires a web service (Tailscale) for proxying network traffic. Even JSLinux (bellard.org) uses proxy server. That's necessary because there is no "WebNetworking API" exposing local native networking trough the browser. Usage of such service is implementation detail, but including it in the "WebContainers API" standard is right now the only way to make provider-agnostic clients and I did not consider that before. It may become redundant one day if we get "WebNetworking API" for the browser but there's no such ongoing initiative.

Did I get that right now?

Is StackBlitz WebContainers web service going to proxy arbitrary network traffic, or is it about git, package management and other dev-specific protocols?

Is "WebContainers server API" going to also reflect client API methods to give optional support for thin clients and hybrids? (running all or selected commands in remote container rather than only proxying the network)

Eric (StackBlitz CEO) here- just wanted to confirm that we are indeed using VitePress! By far the best documentation site generator available right now from a DX, design, and flexibility perspective. Highly recommend.

This sounds pretty reasonable, is easily readable, and I suppose this should be the main URL.

The idea is to use the browser as the dev environment, all of it: emulate a file system, run non-JS tools compiled to WASM on top of it, and access networking via the browser, too. For Node-based development, this sounds rather doable.

Enterprise firewall