Show HN: CheerpX – x86 Node.js/python3/Ruby REPL in browser via WebAssembly JIT
repl.leaningtech.com
repl.leaningtech.com
What are the tradeoffs of running virtualized x86 in the browser via WASM relative to a traditional VM (e.g. Virtual Box) or VM-like container runtime like Firecracker [0]? I would expect to get improved portability (it's a webpage) at the cost of some performance and security.
The ShowHN link is for the REPL demo, the actual homepage for the CheerpX x86 to WASM virtualizer is here [1]
Minor bug: when you load a new REPL, the loading log fills the screen and continues below the fold without auto-scolling to keep up with new output. You have to manually scroll past a list of all the component modules to see the new REPL.
The scrolling behavior you mentioned is actually a feature, we want to give people time to read the first message before filling up the console.
> The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit.
I understand that the security model is more like a webpage than a local binary. What I don't understand is:
(1) what is the relative difficulty of escaping a full, local VM vs a local browser sandbox vs microVM container? That is, if you want to run an untrusted x86 binary locally, is CheerpX + browser sandbox really as safe as VirtualBox or firecracker? I suspect there's a speed/security tradeoff happening somewhere.
(2) how complete is the set of operating system APIs available to an x86 running in WASM via CheerpX vs running that same application locally? That is, what local functionality might I sacrifice to use the browser?
(3) what is the nature and magnitude of the performance hit? Obviously you have to load the binary over the network in this demo, but locally-hosted resources should be fine.
(2) We are implementing syscalls and devices as they are needed for the various use cases we are considering. In general even if something is not natively supported in the browser it can still be virtualized to various degrees. In particular CheerpX provides a virtualized FileSystem that does not map to your local files. The same would apply for the virtual disks in traditional VMs though.
(3) We plan to release benchmarks soon, but the level of performance is very promising. Consider that we have been using the Flash plugin as our main benchmark which is very demanding. For the REPL use case the limiting factor right now is I/O performance, but we are already working on this and we thing we will achieve much better results very soon. In general, all aspects of CheerpX performance will improve, we are really not done yet.
Running this in the browser makes for a ridiculously easy setup. You can get up and running very quickly by just giving someone a URL (probably with a pre-unpacked image). Setting up a VM on the other hand, can be daunting if you don't already have the infrastructure setup. This might be a benefit of running this WASM VM vs a local VM.
Second, you get the security benefit of running the code on your local computer as opposed to a remote VM. This may not be a big issue, but for some circumstances, it could be.
Third, by running it locally as opposed to on a remote VM, might be more interactive, in that you don't have the round-trip time client -> server -> client. But this depends on how performant the WASM VM is.
This isn't something you do for performance. The WASM VM seems "fast enough", but this isn't something that will be faster than many cloud-based VMs. For me, the major benefits would be setup/maintenance and security.
Personally find this to be a pretty cool project, but I'm not sure of where I'd use it outside of teaching... but it's quite impressive.
For the scrolling -- I found that once I scrolled to the bottom once, it auto-scrolled. But I was confused when I unpacked Python by this too.
Teaching seems like a great use case. Maybe they'll use similar licensing as their Cheerp compiler [0] and provide a basic community tier. You could give students a foolproof (?) way to run a controlled set of applications locally without the confusion of setting up a local VM host or the expense of hosting virtual machines for the class. That assumes your students have decent computers.
Actually, this would be a nice way to sideload real applications onto Chromebooks. Certainly more secure/accessible/maintainable than unlocking all the default protections and side-loading Linux first.
The upside is obvious, it's idiot-proof and zero setup.
[0]: https://github.com/WebAssembly/design/blob/master/FutureFeat...
Or said in other way: is the node binary compiled with v8 in interpreted mode, or does it support the v8 JIT?
[0]: https://phet.colorado.edu [1]: https://www.leaningtech.com/pages/cheerpj.html
(Not affiliated, just a very grateful student.)
CheerpX is more advanced in a way that you can run arbitrary binaries. I’m interested to learn more about the performance tradeoffs and compare benchmarks. Out of curiosity, what’s your take on libraries that require compilation step, e.g. Pandas/NumPy?
What I particularly like about WASM is you don’t need to install anything on your machine. It’s as simple as clicking a link, and you have a secure environment that works right out of the box.
On a more personal note, I was excited about Pyodide, and about a month ago I began developing a visual notebook. Its initial purpose was to create a Python playground, which can render ad-hoc visualizations into a browser to share them with my friends. Zero setup, just type some Python code in the browser and instantly see results, render charts, etc. [1]
Overall, I love the momentum that erases the setup step for traditional tools, ultimately bringing joy to programming. I believe it would be a great way to introduce programming concepts in an educational setting.
Obviously compiling directly to Wasm will provide the best level of performance, but it also take effort for every single application/library you want to port.
Try the "primes.js" example in the nodejs repl with CheerpX, then run it on jslinux and see for yourself.
On my machine it runs about 600 times slower in jslinux than in CheerpX.