51–54 of 54 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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 techno…
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…
I will contact you...
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.
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.
> 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- mo…
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)