Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

I remain mystified about the value of running JS inside a wasm VM. I see why people want to go there, because they want one tool to rule them all, but I don't get the actual value add. WASM hasn't been built for this. Not yet. You'll be running the garbage collector, compiler, bytecode interpreter fully in an emulated environment. There's bound to be overhead. For no reason. (And remember overhead isn't just slow processing of customer jobs -- it's energy consumption as well.)

There are already multiple runtimes that can run both WebAssembly and Javascript/TypeScript. The JS runtimes themselves. V8 does a great job of running both wasm and JS. And a custom V8 (or JavaScriptCore or whatever) embedding with appropriate sandboxing can be put together without a huge amount of work.

Seems like the better peg for the hole in question if people want support for JS and WASM in a hosted environment.

View on HN

Disclaimer: I am a maintainer at WasmEdge.

One of the benefits of running JS in Wasm (specifically the QuickJS approach) is that you can create JS APIs in Rust. That allows you to move a lot of compute intensive operations into Rust while still giving your developers a clean and nice JS API. WasmEdge does this with its JS Tensorflow API:

https://wasmedge.org/book/en/write_wasm/js/tensorflow.html

In fact, we are using Rust to support the entire Node.JS API in WasmEdge. :)

Not to denigrate your work, it's good what you're working on... but I can create JS APIs in Rust with native V8 bindings, too: https://github.com/denoland/rusty_v8/blob/main/examples/proc...

After working on a couple codebases that used wasmtime and wasmer heavily, I think if I were to start from scratch I'd just use V8 as my WASM runtime.

(And the model I would follow would be to containerize the V8 runtime piece inside its own cgroup, with resource budgets and permission constraints. cgroups accounting beats the limited and inefficient accounting one gets from the various WASM runtime opcode based accounting systems.)

Personally, I believe v8 is and always will be primarily focused on the browser use case. It’s support for wasi, container tooling will always take a back seat compared with priorities in the browser.

Today, there are a large set of Rust apps that can run in WasmEdge, wasmtime, Fermyon spin, wasmCloud etc, but would not run on v8’s embedded Wasm engine …

However, I do agree that v8 excels in JavaScript.

The design of WASI and the component model are layered, though: you could start with V8 and build a runtime with full WASI etc. support.

In fact, Node.js and Deno have both done exactly that, a V8 core with layered APIs on top including WASI.

My interest comes from wanting to see more performant options for per-request isolation in JavaScript applications. There have been bugs on popular web services returning information for the wrong user caused by inadvertently using global or module level variables.

Isolates are one option but I believe startup time for isolates with a snapshot is actually slower than Firecracker's snapshot restore.

Developing with Firecracker is somewhat annoying since it requires support for nested virtualization (doesn't work on Mac M1 or AWS, though does on GCP and GitHub Codespaces. The M2 has hardware support so development on Mac should work eventually.)

The various WebAssembly runtimes have really put a lot of work into getting fast snapshot restore with Wasmtime 1.0 doing so in microseconds. I'd love to be able to run server rendering in such an environment.

You could take a look at GraalJS. It supports its own form of isolates and they can be created very fast, because an isolate setup is basically mmapping the pre-calculated heap into another area of memory and starting up another thread. I never measured it but it shouldn't be particularly slow. It also means you can mix languages.

Reply on news.ycombinator.com