4 ms·

asm.js is faster than WASM, and it can do everything that JS can do.

cogman10 5mo ago
Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome. I don't think Chrome ever did an asm.js specific optimization.
- nightpool 5mo ago
  It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-and-compiled-to-webassembly https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...
mbrock 5mo ago
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
chilmers 5mo ago
How can a subset of JS do "everything" that JS can do?
- bogdan 5mo ago
  All you need is a lambda
ramon156 5mo ago
WASM wont improve if no one adopts it. Its a chicken and egg issue
- flohofwoe 5mo ago
  WASM has been adopted and it has improved massively since 2017 though.
  - pjmlp 5mo ago
    Yes, but GC is still useless for languages with interior pointers, some features require gimmicks with server configuration, and for most languages we aren't any way closer to -march=wasm and that's all. We still need to download half Internet for emscripten, plus whatever tools are being used on top. Although it is somewhat simpler for those that build on top of binaren.
    - titzer 5mo ago
      Wasm evolution happens in fits and starts. There's a lot of nested chicken-and-egg problems. We first started on Wasm GC less than two years after MVP, and then we didn't have any language targeting it, so we had to bootstrap it. Now, Java, Dart, Kotlin, and Scala all target Wasm GC (and Virgil too :-)). The interior pointer is on people's radar. The next big feature coming is stack switching. It works best with unboxed continuations, which necessitates a fat pointer representation in the engine. Once the engine supports fat pointers, then interior pointers will be an easier sell. It might take several years to get there, but Wasm evolves slowly and deliberately, and IMO hasn't made any massive fatal design errors yet.
flohofwoe 5mo ago
Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;) It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements. Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).

Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome. I don't think Chrome ever did an asm.js specific optimization.

nightpool 5mo ago
It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-and-compiled-to-webassembly https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...

mbrock 5mo ago

Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.

chilmers 5mo ago

How can a subset of JS do "everything" that JS can do?

bogdan 5mo ago
All you need is a lambda

ramon156 5mo ago

WASM wont improve if no one adopts it. Its a chicken and egg issue

flohofwoe 5mo ago
WASM has been adopted and it has improved massively since 2017 though.
- pjmlp 5mo ago
  Yes, but GC is still useless for languages with interior pointers, some features require gimmicks with server configuration, and for most languages we aren't any way closer to -march=wasm and that's all. We still need to download half Internet for emscripten, plus whatever tools are being used on top. Although it is somewhat simpler for those that build on top of binaren.
  - titzer 5mo ago
    Wasm evolution happens in fits and starts. There's a lot of nested chicken-and-egg problems. We first started on Wasm GC less than two years after MVP, and then we didn't have any language targeting it, so we had to bootstrap it. Now, Java, Dart, Kotlin, and Scala all target Wasm GC (and Virgil too :-)). The interior pointer is on people's radar. The next big feature coming is stack switching. It works best with unboxed continuations, which necessitates a fat pointer representation in the engine. Once the engine supports fat pointers, then interior pointers will be an easier sell. It might take several years to get there, but Wasm evolves slowly and deliberately, and IMO hasn't made any massive fatal design errors yet.

flohofwoe 5mo ago

Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;) It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements. Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).