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.
~20x slower for a naive recursive Fibonacci implementation in Python (1300 ms for fib(30) in this VM vs 65ms on bare metal. For comparison, CPython directly compiled to WASM without VM overhead does it in 140ms.)
~2500x slower for 1024x1024 matrix multiplication with NumPy (0.25 GFLOPS in VM vs 575 GFLOPS on bare metal).
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 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.
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 depends on a country, if dual citizenship is allowed. Sometimes, it even depends on what the original citizenship is. Germany and France, for example, allow dual citizenship, meaning naturalization doesn't mean a loss of another citizenship.
Browserpod is great, been following it for a bit. Keep the good work up!
The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.
In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)
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 :-)
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.
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.
> Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.
Why not? .NET Blazor and others already do that. In my eyes this was the whole hype of WASM. Replace JS. I don't give a crap about running node/java/whatever in the browser, why would i want that? I can run those outside the browser. I mean sure if you have some use case for it that's fine and I'm glad WASM lets you do it but I really don't see why most devs would care about that. We use the browser for browsing the web and displaying our websites.
To me the browser is for displaying websites and I make websites but I loathe JS. So being able to make websites without JS is awesome.
Because people don't want to load 300MB for a simple website (and this is blocking the first render, not just loading in the background).
Not every language is a good source for targeting WASM, in the sense that you don't want to bring a whole standard library, custom runtime etc with you.
High-level languages may fare better if their GC is compatible with Wasm's GC model, though, as in that case the resulting binaries could be quite small. I believe Java-to-wasm binaries can be quite lean for that reason.
In c#'s case, it's probably mostly blazor's implementation, but it's not a good fit in this form for every kind of website (but very nice for e.g. an internal admin site and the like)
A modern blazor wasm app is nowhere near 300mb. There are techniques to reduce this size like tree shaking. There's no need to include lots of unused libraries.
Modern Blazor can do server side rendering for SEO/crawlers and fast first load similar to next.js, and seamlessly transition to client side rendering or interactive server side rendering afterwards.
Your info/opinion may be based on earlier iterations of Blazor.
That's still pretty bloated. That's enough size to fit an entire Android application a few years ago (before AndroidX) and simple Windows/Linux applications. I'll agree that it's justified if you're optimizing for runtime performance rather than first-load, which seems to be appropriate for your product, right?!
What is this 2 MB for? It would be interesting to hear about your WebAssembly performance story!
Regarding the website homepage itself: it weighs around 767.32 kB uncompressed in my testing, most of which is an unoptimized 200+kB JPEG file and some insanely large web fonts (which honestly are unnecessary, the website looks _pretty good_ and could load much faster without them).
Thats not too surprising as most web developers are JS developers. I'm sure JS will stay dominant at least a while longer, but in the .NET world Blazor is quite popular as far as web frameworks go. I imagine it will keep gaining popularity.
Any reason why browsercraft doesn't work in Firefox? Ended up opening it in Brave and had a lot of fun hahaha
It's pretty impressive how far along CheerpJ is right now. I kinda wish this existed about five or ten years ago with this level of performance, maybe it would've allowed some things in the web platform to pan out differently.
Tried it again in a private window and it worked indeed. The problem is probably caused by one of my extensions (not sure which, though, seems a bit unexpected to me). Thank you anyway, and sorry for bothering!
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.
