An Overview of WebAssembly

Creation, Development, and Future

Zen Garden in the browser by Epic

What if you could run any software application at peak performance on nothing but a webpage? Thanks to the speed & efficiency of WebAssembly, a newly developed compilation target for the web, locally-hosted software applications may soon be a thing of the past. WebAssembly was introduced five years ago in a historic contribution between the four major browsers: Google Chrome, Mozilla Firefox, Apple’s Safari, and Microsoft’s Edge. Two years later it was compatible with 91% of web browsers, and by 2019 it became the fourth World Wide Web Consortium (W3C) standard along HTML, CSS, and JavaScript [1]. Webassembly, or wasm, has produced significant hype within the web development industry. But for those outside, some basic questions remain unanswered: what is WebAssembly and why is it suddenly so important? This blog post will answer these questions from the ground up.

  • Why is WebAssembly important?
  • What is WebAssembly?
  • Adoption and development in the industry
  • The future of WebAssembly

Why is WebAssembly important?

To understand the need for WebAssembly, we must first understand two things: (1) why Javascript (JS) is the standard compilation target for web browsers, and (2) why it is not fit for that role. Back in the day, webpages were just a bunch of static documents and simple forms. Then Javascript was introduced, a high-level scripting language which allowed for dynamic behavior on web pages. Anytime something is dynamic on a webpage (a pop-up notification, a share button, a live news feed, etc.), Javascript is responsible for that feature. Netscape and Sun Microsystems developed JS in 1993 for small scripts that would add single feature interaction on a web page. They did not foresee the rapid expansion of their language to new and more complex use cases: Eric Lippert, one of the initial contributors to JS, said “The notion that there would someday be [JS] frameworks with hundreds of thousands of lines was not even close to being on our radar.” [2].

As browsers were vying for market share in the browser wars of 2004 [3], the main focus was around client side scripting. Browser creators needed to optimize their script parsers, which in turn meant that they needed a web language to optimize them for. There were other better suited web languages such as Java, Flash and Shockwave, but for the simple reason that Netscape was the first to submit their application to the W3C, they were not web standards like Javascript was. That meant that these alternatives usually required plug-ins. So when eye-catching headlines raised security and availability concerns around plug-ins, web standards became increasingly important in the industry. [4] With no other languages to take the spot, Javascript became the de-facto web language to optimize if you wanted to make a competitive web browser.

Image Source

Ubiquitous use of the language led to clever but exhaustive methods to optimize it. The way that Javascript is interpreted in modern browsers is both a huge engineering feat and a testament to its shortcomings. Initially, Javascript interpreters were built to execute simple scripts, making it increasingly slow. As javascript became the de-facto web scripting software, just-in-time compilation and an elaborate set of optimization methods were developed.

Nowadays, Javascript is delivered as text over HTTP. It is then parsed into an Abstract Syntax Tree (AST) used to generate bytecode which is processed by the interpreter. Then, based on many assumptions (such as what type a variable is), the code is further compiled and optimized. But given the scripting and untyped nature of javascript, the assumptions made to optimize it can be violated at any point. When that happens, the optimized code fails and the interpreter has to bail back to the less optimized version, then repeat the JIT compilation with new assumptions. This process can be repeated through several layers, with browsers such as Safari Nitro using up to three tiers of assumption-based optimizations. In ideal cases, this process takes Javascript’s runtime down to near-native performance, minus the inherent startup cost to getting to that point. However, in the majority of cases, Javascript’s performance ends up being subpar to Ahead of Time (AOT) compiled languages. This inefficiency presents a problem which leads well into the next paragraph.

Image Source

