apignotti

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

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.

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)

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.

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

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

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.

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/

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.

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).

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

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.

Only node is supported as of version 1.1, but the next version is fully focused on command line tooling (git, bash, ssh, grep, ...).

See the launch blog post for our full timeline: https://labs.leaningtech.com/blog/browserpod-10

Also, could I ask you to quickly edit your previous comment to clarify you were benchmarking against the older project?

Demo works as expected for me, please share information if possible or join our Discord for further help: https://discord.leaningtech.com

This is not correct. You are using WebVM here, not BrowserPod.

WebVM is based on x86 emulation and JIT compilation, which at this time lowers vector instructions as scalar. This explains the slowdowns you observe. WebVM is still much faster than v86 in most cases.

BrowserPod is based on a pure WebAssembly kernel and WebAssembly payload. Performance is close to native speed.

We are working on exactly this: https://browserpod.io

For a full-stack demo see: https://vitedemo.browserpod.io/

To get an idea of our previous work: https://webvm.io

We test performance internally constantly, and we plan to soon publish a benchmarking repository.

Depending on the workload the performance is actually very close to native, I'll give a few highlights.

* Node.js C++ code is compiled to WebAssembly and as such is very close to native speed

* Node.js JavaScript payloads are executed directly by the browser engine. There is some additional overhead in some scenarios, but it's not large and we expect to further improve this down the line.

* There is proper multi-process support via WebWorkers. Multiple node processes can actually run in parallel on top of the same WebAssembly kernel.

There are a few areas that we need to improve still, to make an example we are hitting some of the limitations of IndexedDB for data persistent and we are experimenting with the OPFS API to squeeze some more performance. This is tricky since performance with OPFS is very dependent on the browser at this tie.

Our kernel itself still need some work, as concurrency in some scenarios is limited by overly extensive locking. We expect to make significant progress on these problems as well over the next weeks and months.

Moreover, the most direct alternative to BrowserPod is not a local sandbox, but a cloud provisioned one. Of course cloud performance depends on how much the platform owner is willing to spend, but we expect BrowserPod to be actually _much_ faster than common cloud options especially on the cheaper tiers.

We plan to publish benchmark against the main cloud sandbox providers as well in the future.

[Edited to mention the comparison against cloud VMs]

Hello HN community, I am very happy to share with you BrowserPod for Node.js - a sandboxed Node runtime, compiled to WebAssembly, that runs completely in the your browser.

BrowserPod builds on our previous work on WebAssembly virtualization, see WebVM (https://webvm.io) as an example. The environment is not a simple set of shims, but the "real" Node.js, including support for filesystem, multiple processes and outbound and inbound networking.

This latest feature is powered by "Portals", shareable public URLs that let any user you want, anywhere on the internet, access full-stack applications running locally in your browser. Portals can be used to power live demos of full-stack frameworks, previewing what you (or your agent) are building and sharing the state of your app with testers, colleagues or customers.

Node.js is just the first "engine" of BrowserPod. Behind the scenes there is a real WebAssembly kernel and we are soon going to support more languages, with Python, Ruby, Go and Rust coming first in our pipeline.

Later in the year we expect to merge back our previous work on x86 virtualization into BrowserPod, and be able to run arbitrary binary containers safely sandboxed in the browser.

Let us know what you think.

As far as I know lots of EU countries don't allow double citizenship. This implies that, even when having the prerequisites, acquiring the new citizenship for the sake of voting also mean losing the old citizenship altogether. At least for me this is too much to ask. I am happy with my life in my new country of residence, but I am still very connected to my heritage.

On the other hand I would be quite happy to give up my _voting rights_ in the original country in exchange for local ones. I do understand that allowing double voting would give mobile citizens an excessive amount of weight, but letting each individual choose would seems quite reasonable to me.

And in any case, might the EU live long and prosper.

It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)

Hi, if you like the idea of Wasm sandboxing you might be interested in what we are working on: BrowserPod :-)

https://labs.leaningtech.com/blog/browserpod-beta-announceme...

https://browserpod.io

The browser is the most effective environment to distribute and isolate applications. We have built technologies for years to leverage these capabilities to run legacy Java (CheerpJ) and x86 binaries (Cheerpx / WebVM).

We are soon going to release a new technology, built on top of the same stack, to allow full-stack development completely in the browser. It's called BrowserPod and we think it will be a perfect fit for agents as well.

https://browserpod.io

Firefox should work just fine, I tried it right now.

Consider dropping in our Discord for further help: https://discord.leaningtech.com

We use WebAssembly aggressively at Leaning Technologies across our tools.

WebAssembly makes it possible to:

* Run x86 binaries in the browser via JIT-ting (https://webvm.io)

* Run Java applications in the browser, including Minecraft (https://browsercraft.cheerpj.com)

* Run node.js containers in the browser (https://browserpod.io)

It's an incredibly powerful tool, but very much a power-user one. Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.

We’re launching BrowserPod today in open beta, after a month-long closed beta with early adopters.

BrowserPod is an in-browser code sandbox for dev environments built on WebAssembly, that runs Node.js directly in the browser with no cloud provisioning.

BrowserPod containers run Node.js code at native speed, without modifications, using only client-side compute. They are built on a full version of Node compiled to WebAssembly, with the browser’s local JavaScript engine taking the place of Node’s embedded v8. BrowserPod provides a Linux-compatible kernel built on top of WebAssembly and modern Web technologies. The BrowserPod kernel is derived from our previous work on x86 virtualization in the browser (see WebVM - https://webvm.io) and supports multiple processes/threads on top of WebWorkers and advanced filesystem and networking capabilities.

BrowserPod can seamlessly expose virtualized HTTP endpoints to the wider internet. We call this feature “Portals”. We believe Portals to be one of the most exciting features of BrowserPod, making it possible to run tests on real mobile devices or to share your work with testers, early adopters and customers without setting up any hosting.

While we’re focusing on Node.js 22 now, the architecture is language-agnostic. Python and Ruby support are immediate priorities and will be released in early 2026. Extensive support for command line tooling will be added in the near future. We’re prioritizing git, bash, and compression utilities, but let us know what tools would be most helpful for you.

I’d love to hear your thoughts, and I’m happy to take any technical questions you have.

Indeed, it's not. It's possible we might decide to release the code in the future, but for the time being we are keeping it proprietary.

What you describe is 100% possible. Rails is one of our priorities. PHP is also easy to achieve.