back

by binyu·2mo ago·view on hn ↗
Been working on something similar based on Webcontainers. How does your Node.js support compare with StackBlitz technology?

Are you running the version of Claude code that Anthropic distributes in the browser or did you have to adapt it to run on your stack?

Cheers

1 comments
Our technology is much more general that WebContainers, and it's based on a Linux-compatible WebAssembly kernel. It also supports real command line tools, including git, bash and the complete set of busybox utilities.

The version of Claude Code you see running is completely unmodified.

Awesome, what approach are you using? Is this a real micro kernel architecture or just containerized VM?
The architecture is a fairly straightforward WebAssembly-native monolithic kernel. Most of the complexities come from making things work well within the browser constraints for real world, large apps.

We have quite a bit of experience on the topic however, these are previous projects of ours:

WebVM (https://webvm.io): x86 Debian shell running client-side in the browser via x86 -> WebAssembly JIT compilation

Browsercraft (https://browsercraft.cheerpj.com): Minecraft running unmodified in the browser via our WebAssembly JVM (CheerpJ)

Oh, you are the author of WebVM, pretty cool! I looked at it while choosing the stack for our project and it seems very solid.

Keep up the great work

As a matter of fact WebVM and BrowserPod share the same kernel, the difference is all on the performance side.

WebVM uses x86 virtualization and hence has a significant performance penalty, with the upside of running any existing software without needing the source code.

BrowserPod on the other hand runs WebAssembly binaries at almost native speed. Source code is required, but that is a fair compromise in the world of sandboxing. Most language runtimes and CLI tools are FOSS anyway, and many closed-source tools (such as Claude Code) are written in scripting languages and run on top of FOSS engines.

> WebVM uses x86 virtualization and hence has a significant performance penalty

That is precisely the reason why we chose not avoid using any solution which uses virtualization, even though you get a full OS. QuickJS also pays a performance tax (no JIT) and still doesn't give you the OS.

On our part we're mostly focused on JS for the time being and we think that the best bet is to reuse the browser V8 engine