A tale about not-so-much-dead JavaScript
Tags: javascript, webassembly, web, new
Published: 2018-11-26 18:56:28

---
title: A tale about not-so-much-dead JavaScript
published: true
canonical_url: https://areknawo.com/the-tale-about-not-so-much-dead-javascript
cover_image: https://images.unsplash.com/photo-1518732714860-b62714ce0c59?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=a7e2177b9f785d57391f6f82941ba8a5&auto=format&fit=crop&w=1350&q=80
description: Is WASM indeed so good?
tags: javascript, wasm, web, new
---
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. 

![via Giphy.com](https://media.giphy.com/media/lRnUWhmllPI9a/giphy.gif)

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?



![via Giphy.com](https://media.giphy.com/media/xHMIDAy1qkzNS/giphy.gif)

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](https://github.com/kripken/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](https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format). So let’s check the performance of Emscripten-compiled C vs JS!

![via Giphy.com](https://media.giphy.com/media/3aGZA6WLI9Jde/giphy.gif)

Or rather to keep things simple, clean and as good as they are - just go to [this page](https://takahirox.github.io/WebAssembly-benchmark/) 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](https://alexcrichton.github.io/rust-wasm-benchmark/index.html) 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. 😁