“Is WebAssembly going to kill JavaScript?”
This question has been on the lips of many a developer ever since WebAssembly (WASM) began to look like it might actually become a reality. While many have speculated that WebAssembly will mean the end of JavaScript, those involved in creating it deny any such intent.
Within the official FAQ on webassembly.org this question is addressed head-on, with the answer “WebAssembly is designed to be a complement to, not replacement of, JavaScript.” Experts like Brendon Eich, former CEO of Mozilla, have predicted a future where WebAssembly and JavaScript co-evolve.
The Future Of Web Development
While it may not kill JavaScript, WebAssembly is definitely going to change the face of front-end web development. It is still too early to see all of the ways this change will play out, we're far enough along to make some strong predictions about the future of web development.
Enabled by WebAssembly, the future of web development is:
- Linguistically Diverse
- Extremely Fast
- Parallel
WebAssembly Enables Linguistic Diversity
WebAssembly will dramatically diversify the languages available for building front-end applications and tools, enabling developers to build applications in any language they might choose.
There is already an impressive list of implementations, with compilation to WASM supported in over 20 different languages including these major ones:
This diversification in languages will enable a proliferation of web frameworks for developers of these languages, allowing them to develop applications directly in their languages of choice. Some early examples are Yew for Rust and Humble in Go (Humble currently targets GopherJS as ‘compile-to-javascript’ but I expect will soon support a WASM backend)
WebAssembly Enables Extremely Fast Web Applications
WASM will allow for some pretty amazing performance boosts. We’ve seen Firefox demonstrate that in contrast to JavaScript, WASM can be compiled and executed as fast as it comes over the wire.
This parse-time improvement cuts one of the biggest bottlenecks with modern JavaScript-heavy web applications: Time to initial load. In a set of benchmarks published by Figma, a browser-based design tool, comparisons between implementations using asm.js vs WebAssembly showed a 3X improvement in load time enabled by WebAssembly.
For large documents, this meant going from over 10 seconds to browser-interactive to less than 5. That is a tremendous improvement.
Run-time performance improvements have been less dramatic, but still in evidence. Benchmarks of intense graphical operations comparing WASM to D3 showed 30% improvements in large projects.
Even if large amounts of web applications remain in JavaScript, libraries and frameworks built with WebAssembly could enable developers to take advantage of these speed boosts while continuing to develop primarily with JavaScript.
There is already evidence of frameworks investigating this, with Ember.js investigating a WASM implementation for it's Glimmer VM.
I think this trend will continue to accelerate. Imagine JavaScript frameworks shipping “fast-boot” starter sequences compiled to WASM that then progressively enhance with JavaScript and load your JavaScript-based application, letting complex web applications boot up and reach interactivity as fast as simple static websites do today.
WebAssembly Will Enable Parallelism
This one is admittedly a bit more speculative, as it is not fully realized in today's WebAssembly.
Since the shift towards multicore processors began in around 2005, it has become increasingly the case that to achieve greater performance, software needs to become parallel.
In a recent keynote presentation about the future of the browser, Lin Clark of Mozilla highlighted that the one part of the web experience that browsers cannot "invisibly" parallelise is the actual application code. JavaScript was designed as a single-threaded language, and while newer tools like Web Workers enable some amounts of parallelism in JavaScript, they are still challenging to use and work only at a relatively course-grained level.
Languages like Rust and Go were designed for parallelism from the beginning, making it far easier to write parallel applications. WebAssembly's threads feature is still only a proposal, but once it becomes a reality we will quickly be able to see web applications taking advantage of fine-grained parallelism.
Most of this will once again occur at the level of frameworks and libraries. I don't envision your average application developer using WebAssembly threads in their application, but there is tremendous potential just in the framework side. React's new Fiber Architecture is already looking at slicing and dicing the behind-the-scenes rendering work into chunks that can be passed around and delayed.
Imagine a WebAssembly-powered Fiber that splits rendering work across all available cores, then simply hands it up to the JavaScript application as needed.
The Future Of Web Development Is Bright
I don't know about you, but I’m pretty excited about the possibilities enabled by WebAssembly, even if I never touch it directly and keep coding in JavaScript. As the tooling continues to advance, more browsers take advantage of the performance capabilities as demonstrated by Mozilla, and frameworks and libraries increasingly take advantage of the possibilities, the future of web development is very bright!
P.S. - If you're interested in these types of topics, you should probably follow me on Twitter or join my mailing list. I send out a weekly newsletter called the ‘Friday Frontend’. Every Friday I send out 15 links to the best articles, tutorials, and announcements in CSS/SCSS, JavaScript, and assorted other awesome Front-end News. Sign up here: https://zendev.com/friday-frontend.html
Top comments (2)
I bet for web assembly.
as a C# developer, I prefer to use the same language to make the front-end. Microsoft is working on Blazor and it looks pretty good but unfortunately, we have to wait a lit bit because it's an still experimental project.
Yeah, I was just on a podcast with a WebAssembly expert and he was saying that of the current languages supported, really only C, C++, and Rust are truly production quality at this time.
But the rest are growing very rapidly! Exciting times