Comment by TekMol
3 days ago
Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?
3 days ago
Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?
Mozilla tried that with asmjs. Turns out javascript has pretty half-assed semantics (notably around integer types), nobody wants to expand it to a useful compilation (asmjs was mostly an optimisation for hand-written code) target, and few want to compile to text, especially javascript.
Having a proper and well defined ISA is a lot more compelling.
Not only that, but it allows WASM-only compilers and runtimes with none of the JS baggage, and thus use of WASM outside of a browser context and with significantly lower resources requirements.
That makes it sound like WASM only exists because of the nerdy preferences of compiler makers, not because of any benefits to the users of applications?
If speed is fine, why would a user care if the application was compiled to a language with "half-assed semantics" in a text format?
I don't think speed is fine. Here's a write-up from Mozilla which talks about the performance benefits of WASM compared to asm.js: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
1 reply →
Simple: Javascript can focus on being a human-friendly programming language, while WASM can focus on being a compile target. If you've been around in the asm.js times, this conflict was a real concern.
That does not answer the question what the benefit of compiling to WASM rather than to JavaScript is.
If speed is fine, why would I care if a compiler compiled to a human-friendly language?
People can use software written in languages that need a compile target. For example you can write web applications that use libraries written in C/C++ that before would have needed to be hand ported to JS or compiled using technology like asmjs that was creaking at the seams. From the user perspective it enables more rich web applications.
From a performance perspective it's also a different target for web engines so has different opportunities for optimization. It's not clear to me we've reached the limit on that at the moment, or how much work browser developers are putting in to optimizing their WASM codepaths. The standard also includes support for things like SIMD which is not natively available in JS land which should provice a boost for suitable workloads and there is a lot coming through the proposal pipeline (https://github.com/WebAssembly/proposals) that will also let WASM diverge more from JS.
From a developer perspective allowing more languages than JS also has some productivity benefits. Both in using languages they are more familiar with and those better suited to certain domains. For example you can write math code in JS, in particular making use of TypedArrays to help things along but its much more straightforward in a language that supports more 'native' types.
Because Javascript would need to change a lot to better support compiled languages (for instance adding 'proper' separate integer and float types, but that's just the tip of the iceberg). This means extending the ECMAScript standard with features only few web developers care about, increased complexity in JS engines, and potential design-conflicts for new JS features between 'compile-friendly' vs 'human-friendly'. With WASM, the WASM peeps can focus on WASM and the JS peeps can focus on JS.
4 replies →
Speed is not fine. It's good enough for a lot of apps, but it doesn't get the job done for anything performance sensitive. An obvious issue is the lack of real machine number types, which makes anything numeric much slower than it could be.
Furthermore, JS semantics are limiting in other respects. E.g. there are people looking at tail calls and continuations in WebAssembly, which I can't see ever coming to JS.
1 reply →
We used to have asm.js for that. For various reasons wasm is a replacement for it. JS doesn't even have proper integer types, it is not a good target language.
asmjs had an i32 type by (ab)using JS semantics and a common jit optimisation: bitwise ops are defined for 32 bits two’s complement integer. So x|0 necessarily results in an i32.