Comment by flohofwoe

3 days ago

Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower than WASM in most situations.

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?

      2 replies →

  • 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?

      8 replies →

  • 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.