[jillesvangurp]

V8 is not the only implementation of WASM. Safari and Mozilla also provide implementations. Though Apple is probably dragging their feet here, Mozilla has been quite active with WASM development, supporting it in their browser, making sure Rust (which they created) can use it, and doing lots of developer support and outreach for WASM.

The word legacy is a bit biased here. From where I'm sitting, Javascript as implemented by browsers is increasingly the legacy language. Even most javascript webapps are actually transpiled to it. It's a compilation target more often than something people write natively. And as such it is used because until WASM came along, it was the only viable way to run anything on the web.

WASM provides developers a better compilation target that can ultimately support just about anything and already is used to run a wide variety of languages that have the ability to target it (in various stages of completion and maturity). Most mainstream languages at this point basically.

And of course WASM is not limited to the web. It's also showing up in edge computing solutions pushed by e.g. Digital Ocean, Cloudflare, etc. Many node.js applications can leverage WASM as well. It's probably used in a fair amount of desktop applications using electron, like VS Code for example. People are even experimenting with embedding wasm in operating system kernels and firmware even. It turns out that performance and sandboxing are very desirable properties in lots of places.

So, it's a general purpose runtime intended to sandbox and efficiently run just about any code. Including javascript interpreters ultimately. My prediction is that the latter will happen before the end of this decade and that Javascript will lose its status as a special language that is exclusively supported in browsers in addition to WASM. It will allow browser creators to focus on optimizing and securing WASM instead of WASM + Javascript.

[micrio]

I wholeheartedly agree with this. V8 is definitely incredible impressive and keeps improving. However Micrio uses a lot of low level Matrix4 maths, which is substantially faster in Wasm.

The second point is also great; having the base Micrio engine as a Wasm module now really makes me itch to use it in different environments. Perhaps I can use it in a serverside rendering flow, or even on an embedded device with a touch screen? Perhaps even as a native mobile app component in the future.

Also from the developer point of view it offers improvements over JS. Type/memory wise it gives more control. It's great to be able to use (u)int, f32 and f64 types, whereas with JS this is impossible from a coding perspective. The buffers passed from Wasm to WebGL are all Float32Arrays and are casted from f64's to f32's manually; giving me that 100% control instead of the black box that V8 gives.

[titzer]

Just for the record, the Wasm implementation in Chrome is a subsystem of V8. It's integrated into the main codebase and shares a lot of runtime services with the JavaScript support, primarily the optimizing compiler tier. So improvements to the (backend) of the optimizing compiler in V8 benefit both JavaScript and Wasm. There is also a baseline JIT compiler which is specifically built solely for faster Wasm startup and not used by JS.

The team (my former team) that maintains Wasm is a subteam of V8 and they all work together. This is unlike (P)NaCl which was both a separate team and a separate subsystem within Chrome. All of the former NaCl people work on Wasm now, primarily tooling and standards.

[maxgraey]

That's true. But wasm also required some extra codegen and optimizations for i64 types for example (also simd and atomics). In addition, wasm will have more specific CFG optimizations for WebAssembly. For example https://bugs.chromium.org/p/v8/issues/detail?id=11298