The web is an area that I don't dabble with often, but one aspect that has interested me for awhile is WebAssembly (wasm). First announced in 2015, WebAssembly stands as the spiritual successor to asm.js, a strict subset of JavaScript designed to make it go fast. While asm.js primarily aimed to speed up JavaScript, WebAssembly boasts a broader range of advantages.
A fast, efficient, and portable web format
Readable and debuggable
Secure
Doesn’t break the existing internet
However, if you have a background in JavaScript, you might wonder if JavaScript already addresses some of these goals, and it does. So, where does WebAssembly fit in? Let's explore JavaScript's origins and shortcomings, then see how WebAssembly stacks up.
According to JavaScript's creator, Brandon Eich, he created JavaScript in just 10 days for the Netscape Navigator browser back in 1995. This innovation allowed for the creation of dynamic web pages that could interact with users, a significant departure from the static information delivery of that era. You can see some of these early web pages using a search engine called Wilby which catalogs these websites from a time when they were developed…
primarily by hobbyists, academics, and computer savvy people
The circumstances surrounding JavaScript's birth mean that we are still grappling with the consequences of decisions made by one person, who never anticipated the language's ascent to becoming the Internet's lingua franca.
Fortunately, immense resources have been poured into making JavaScript a usable language over the years. Just in time (JIT) compilers for JavaScript represent state of the art innovations in complexity and efficiency. However, challenges persist in making JavaScript fast. JIT compilers need time to identify program hotspots before applying optimizations, leading to performance lags.
These optimizations rely on the functions called and the program's state as users interact with it. If the program state changes significantly, previously applied optimizations may no longer be relevant, or detrimental, causing a deoptimization (deopt) to occur. This leads to unpredictable performance, a hurdle when designing high performance web applications. WebAssembly programs are compiled ahead of time (AOT), eliminating the delay before achieving peak performance. This is because all of the optimizations are baked in when the program is compiled.
Another advantage lies in space efficiency. For large JavaScript programs, minifying code by removing unnecessary white space characters, line breaks, and shortening variable and function names is common practice. This is due to fact that when you visit a website all HTML, CSS, and JavaScript have to be downloaded once before it is cached, resulting in slower page loads. WebAssembly, being in a binary format, is inherently compact, facilitating faster page loads and reducing bandwidth costs for users in regions with slower internet speeds.
Portability is another aspect where WebAssembly shines. While web applications ultimately need JavaScript, contrary to popular belief, not every programmer knows JavaScript. WebAssembly provides an alternative compilation target, making previously inaccessible code available on the web without the need for rewriting or transpiling it to JavaScript. As of the time of writing over 20 different languages have mature, and production ready pipelines to produce WebAssembly.
Safety is another goal of WebAssembly. Drawing from over 60 years of hard won knowledge, WebAssembly packages each bit of code in a module executed within a sandboxed browser environment. This ensures isolation, and limits access to browser functionality through specific JavaScript APIs. Declaring accessible functions up front makes compiled code immutable, and due to its fixed size and index based memory management, memory safety issues like buffer overflows are not possible. Finally, unsafe pointer usage and undefined behavior are reduced by validation and bounds checking. While this places limitations on what the programmer might want to do, these guard rails ensure that code is not executed in the browser in unsafe contexts. This also protects the user of the websites.
The final focus of WebAssembly is compatibility. WebAssembly is designed to be compatible with existing web technologies and web standards. This means that WebAssembly is implemented in a way that should not disrupt or break the functioning of websites and web applications that are already in use. We all know what a pain it can be when that compatibility is broken. Thankfully, the web is one of the few places where multiple large companies have banded together to work on open standards, and we are better for it.
Does all this mean that WebAssembly is the silver bullet of the web? Well, yes and no. In terms of performance, WebAssembly has been a game changer for many. However, its effectiveness depends on the specific workload. Some tasks still require JavaScript calls, and if the WebAssembly code is short or simple, the overhead of data copying between JavaScript and WebAssembly can slow it down.
Then there is the fact the JavaScript JIT is like a rocket ship. Given the right circumstances the JIT can reach and even exceed the performance characteristics of an AOT compiled wasm program. This isn’t the end of the world, as the performance advantage of WebAssembly also includes predictable performance, which means that it is easier to gauge how well your app will perform overall. And that isn’t to say that you will never see a speed up when you convert parts of your code to WebAssembly.
Thankfully, WebAssembly offers more than just enhanced performance. It has even found success outside of the web as a portable format for native applications. Overall its future appears promising. But how do we write a WebAssembly program and use it? That’s what we will cover in next week’s article 😉. Stay tuned!
Call To Action 📣
If you made it this far thanks for reading! If you are new welcome! I like to talk about technology, niche programming languages, AI, and low-level coding. I’ve recently started a Twitter and would love for you to check it out. I also have a Mastodon if that is more your jam. If you liked the article, consider liking and subscribing. And if you haven’t why not check out another article of mine! A.M.D.G and Thank you for your valuable time.