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.
So, let's find out:
- how WebAssembly works and what makes it such a great fit for the web
1. The Rise of WebAssembly: The First Alternative to JS for Web Development
Just think about it:
“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).
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.
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:
- it's dynamically typed
- it's highly flexible
- it's delivered in human-readable code
- 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:
- you, the developer, write the code for your web app (in any programming language)
- next, you compile it into WebAssembly bytecode
- then, this code is run in the web browser, where it turns into native machine code and... executed.
Because its binaries are lighter than the textual JS files and, therefore, faster to decode...
4. 3 Performance-Intensive Use Cases for WebAssembly
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
- image recognition
WebAssembly's built as a target for writing in-browser software.
And now, let's get specific:
- porting a desktop app to the web: WebAssembly supports those scenarios that go beyond GUI delivered via HTML
- high-performance code to be written from the ground up: where, obviously, asm.js is not a suitable choice
- 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
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.
… the code before executing it in the browser.
- easy to write
- doesn't need to get compiled ahead (being a dynamically typed language)
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
- it has a binary format
- it's statically typed (it doesn't need to “guess” what types should be used)
- it performs its optimization work in advance while compiling the source code
- first turn text into a data structure (or i.e “abstract syntax tree” or AST)
- 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.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.
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
I'm certain that it won't: JS is still a convenient and fast choice for too many tasks.