Non-stop advancements in web technologies have reshaped web applications in amazing ways. From simple frames with images, links, and decorated text, web apps have evolved into complex computer programs with client and server code. Modern web apps are powered by rich client-side processing and for this, there is one ubiquitous tool (JavaScript), which also gets pushed into places where it is not the right tool for the job. That developers are in a love-hate relationship with JavaScript is indeed true! To give credit where credit is due, JavaScript has matured a lot over the years. Advanced optimization and compilation techniques have led to fast web experiences. Yet, browsers that run on JavaScript fall short of delivering the near-native performance and rich experience demanded by video games, computer-aided designs, and scientific visualization.   Which is why WebAssembly, the new open standard, is such great news. 

What Is WebAssembly?

WebAssembly (WASM for short) is a new low-level binary format for the web. It is the second code format of programming language to be understood by web browsers after JavaScript, introduced in the ’90s. That said, WebAssembly is a not really a new programming language. Instead, it defines a new compiler target for the web, which helps to create modules from diverse programming languages and run them in a web browser. It means that code written in languages such as C/C++ can be run on the web at near-native speed, with client apps running on the web.    WebAssembly-the future of Web is here   WebAssembly defines a .wasm binary executable format that can be downloaded and run in the browser (like a .js file) while taking advantage of the speed and low-level hardware capabilities of machine code. This binary format is executed by a virtual machine that works alongside the JavaScript VM, sharing resources (for example, memory) and executing on the same thread. This way .wasm is designed to execute in a sandboxed environment and it adheres to the same security constraints as JavaScript does in the browser. WebAssembly does not mean the end of JavaScript. Instead, it is going to rev up the processing-heavy or low-level tasks. The virtual machine in the web platform can load and run both .wasm and .js code, allowing both codes to access each other. Codes compiled to WASM can be exported and called as normal JavaScript functions with the help of WebAssembly Javascript API. In contrast, WebAssembly’s code can also import and synchronously call normal JavaScript functions.

WebAssembly: Opening a Door of Opportunities

Performance

Delivering and executing WASM files in pre-compiled low-level format is how WebAssembly achieves one of its primary goals of being really, really fast. Since WASM is more compact than JavaScript, fetching WebAssembly takes less time. Also, decoding WebAssembly takes less time than parsing JavaScript.  Mozilla engineer, Lin Clark has claimed that in the new version of Firefox Beta, calls between JavaScript and WebAssembly are “faster than non-inlined JS to JS function calls.” Also, Firefox proved that with the implementation of streaming compilation, the browser is able to compile the code as it is still being downloaded. Further, resource utilization, in particular on mobile and other resource-constrained platforms is reduced. More performance with minimum battery usage!

Reusability and Language Diversity

Code reusability will be another opportunity opened up by WebAssembly. Back-end developers can even bring their existing code to the web without rewriting in JavaScript. There is such a rich collection of open source intensive graphics libraries written in native programme languages like C/C++. Sooner or later, the developer community will use them in modern web apps with WebAssembly. Imagine using JavaScript to access powerful libraries from outside the web for things like machine learning and physical simulation! The list of languages that currently compile to or have their VMs in WebAssembly is rapidly evolving. This includes mainstream programming languages like Rust, C/C++, C#/.Net, Java, Python, Elixir, Go, Ruby, and so on. As WebAssembly evolves to support managed objects and better DOM+JavaScript bindings, the list of supported languages will continue to grow.

Security

Security in WebAssembly is a topic that comes up often. WebAssembly’s stated security goals include:
  1. Protecting users from buggy or malicious modules
  2. Providing developers with useful mitigations
WebAssembly mitigates the security concerns by providing a memory-safe, sandboxed execution environment to run the WASM modules. Though WASM codes can access raw memory bytes, they are limited to a region of memory allowed by browsers. This is achieved by designing WebAssembly’s memory as an ArrayBuffer in the same memory pool of JavaScript engine, like a JavaScript object. Also, this way the objects that leak memory from WASM modules will be tracked by JavaScript garbage collector itself. Also, since WASM modules download and run within the context of the DOM, HTTP properties like Same-Origin Policy (SOP), Content Security Policy (CSP) filtering are also assured.

New Experiments

The rise of WebAssembly is paving the way for new experiments in the industry. Checked out the new AutoCAD web app yet? With no install required, you can start creating drawings within the browser. Same is the case with Adobe Lightroom. By switching to WebAssembly, Figma—a comprehensive online design tool—improved their load time by more than 3x regardless of document size. The following are some of the interesting experiments with WASM :
  • Blazor - Microsoft's experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly
  • Yew - Rust framework for making client web apps
  • Pyodide - The Python scientific stack running in the browser
  • ewasm - Ethereum-flavored WebAssembly
  • WebSight - facial recognition algorithm running in the browser

The Future Is Awesome with WASM

It is really a breakthrough when native, portable C/C++ code is able to run in the browser without third-party plugins. With WASM, more effort will be spent on the actual products rather than scaling Javascript to fit the requirement. WebAssembly will not disturb the current web ecosystem but will continue to evolve alongside other web technologies. Future roadmap of WebAssembly defined by WASM community looks promising. Support for Threads, Garbage collection, SIMD, and Bulk memory operations is in progress. Yes, the future is bright! Since JavaScript has complete control over how WebAssembly code is downloaded, compiled, and run, JavaScript developers could even think of WebAssembly as just a JavaScript feature for efficiently generating high-performance functions. In the near future, you’ll be able to download and import WASM modules like any other ECMAScript module using <script type='module'> and simply call their functions from JavaScript. With every major browser now supporting WebAssembly, it’s time for developers to start thinking about writing WebAssembly-oriented client-side apps for the web.  
No Image