Is is wasm and not WASM. Source: http://webassembly.org/

Thanks for the link, I would probably have tried this had I stumbled on it before! I did an ask HN prior to writing this article but did not get that much answers: https://news.ycombinator.com/item?id=14483383

This AssemblyScript thing looks like some nice idea for being able to work with a single language while still being able to compile some computationally-heavy but otherwise small modules down to WASM and using them later from JS/TS as an external module.

I'm curious how this approach looks from an optimization point of view? I guess emscripten/LLVM can do more optimization than this the AssemblyScript/binaryen toolchain, and when one puts already the effort in for using WASM the goal should probably be to have as much optimization as possible.

Hard to be sure without measurements, but emscripten uses LLVM's optimizer and the binaryen optimizer, and AssemblyScript can benefit from the latter. So the question is how much the LLVM optimizer could help this type of code.

For example, the LLVM optimizer can do smart things with aliasing and assumptions about undefined behavior in C code, but for a language like AssemblyScript those might not be relevant anyhow.

But currently the binaryen optimizer is still missing some passes like GVN, so until we add those, that might be noticeable when doing comparisons here.

How about https://github.com/WebAssembly/binaryen ?

It's a lower level tool that's used by most things, including the linked project.

Knowing that LLVM has a wasm backend ; could someone explain what role binaryen plays here?