Always great to see uses of CheerpJ in the wild. Make sure to join our Discord to show the community what you are building.

https://discord.leaningtech.com

Running legacy educational Java applets, especially around math and physics, has been a longstanding popular use case of our CheerpJ Applet Runner extension, running Java bytecode in the browser via WebAssembly.

I am not sure how to feel about agents solving the problem via proper modernization. It's certainly positive that students will be able to interact with this content in a modern and more accessible way, but the educational use case for our product, although not commercially important, has always been a source of pride.

https://chromewebstore.google.com/detail/cheerpj-applet-runn...

As another commenter pointed out this is similar to our WebVM (https://webvm.io) , although this one is based on v86 so it will be less performant.

Although the x86 virtualization angle is powerful we think that native WebAssembly executables on top of a Linux-compatible kernel are more viable for the execution of full workloads in the browser.

BrowserPod is a newer project of ours that brings to vision to life, we have recently published a deep dive that might be interesting: https://labs.leaningtech.com/blog/browserpod-deep-dive

i like your work. i am also experimenting with a native webassembly linux core and the performance is incredible. i just had enormous trouble and work compiling packages for the wasm32-linux target. it would be a nice community effort to compile the open source world to this architecture. the browser tab as clean, secure, multi-platform and polyglot abstraction layer.

We are working to solve the "sandoxing in Wasm" problem across multiple runtimes.

https://labs.leaningtech.com/blog/browserpod-deep-dive

Node.js is now fully supported, Python is in preview and Rust is coming soon.

For a glimpse of the possibilities, check our Claude Code running fully in the browser: https://browsercode.io/claude

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

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

Shameless plug: we solved the opposite problem, running any Java application in the browser via WebAssembly: https://labs.leaningtech.com/blog/cheerpj-4.3

And yes, it does run Minecraft as well :-) https://browsercraft.cheerpj.com/

But can it run Endive?

Not something I tried myself, but conceptually if it's Java it should work.

CheerpJ Just-In-Time compiles Java bytecode at runtime, so it makes no difference if the classes come from JAR files or are dynamically generated.

How close are we to the birth and death of yavascript?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

I wonder what the performance loss is for each level?

Mmhh should work for clojure as well then. I should try this.

I can confirm non-Java languages work as expected. I've personally tried Kotlin, and IIRC some user from the community reported Clojure to be working as well.

Consider joining our Discord for help: https://discord.leaningtech.com

Thanks :-) We have been building WebAssembly-based products for a while now, so for us it's second nature.

But I think you are right, most developers, even experienced ones, have not yet come to grasp the fully capabilities of the Web platform in conjunction with WebAssembly.

You might find previous projects from us also interesting:

* WebVM (https://webvm.io): x86 virtualization in the browser

* CheerpJ (https://cheerpj.com): A WebAssembly JVM to run large scale Java apps unmodified

* BrowserCode (https://browsercode.io/claude): Run Claude Code (and other agents) unmodified in the browser.

We are thrilled to share with the HN community the second preview of BrowserCode: A FOSS web app to run TUI agents (such as Claude Code, OpenCode, Gemini CLI and the like) fully in the browser. This release focuses on Claude Code and initial support for mobile. BrowserCode is released under the Apache License, version 2.0.

BrowserCode is based on BrowserPod (https://browserpod.io), a in-browser WebAssembly-based code sandboxing technology that can currently run Node.js, python, git, bash and many other command line tools. This will further expand to Ruby / Rails, Go, Rust and eventually x64 Linux binaries.

BrowserCode is free to use and unlimited. You'll need to login to each CLI with the corresponding login, i.e. with your Anthropic account or API key. All the data and execution stays completely local to the browser and it's persistent across sessions thanks to a disk backend based on the Origin Private File System API or IndexedDB.

This is a preview release, so please try and break it! Please report issues on GitHub and star the repo if you like our work. Your support will help us push this project forward.

For any question or feedback please consider joining our Discord: https://discord.leaningtech.com

Hello HN! I am happy to share to release with the community.

Thanks to BrowserPod it is now possible to run node.js developer workflow completely in the browser. An example of what can be done today.

- Clone a repo (via git clone)

- npm install

- npm run dev

- Connect to the dev server from anywhere on the internet (via Portals)

- Commit changes and push them to the repo

This is achieved by native WebAssembly builds of git, bash, node and many other utilities. A WebAssembly kernel, designed from scratch by us, provides a consistent virtual machine view to all the processes in the sandbox.

Python is also available in preview, with Ruby, Rust and Go coming soon.

The main use case is to sandbox AI-generated code, but the technology is generic and we can envision many other use cases: Web-based IDEs, educational platforms, live docs, ...

Happy to answer any questions, let us know what you think.

Hi, lead dev of WebVM here. Can you link to the specific change that affects ephemeral devices? I cannot find this reference in the article.

Keep in mind that we also plan to offer builtin networking in the near future, we are developing the infrastructure to do so as part of our newest product (In-browser sandboxes): https://browserpod.io

https://tailscale.com/pricing says "1,000 mins per month for ephemeral resources"

Thanks for sharing. I see how this could impact heavy user, but there is always the option of authenticating via a non-ephemeral auth key as a potential workaround. It's not integrated in the public WebVM UI, but it is supported by the underlying engine (CheerpX).

Do you have any specific test case that you would consider "very challenging" on the compatibility side? I'd be curious to check if BrowserPod can support that already.