4 ms·

You can use javascript as a single cross platform compile target. What's the difference?

• merlindru 9mo ago
  WASM works with any language and can be much faster than javascript
  • vbezhenar 9mo ago
    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!
• hnb2137 9mo ago
  WASM allows you to run some parts of the application a bit faster. ;)
• lxgr 9mo ago
  Javascript comes with mandatory garbage collection. I suppose you could compile any language to an allocation-free semantic subset of Javascript, but it's probably going to be even less pretty than transpiling to Javascript already is.
  • creata 9mo ago
    > it's probably going to be even less pretty than transpiling to Javascript already is. I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?
    • lxgr 9mo ago
      “Pretty clear” is good, “guaranteed by language specifications” is better. Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?
• yencabulator 9mo ago
  WASM, and asm.js before it, roughly exist because Javascript is such a bad compile target.