To account for these requirements, a new strict subset of JavaScript called asm.js was introduced. Asm.js only included the parts that could be best optimized. Asm.js quickly became a compilation target for statically-typed languages with manual memory management (such as C). Given that it was a strict subset of JS, it could be run in any javascript environment while being much more optimizable due to its decreased flexibility. Asm.js had huge measurable performance improvements and gained a lot of popularity as a web compilation target; however, it showed the fundamental limits that came with javascript JIT compilation. Despite all the innovations, the web was fundamentally limited by the inefficient way in which it was receiving code. It was clear that we needed a way to deliver code as AOT optimized and in a compact manner. With the empirical evidence available from asm.js, and the lessons learned in its creation, the web community was — for the first time — able to come to a consensus on the need for a new low-level language. This led to the innovation of WebAssembly.

What is WebAssembly?

WebAssembly, unlike JavaScript, is intended to be a low-level compilation target rather than a programming language. This allows WebAssembly to be a fast, compact, and portable compilation target for a variety of languages. The most popular at the moment are C++ and Rust, but there are now over 40 languages that reported support for Wasm as a compilation target. Wasm has syntax and semantics, but they are there for the sake of explainability and last-resort debugging, the underlying language is a binary code format. [5]

WebAssembly did not just come in, it more so kicked-in the door and came in shouting. The four major Web Browsers rarely cooperate with each other. This time it was different, on the day it was announced, WebAssembly engineers showed off Unity’s flagship game Angry Bots already running in Mozilla Firefox, Google Chrome, and Microsoft Edge, with Apple’s Safari also pledging their support to wams’s development. [6] With such big guns behind the technology, the design of the MVP was declared finished only two years later in March 2017 and by September, Safari 11 was publicly released with support for WebAssembly. In 2019, WebAssembly became the fourth standard by the W3C consortium alongside HTML, CSS, and Javascript. By July 2020, 91.1% of installed browsers supported WebAssembly. [6] And there were good reasons for the huge support to its development.

WebAssembly offers many upgrades over the previous alternatives, with some of key ones focused around speed, portability, and compactness. [4] At the core of WebAssembly’s design is speed. Low level code such as C, C++, or Rust is usually compiled and optimized ahead of time (AOT). Features of these languages such as type casting and function inlining allow them to be fully optimized during their first compilation. This avoids the JIT compilation overhead that Javascript implies, bringing down “time to interactive” or startup speed significantly. WebAssembly is also very portable; previous solutions for very low level code were tied to specific architectures, creating a need for different compilers for different operating systems. But web browsers span all types of devices and operating systems, thus web-assembly can serve as the “write once, run everywhere” that has been a goal of many decades of portability development. [7] Finally, WebAssembly is very compact. When transmitting information over the web, every bit matters so files should be as compact as possible. WebAssembly’s bytecode is designed to be very small to download, so code on the web transmitted as Javascript text is much less compact than WebAssembly’s binary format even in its gzipped state. It is often around 10–20% smaller(comparing gzipped sizes) than gzipped Javascript.

Image Source

Adoption and Development of WebAssembly

WebAssembly is an ambitious goal; creating a unified compilation target for the web is no easy task. The web is fragmented into many popular browsers, which makes this a challenge from both a technical perspective and from an adoption perspective. But fortunately, there is a collective wealth of knowledge and experience among the individuals working on wasm. After asm.js was rendered obsolete by webasm, Mozzila placed some of the original engineers on the asm.js project such as Alon Zakai and Lin Clark behind webassembly to support its development. Google was working on Native Client (NaCl), its own binary format for the web based on LLVM, those same engineers such as Ben Smith, and Derek Schuff are also now closely involved in the development of WebAssembly. The list goes on: the project is contributed to by Microsoft’s Limin Zhu and Michael Holman, Apple’s Raphael Isemann, Nvidia devsnek and countless other notable WebAssembly Contributors from the most prominent technology companies.

