BrowserPod: Universal in-browser sandbox powered by WASM (starting with Node.js)

BrowserPod: Universal in-browser sandbox powered by WASM (starting with Node.js)(labs.leaningtech.com)

7 points by apignotti 89 days ago | 3 comments

apignotti 89 days ago |

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.

InkCanon 89 days ago |

This will be an unfair question given the limitations of a browser sandboxed compiled to wasm, but do you have benchmarks comparing this to node hosted on the same machine?

apignotti 89 days ago | |

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]