WebAssembly vs. JavaScript

“Will WebAssembly replace JavaScript by 20XX?” This is one of those “sensationalizing” questions of the moment, right? But still: if we were to run a WebAssembly vs. JavaScript performance comparison, which one would be the winner?

And would we have the same winner for different implementations? 

We're all looking forward to the future of web development now that WebAssembly has come around to “tempt” us with near-native performance to the browser. 

Yet, most of us still write code in JavaScript, despite the predictions of its “imminent extinction”. And there still are use cases where JS outperforms WASM.

So, let's find out:

• Exactly when JavaScript performs better that WebAssembly
• How WebAssembly works and what makes it such a great fit for the web
• Whether WASM is, indeed, faster than JavaScript and when precisely 
  

1. The Rise of WebAssembly: The First Alternative to JS for Web Development

Just think about it:

We've been having JavaScript as the one and only programming language to be used natively in web browsers and then... WebAssembly stepped in.

“But what is WebAssembly more precisely?” Is it a really an assembly language, like its name suggests? Well, here's a hopefully clear enough definition for you to ponder on:

WASM is a new type of code — with a small-sized fast binary format — for modern browsers. A “compile target,” if you wish.

One that you get to use for compiling any programming language (JS here included).

And NO:

It is not an assembly language, it's not built for a specific machine.

And no, you don't write code in WebAssembly; you use it to compile any given language.

What it does is compile higher level languages and then run those web apps in the browser a lot faster than JavaScript (due to its lightweight, low-level binary format, remember?).

2. WebAssembly vs JavaScript: Essential Differences

Now that we've seen what WebAssembly is and what it is not, let me briefly outline the key features that set our 2 “contestants” apart:

JavaScript:

• it's dynamically typed
• it's highly flexible
• it's delivered in human-readable code 

WebAssembly:

• it's just fast(er)
• it's delivered via a small-sized binary format
• it's strongly typed 
  
  

3. How Does WebAssembly Work? What's Behind Its “Near-Native Performance”?

“Why is WebAssembly faster? How does it work?”

Here's WASM in action:

1. you, the developer, write the code for your web app (in any programming language)
2. next, you compile it into WebAssembly bytecode
3. then, this code is run in the web browser, where it turns into native machine code and... executed.  

And it gets loaded, parsed, and executed way faster compared to JavaScript.

Why?

Because its binaries are lighter than the textual JS files and, therefore, faster to decode...

4. 3 Performance-Intensive Use Cases for WebAssembly

Before I run an “enlightening” WebAssembly vs JavaScript performance comparison, let me highlight the use cases where WASM “shines supreme” as a web performance “booster.

First of all, when you say “common uses cases for WebAssembly”, think about all those performance-critical cases:

• video editing
• 3D rendering
• video games
• music streaming
• encryption
• image recognition 

WebAssembly's built as a target for writing in-browser software.

In short: think of all those use cases where JavaScript would usually struggle to reach the needed level of performance.

And now, let's get specific:

1. Porting a desktop app to the web: WebAssembly supports those scenarios that go beyond GUI delivered via HTML.
2. High-performance code already existing in a targetable language: deploy it as a WebAssembly module; here, you could keep the less performance-critical elements in JavaScript.
3. High-performance code to be written from the ground up: where, obviously, asm.js is not a suitable choice.

In short:

• With WebAssembly, there's only one step to complete — the compilation step —  for running your app in any browser; portability is one of its main strengths.
• If top performance is critical for your web app, you might want to consider WebAssembly as an alternative to JavaScript.
  

5. WebAssembly vs. JavaScript: Performance Comparison

Now that we've settled that WebAssembly is usually faster than JS, let's:

• find out when precisely. When does WASM outperform JS?
• dig some more into the load of features that enable WebAssembly to perform better
• discover all those use cases where JS can't be “dethroned” 

5.1. WebAssembly's Binaries Are Faster to Download and to Execute

“Why?” Because they're smaller than JS's textual files.

By comparison, JavaScript would need to:

• parse
• compile
• optimize 

… the code before executing it in the browser.

Although it's:

• easy to write
• doesn't need to get compiled ahead (being a dynamically typed language) 

… JavaScript still needs more time to do all the needed work before executing the code.

5.2. With WebAssembly, Memory Gets Managed Manually

In other words: there's no garbage pile-up to impact performance.

5.3. WebAssembly Reduces the Initial Load Time

Any WebAssembly vs JavaScript performance analysis would point out that WASM comes with some significant time-parsing improvements.

Here's why it decodes much faster than JavaScript:

1. it has a binary format
2. it's statically typed (it doesn't need to “guess” what types should be used)
3. it performs its optimization work in advance while compiling the source code 

By comparison, JavaScript would need to:

1. first turn text into a data structure (or i.e “abstract syntax tree” or AST)
2. then, turn that AST into binary format 

Just think of the JS-heavy web apps striving to parse all that data in due time.

WebAssembly is proven to score 3 times better at load time. 

5.4. JavaScript Performs Better on Smaller Array Sizes

In a WebAssembly vs JavaScript “duel” WASM would always perform better on larger array sizes, powering extremely fast web applications.

5.5. WebAssmebly Files Load Faster Once in Cache

The moment they get stored in the cache of the browser, WASM files are easier to load, compared to JS's source code.

5.6. JavaScript often performs better during execution

Once fully optimized, WebAssembly is slower when executing code in the browser.

And this is partly (some) browsers' “fault”: 

On Microsoft edge, for instance, WebAssembly executes terribly slowly.

5.7. WebAssembly Doesn't Really “Outshine” JS in Terms of Run-Time Performance 

6. What Next? Will WebAssembly Become More Than Just a Web-Based Solution?

Well, that's the goal, at least: 

To go beyond its common use in web browsers.

To upgrade it from a web-based solution to the go-to option for:

• desktop apps
• mobile apps
• other execution environments 

Moreover, one of the “forecasts” is that we'll no longer talk about a “WebAssembly vs JavaScript” rivalry in the future, but about a cohabitation of the 2:

You'll still be able to write your code in JavaScript all while leveraging the speed that WebAsssembly brings to the table: improved frameworks and libraries.

“Will WebAssembly replace JavaScript by 20XX?” 

I'm certain that it won't: JS is still a convenient and fast choice for too many tasks.

Yet, we will witness a successful collaboration of the 2.