Back in the startup atmosphere there has also been support to build the tools and frameworks that are going to be needed to make webassembly seamless to use. Two of the biggest players are Wasmer and Fastly which are creating open source tools to execute WebAssembly files universally. Wasmer’s CEO Syrus Akbary believes that webAssembly and the browser will eventually become the universal computing platform.[8][9] Another player in the startup market is Second State, which is building WebAssembly execution engines, frameworks, and developer toolchains for the cloud. Their CEO Michael Yuan is an expert and recognized author on enterprise mobile computing. [8]

There are also many companies developing products powered by WebAssembly. Adobe has already introduced Acrobat on the web “Powered by WebAssembly”. With Webassembly’s native-like performance, plus the browser’s mature file transfer and plugin infrastructure, and the web’s seamless connection to the growing cloud, the rest of the adobe suite is bound to follow the same path. [10] Another example is seen by Autodesk’s release of webassembly based AutoCAD, allowing you to “AutoCAD anywhere” though a browser, a significant example given the high computation nature of the application. The development process and compute upsides of webAssembly are well illustrated by Ebay VP Senthil Padmanabhan on this Blog Post. On it he details how they used WebAssembly at Ebay to port their barcode scanner feature to the web, something that was not previously possible with JavaScript. Finally, you can check out this demo of Zen Garden in the browser by Epic (Only available in Firefox, but see a video below) to get a visual example of the performance capabilities of webAssembly.

WebAssembly Demo: Zen Garden (Epic)

The future of WebAssembly

WebAssembly has clearly come very far since its inception five years ago, but it’s not close to maturity. WebAssembly’s development is divided into five chronological phases, it recently completed its phase 0 or (Minimum Viable Product) MVP, and phase 1 and 2 are currently in development. [10] These will bring many features that will put wasm up to par with its alternatives.

One of the key proposals in development is garbage collection. Most modern languages use garbage collection (GC) to optimize memory management by clearing variables when they are no longer used. WebAssembly does not have a native garbage collector, or any memory management tools, and simply provides you with a ‘chunk’ of memory. Thus languages that need garbage collection need to compile a GC to wasm and ship it as part of the code transfer, which is computationally expensive. A native garbage collector has already been proposed and will be released sometime during the current phase of development–phase 1.[10]

Another current shortcoming is that wasm lacks direct access to the Document Object Model (DOM). Due to the simplicity of WebAssembly’s MVP, modules cannot yet access the DOM or WebAPIs directly. If you want to write a wasm module that manipulates the DOM you have to use Javascript APIs as ‘glue’ code. Rust already has a feature, wasm-bindgen, that allows for a more direct connection, that feature closely aligns with the phase 1 proposal to make this a native feature of webasm. [10] When this feature is added it will allow WebAssembly to communicate directly with the DOM, making JavaScript less important and further cementing WebAssembly’s position as the superior language for the web.


Webassembly is only in its infancy, but it’s already changing the industry. It’s important to stop and ponder on how it will affect web browsers, operating systems, and technology as a whole. As a starter, once there are better frameworks that compile seamlessly into webAssembly it will allow most compiled languages to compile to webAssembly, bringing back the possibility of code that you “write once, run anywhere”. This means that many apps, such as AutoCad, Adobes suite, and countless others which currently run on the desktop, will start migrating to the browser. We predict that farther into the future, native apps on android and other devices will die out in favor of progresssive web apps, especially with the rise of downloadable web pages. This will mean a rise in popularity of operating systems that, like chromeOS, use the web browser as its principal user interface. A couple more years from that and we will see the main OS providers like MacOS and Microsoft drop support for non-web applications, resulting in the browser acting as a unified application host across all mainstream consumer desktops. Finally, in our wildest predictions, we see WebAssembly completely pushing out native apps from operating systems and crowning the web browser as the operating system of the 21st century.

The Startup

Get smarter at building your thing. Join The Startup’s +793K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Alfredo Andere Valencia

Written by

EECS@UCBerkeley, SWE@Google, President@MLatB

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Alfredo Andere Valencia

Written by

EECS@UCBerkeley, SWE@Google, President@MLatB

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store