WebAssembly has been gaining popularity in recent times. It's fast, it's "hip" and my God, C/C++ and Rust developers seem to mention it a lot these days. There are several articles already written for Wasm (as I'll keep calling WebAssembly in this article). Go here for my article on using WebAssembly, Go and React. There is also a Rust port here. The Rust port is up and running at this URL.
Java is a language that needs no introduction. The JVM is simply a virtual machine that takes in Java bytecode and then spit out the machine code of the CPU the code is running on. That way, you can write any language that is supported by the JVM (e.g Scala) and run it on any CPU/platform. This forms the basis of Java's Write Once, Run Anywehere. Enter Wasm.
Wasm basically is a format that allows you compile code you've written in various languages on any hardware/platform in a safe environment.
So how does Wasm differ from the JVM?
- Speed. Wasm runs at near native speed (even in the browser).
- Security. WebAssembly lets you run code you don't trust. It runs in its own sandbox.
- In the frontend, there are JS bindings from your host language. This means you can write your app in a language like Rust. You can manipulate the DOM directly, compile to Wasm and have JS bindings generated for you.
- WebAssembly can be loaded "lazily" loaded. What does this mean? You can actually run the WASM code before its been fully dowloaded. The browser can run the WASM as its being downloaded using the
WebAssembly.instantiateStreaming()function provided in JavaScript.
Personally, my biggest takeaway from the differences between JVM and WebAssembly is that Wasm is platform-independent and provides near native speed for whatever architecture you're running on all with support for many languages, guaranteed security and the fact that you can stream the Wasm binary in the browser. Another takeaway is the fact that it supports a lot of languages — Rust, Go, AssemblyScript all support Wasm. I think its pretty obvious that Wasm is not just another JVM. WebAssembly is WebAssembly.
Top comments (3)
Native speed? JavaScript is significantly faster than WASM at certain tasks. Especially things related to image/video processing. takahirox.github.io/WebAssembly-be...
On the video grayscale example in my version of Google Chrome, JavaScript is 4-5x faster than WASM.
Javascript can run at native speed as well, if the engine optimizes it. On the other hand, I'm not sure what's in your wasm binary but I'm certain there's quite a bit of emscripten stuff in there.
You'd be better of using a language that directly compiles to wasm (maybe assemblyScript?) instead of this toolchain which gives you half a C std lib as well.
Add to that the aforementioned problems with calling from JS into wasm and back and the overall very concise code which the JS engine probably optimizes instantly, and it makes total sense that the overhead outweighs the benefit.
I wouldn't use wasm to replace 5 lines of JS just because it's possible. I think JS is still seen as an interpreted language, when performance in many cases is near native.
You can use wasm in cases where you want SIMD, for example, or when you want absolute consistency across all browsers in terms of execution time.
This is the quickest benchmark. I bet what is slowing WASM is that it is repeatedly called from JS. I wonder what the result would be if the main loop was in WASM, ran with wasmtime