3 ms·

You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript. So basically wasm is some optimisation. That's fine but it's not s

You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript. So basically wasm is some optimisation. That's fine but it's not something groundbreaking. And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.

IshKebab 9mo ago
> some optimisation That's underselling it a bit IMO. There's a reason asm.js was abandoned.
- gf000 9mo ago
  Both undersell and oversell. There are still cases where vanilla JS will be faster. And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
- creata 9mo ago
  Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.
  - IshKebab 9mo ago
    > I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then. Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
    - gr4vityWall 9mo ago
      After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
      - IshKebab 9mo ago
        Whatever it would have ended up like it would have been a big hack so I'm glad everyone agreed to go with a proper solution for once!

IshKebab 9mo ago

> some optimisation That's underselling it a bit IMO. There's a reason asm.js was abandoned.

gf000 9mo ago
Both undersell and oversell. There are still cases where vanilla JS will be faster. And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
creata 9mo ago
Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.
- IshKebab 9mo ago
  > I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then. Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
  - gr4vityWall 9mo ago
    After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
    - IshKebab 9mo ago
      Whatever it would have ended up like it would have been a big hack so I'm glad everyone agreed to go with a proper solution for once!