JS with its vast ecosystem isn’t going anywhere anytime soon. Why’s that? Well, firstly WASM is (for now) an MVP which stands for Minimum Viable Product. So although it is indeed usable cross-browser standard, there’s still many changes & upgrades to come before it’s declared fully-completed (or something similar). Secondly, WASM is designed to cooperate with JS (at least for now that’s how it’s meant to work) and lastly - yes - the ecosystem 😎; So JS isn’t going anywhere - everybody (JS developers) happy?
Yeah, great! Now, that we have this misunderstanding out of the way...
Let’s talk performance
Yup - the performance, but first a fact. WASM is designed to be a compilation target/format for lower-level languages like C or Rust. Rust already provides this functionality kind-of built-in. For C (and C++ of course) it’s provided with help of the Emscripten project which also allows this functionality for other LLVM based compiled languages (believe me or not - there’s a lot of them). Of course, if you don’t like either of this solutions and want to take benefit of WASM “performance” (more on that later) you can use it’s own really-low-level format. So let’s check the performance of Emscripten-compiled C vs JS!
Or rather to keep things simple, clean and as good as they are - just go to this page which contains a proper comparison between JS and WASM and is, of course, open source. Because I’ve been there & I’ve done that, below are some results:
The results are pretty neat and as expected - 2x improvement over JS!
Yeah - 4x improvement! Now - let’s try something different...
Yeah - 1/2x improvement! Wait - what? That 50% decrement when compared to JS! Why’s that? Well, ladies & gentlemen let me introduce you to the problem (if you haven’t deduced it from tests’ code already) - the C char type. It’s apparently the main problem. WASM is crazy fast when working with numbers, but it isn’t so great when dealing with type compelling to JS strings. This trend continues in other tests that use string-related types and also in similar benchmarks written in Rust. Is it a problem? - I don’t think so. Assembly (as the name implies) is generally better for calculation-related operation and that’s fine. Because the advertised usage of WASM in performance-demanding games is therefore true (games do a lot of different calculations). It’s debatable if representing strings and characters in WASM with arrays of ASCII characters would improve our performance if written in WASM text representation by hand, because it would require conversion from JS string to ASCII numbers, more memory usage and would limit string by inability to use Unicode (don’t know how Emscripten handles C chars).
Bottom line then...