WebContainer API(webcontainers.io)
webcontainers.io
WebContainer API
https://webcontainers.io/
53 comments
Can anyone translate this from marketing speak to developer speak? I’m genuinely not sure what this is. Is this like… WASM docker in the browser or what?
"Like codepen, but node.js executing in the browser."
node.js executing in the browser with all of the browser safety restrictions?
Much appreciated!
I’m also equally confused.
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
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
> WebAssembly is similar to a Docker container
In what sense?
Maybe I'm thinking too much about the implementation, rather than the use cases, but to me, WebAssembly is a VM/execution environment (in the sense of the JVM, not VirtualBox), whereas Docker is a containerization solution (i.e. a way to isolate userspace environments, for both security and dependency management), and decidedly also not a VM at all.
I can see how they can be used for similar goals, in any case: "Run my binary efficiently on your generic computer without having to trust it".
In what sense?
Maybe I'm thinking too much about the implementation, rather than the use cases, but to me, WebAssembly is a VM/execution environment (in the sense of the JVM, not VirtualBox), whereas Docker is a containerization solution (i.e. a way to isolate userspace environments, for both security and dependency management), and decidedly also not a VM at all.
I can see how they can be used for similar goals, in any case: "Run my binary efficiently on your generic computer without having to trust it".
I'm thinking of the end product of the "Docker container", not all of the things it takes to get there. The "my binary" part is what WebContainer emphasizes, and it's somewhat impressive in how many programs it can run.
I agree WASM is more similar to the JVM but I think the JVM is pretty similar to a Docker container in a way, if you get rid of all the higher level JVM features like garbage collection, and for docker container look at the whole system and not just docker. If you have a computer with only docker installed it's easy to think of it as docker when it's really docker or containerd running on the Linux distro. Or some MicroVM orchestration.
I agree WASM is more similar to the JVM but I think the JVM is pretty similar to a Docker container in a way, if you get rid of all the higher level JVM features like garbage collection, and for docker container look at the whole system and not just docker. If you have a computer with only docker installed it's easy to think of it as docker when it's really docker or containerd running on the Linux distro. Or some MicroVM orchestration.
Great breakdown, thank you! Tricky landscape. Did not get any of that from the marketing page.
s/not the sandboxing of a WebContainer/not the sandboxing of WASM/g
This looks really cool (I love anything with a filesystem API), but I'm unclear on the role of hosted proxies in this setup. Also, the licensing costs aren't clear.
"WebContainers rely on hosted proxies and server-side acceleration to enable truly instant development environments. By obtaining a WebContainer API license, your business can gain access to higher API rate limits, uptime reliability, and a range of benefits designed to help you maximize the potential of the WebContainer API in your organization."
"WebContainers rely on hosted proxies and server-side acceleration to enable truly instant development environments. By obtaining a WebContainer API license, your business can gain access to higher API rate limits, uptime reliability, and a range of benefits designed to help you maximize the potential of the WebContainer API in your organization."
That's bizarre how the major emphasis is on running things client-side instead of on a hosted VM, but then it still requires a live paid service
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.
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.
Eric (CEO of StackBlitz) here- your explanation is 100% correct regarding why & how servers need to be used to power parts of WebContainer environments (i.e. proxying npm, git, transforming binaries, amongst a handful of other things).
Some of these operations can be cacheable which is ideal for scalability, but even the ones that cannot tend to be far cheaper than running VMs which incur by the minute CPU costs.
Our intention is to be fully transparent on the how & why, so I’m happy to answer further questions on all this! I also think it’d be good for us to include something more detailed like your explanation in our docs so that other folks don’t feel similarly confused when reading them- curious if there’s particular points that jump out to you that I can share with our team to include!
Some of these operations can be cacheable which is ideal for scalability, but even the ones that cannot tend to be far cheaper than running VMs which incur by the minute CPU costs.
Our intention is to be fully transparent on the how & why, so I’m happy to answer further questions on all this! I also think it’d be good for us to include something more detailed like your explanation in our docs so that other folks don’t feel similarly confused when reading them- curious if there’s particular points that jump out to you that I can share with our team to include!
I don't have any questions, but I would like to work for you, love the project.
I will contact you...
I will contact you...
What kind of use cases does this have? Excuse my ignorance on the topic
[deleted]
Short of building my own using this API, does a self-hosted Codesandbox/Stackblitz alternative exist? I love the idea of spinning up web containers within my corporate network so I can prototype applications using internal APIs.
Beware of this (from their enterprise page):
"Licensing is required for production usage of the API in a for-profit setting (feel free to prototype as much as you like without a license). If you're using the API to meet the needs of your customers, prospective customers, and/or employees you need a license to ensure continued access to the API as you scale."
"Licensing is required for production usage of the API in a for-profit setting (feel free to prototype as much as you like without a license). If you're using the API to meet the needs of your customers, prospective customers, and/or employees you need a license to ensure continued access to the API as you scale."
Eric (StackBlitz CEO) here- you can actually self host StackBlitz! You’ll just need our Enterprise Edition (https://stackblitz.com/enterprise) which can be run on any cloud or on-prem. Happy to answer any questions you might have!
For free?
We have a generous free tier on stackblitz.com! Self-hosting does require a paid license though (we have to keep the lights on somehow :)
Gitpod/codeserver exist.
They are basically cloud vscode with server sidr containers.
Codeanywhere offers on-prem hosted and air-gapped workspaces supporting devcontainer.json
It's tempting to try to integrate this as an alternative to actual containers or fly.io but it seems to need to execute arbitrary npm installs on my server which defeats the purpose since the goal is to everything in the customer's browser instead of trusting their code on my server.
Er, I must be missing an important nuance here, can someone who understands this explain. What is the real world use case for this? I'm afraid I don't understand what this provides that either wasm or the browser sandbox does not.
https://learn.svelte.dev/tutorial/introducing-sveltekit was built with web containers. SvelteKit allows developers to create server-side APIs and do server-side rendering and web containers allow those server-side components to run in the browser.
This page has some more helpful explanation https://blog.stackblitz.com/posts/introducing-webcontainers/ It has some nice features like native back-end debugging for things like Next.js apps.
Do you want to run nodejs right inside your browser without a backend? If not, then you can just ignore it.
But if you do, then this attempts to solve that problem.
If you're asking what's the use case for running nodejs in the browser? I say use your imagination.
But if you do, then this attempts to solve that problem.
If you're asking what's the use case for running nodejs in the browser? I say use your imagination.
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?)
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?)
Does "WebContainer API" mean "proprietary web service for accessing npm and git over http"?
Or is it "ECMAScript API of new open source WASM-based POSIX-style browser OS"?
The documentation doesn't seem to separate these two, and applying such name for the former would seem intentionally misleading to me, especially if it gets trademarked by commercial entity providing the service.
The documentation doesn't seem to separate these two, and applying such name for the former would seem intentionally misleading to me, especially if it gets trademarked by commercial entity providing the service.
> is it "ECMAScript API of new open source WASM-based POSIX-style browser OS"
This is closer to what the Bytecode Alliance is looking to do with WASI, which we're playing a small (but crucial) part in: https://blog.stackblitz.com/posts/bytecode-alliance/
> Does "WebContainer API" mean "proprietary web service for accessing npm and git over http"?
Kinda, we have plans to allow self hosting and more reg open source- more to come!
This is closer to what the Bytecode Alliance is looking to do with WASI, which we're playing a small (but crucial) part in: https://blog.stackblitz.com/posts/bytecode-alliance/
> Does "WebContainer API" mean "proprietary web service for accessing npm and git over http"?
Kinda, we have plans to allow self hosting and more reg open source- more to come!
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)
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)
"This site is blocked due to a security threat that was discovered by the Cisco Umbrella security researchers."
This is potentially exactly what I'm looking for to take Boot.dev to the next level. I'm a bit worried that it's too JS focused, but if I can hack in the other stuff I need with wasm then this gets really exciting. thanks for posting :)
FYI, in your homepage video explainer, the code contains the comment "Don't touch above this line", but I think you meant "below" given the purpose of the exercise.
While this is really cool the setup guide feels like a lot of work and headache for an app that's already running in your browser in step 1.
I like the website layout. Knowing little about Web development. Is this custom made or using some kind of framework/template?
It looks like they're loading in MDX (Markdown) for a lot of the pages
There are quite a few "static-site generator" templates that are easy to setup and customize and many of them are free to use! If I had to guess, I think they're using VitePress [1] here. Nextra [2] is also good for this kind of a website.
[1] https://vitepress.vuejs.org/
[2] https://nextra.site/
There are quite a few "static-site generator" templates that are easy to setup and customize and many of them are free to use! If I had to guess, I think they're using VitePress [1] here. Nextra [2] is also good for this kind of a website.
[1] https://vitepress.vuejs.org/
[2] https://nextra.site/
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.
I thought this was like a standardization effort of Firefox's Multi-Account Container.
Doesn’t work in Safari for me
HN title is a little editorialized, making it sound like a new browser standard. Should be edited imo
The materials themselves also drip with exaggeration and hand-waving, talking about things like "the legacy cloud VM" (emphasis mine), "unmatched security", "spinning up the entire dev environment in milliseconds"
All of this is aside from the actual technology, which could be cool, I have no idea yet. But it rubbed me the wrong way
The materials themselves also drip with exaggeration and hand-waving, talking about things like "the legacy cloud VM" (emphasis mine), "unmatched security", "spinning up the entire dev environment in milliseconds"
All of this is aside from the actual technology, which could be cool, I have no idea yet. But it rubbed me the wrong way
They are aiming to develop a standard... of sorts...
https://github.com/stackblitz/webcontainer-core
https://github.com/stackblitz/webcontainer-core
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.
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.
It is nice, but not totally free or open source:
"WebContainers rely on hosted proxies and server-side acceleration to enable truly instant development environments. By obtaining a WebContainer API license, your business can gain access to higher API rate limits, uptime reliability, and a range of benefits designed to help you maximize the potential of the WebContainer API in your organization.
Licensing is required for production usage of the API in a for-profit setting (feel free to prototype as much as you like without a license). If you're using the API to meet the needs of your customers, prospective customers, and/or employees you need a license to ensure continued access to the API as you scale.
"
"WebContainers rely on hosted proxies and server-side acceleration to enable truly instant development environments. By obtaining a WebContainer API license, your business can gain access to higher API rate limits, uptime reliability, and a range of benefits designed to help you maximize the potential of the WebContainer API in your organization.
Licensing is required for production usage of the API in a for-profit setting (feel free to prototype as much as you like without a license). If you're using the API to meet the needs of your customers, prospective customers, and/or employees you need a license to ensure continued access to the API as you scale.
"
[deleted]
Site is blocked due to “active security threat” so that’s not a good sign for an enterprise SaaS
[deleted]