The tale about not-so-much-dead JavaScript
If you’re into this JS ecosystem (and given that your reading this post - I think you are) you must / should have heard of something like WebAssembly or WASM for short. It’s said to be new format/ language/standard for languages like C to compile to and therefore run on web natively. The biggest selling factor of this new standard is its speed. It’s said to be faster than JavaScript X number of times.
This speed factor is especially important with modern performance-hungry web-apps & games. So, it’s not really unexpected that this encourages many controversial discussion, presentations & titles. One of which, that has received much more attention than others is “WebAssembly and the death of JavaScript”. Oh, it really struck me! Does this mean that all JS developers will suddenly be replaced by the C-writers and only the ones knowing other lower-languages will survive this change? - Just kidding! Of course not!
JavaScript is still with us
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:
Fibonacci
Result
(average [ms])
JavaScript
711.6200
WebAssembly
325.7500
JavaScript/WebAssembly
2.1846
The results are pretty neat and as expected - 2x improvement over JS!
Multiply double
Result
(average [ms])
JavaScript
2909.2600
WebAssembly
592.4600
JavaScript/WebAssembly
4.9105
Yeah - 4x improvement! Now - let’s try something different…
Image convolute
Result
(average [ms])
JavaScript
43.3000
WebAssembly
84.4600
JavaScript/WebAssembly
0.5127
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…
JavaScript (especially in V8) has been optimized to the level where it’s really, really fast. WASM provides us with something new and fresh. If you need to execute CPU-heavy calculations on the browser (for whatever reason) then go for it. Just remember that initialization of WASM from JS site is quite costly as is communication between them, so you’ll need to have the level of performance gain from WASM justify its other performance costs. Anyway, that’s it… for now. 😀
If you need
Custom Web App
I can help you get your next project, from idea to reality.