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. 😁
Top comments (10)
Whilst your stats are correct your assumptions are wrong.
Wasm is slow with strings because the MVP doesn't support strings. Once it does the performance bench marks will change in favour of wasm.
But you are also wrong if you think the death of JavaScript will come as a result of wasms performance.
JavaScript is the new cobol because developers want to program in a single language. As soon as wasm supports a wide variety of languages the long slow death of JavaScript will begin.
JavaScript is more like the new Visual Basic For Applications, you have to use it because is the only option.
When other options appear, some developers will stay with js, some others will innovate applying more robust technology to the web.
Nothing that have not happenned before.
I don't think that is the case. Currently a lot of people enjoy writing JavaScript, which wasn't always the case.
Of course people enjoy it, they actually enjoy it too much.
Well we start to use dart maybe
You miss the plot. Wasm isn't just about super fast division by zero its about introducing actual programming languages to web development and offer an exit to that dreaded bloat of inconsistency called js. If this takes a performance hit, me personally can't care less...
Indeed you're right. But (at least for me) WASM is advertised as new format for better speed and efficiency. I think that support for LLVM-compiled languages is just a side-effect. If course, I can be wrong but it's my opinion.
While everything you said, I think it comes as a disappointment to many. WASM was hyped up to be (wrongly in hindsight) to be the way the JavaScript monopoly was going to be (finally) toppled. I love JS. But I am by no means the only developer, and we also shouldn't expect one language to be able to do everything. I thought WASM binaries were going to (in a way) almost be like bringing
.jars back to the Web, but interoperable with the JS Module system. As you have discussed in the article, this is not the case. WASM is meant to simply offload intensive math heavy operations to a lower level format.It's going to be for both, it's just that they are not there yet, it's a mvp after all.
If you want to see what's coming, check this article by Lin Clark hacks.mozilla.org/2018/10/webassem...
No matter how proficient I am in JS, I still wish it would disappear :)
WASM is a miracle, my only fear regarding it is that the order of new features will be Garbage Collection Primitives then Threads then DOM access, which means that languages familiar to serverside frontend developers like Ruby and Python will flood the scene.
I hope it will be DOM access then Threads (all before Garbage Collection Primitives), so that Rust UIs have time to create a great ecosystem.