Knowledge about WebAssembly

What is WebAssembly?

WebAssembly, or WASM for short, literally consists of Web and Assembly, which can be understood as web/browser assembly, indicating the origin of the technology, which is assembly code that runs inside a browser. However, as the technology has iterated, WebAssembly has long since moved beyond its original design vision.

1. WebAssembly is not exactly assembly language, but rather an assembly bytecode-like instruction format standard maintained by the W3C’s WASM Working Group and the ByteCode Alliance. It is more like LLVM-IR, an intermediate language that is somewhat higher in abstraction than assembly language, and instead of writing WASM manually, developers choose to write and compile to WASM using other high-level languages (e.g. C, C++, Rust, Go, Python, etc.).
2. WebAssembly is no longer limited to running on top of the browser. As the WASM ecosystem continues to expand, various WASM-compatible runtimes have emerged that allow WASM to run in a sandbox environment outside of the browser, on both the client and server sides.

Why do we need WebAssembly?

Why do we need WASM when JavaScript can do the job in the browser or on the server side like Node.js?

The main reason for this is the performance of JavaScript. Essentially, JavaScript does not have static variable types, so the compilation optimizations made by the execution engine (JIT Compiler) are likely to fail. For example, if a function is defined in JavaScript code and contains a local variable, it is given an Array value at first, and then it is given an Object value on the next line of code, and the JIT compiler’s optimizations fail. The design flaws in JavaScript itself have turned the history of the programming language into a history of filling holes, and even though the development ecosystem around JavaScript is getting bigger and bigger, it is still a bit overwhelmed by large and complex projects.

Of course, developers have made various attempts to solve the performance problem of JavaScript, besides WASM, there is also an optimized subset of JavaScript: asm.js. Like WASM, asm.js is also a compilation target and has better readability than WebAssembly, but developers have to force the use of static types, which makes it not acceptable to all developers. Secondly, acm.js code still needs to go through the time-consuming process of “get-parse-compile-optimize”, while WASM does not need to go through these steps, as WASM is already native bytecode, and WASM is also statically typed, which makes most of the optimizations done during its initial compilation. This makes WebAssembly much faster than asm.js and native JavaScript.

Features of WebAssembly

WASM has several key design features that make it an aura of its own from birth.

• Portability - As mentioned earlier, WASM was originally designed for the Web, and almost all major browsers now offer support for WASM; in addition, WASM was also designed for low-level virtual machine architectures, and its instructions are translated into machine code by the physical machine alone, which means that WASM binaries can eventually run on various combinations of operating systems and chip architectures, whether Linux, MacOS, Windows, and other operating systems, or in ARM, X86, Power, and other chip architectures, and even mobile devices and Internet of Things (IoT) devices.
• Lightweight and efficient - The aforementioned static typing and compilation optimizations of WASM make it several times more performant compared to JavaScript and asm.js. This performance advantage also allows WASM to bring compounding benefits in runtime environments outside of the browser, and WASM is particularly well suited for Serverless application scenarios with high requirements for cold starts. Currently, while Serverless technologies can help manage the underlying computing facilities and allocate distribution resources, they still require new computing resources in a cold-start scenario, which brings additional costs. The lightweight and efficient nature of the WASM module makes cold start-up much less costly.
• Security - WASM runs in a sandbox environment that values capability-driven security where access to host system resources (e.g. file systems, hardware, etc.) is restricted unless explicit capability access is granted, so WASM reduces the attack surface and enables secure restricted execution of untrusted code in a multi-tenant environment. This security model allows developers to extend existing applications with plugins and user submitted code.
• Multi-language support - WASM is a compiled target format that is programming language agnostic, and developers have the flexibility to build WASM in multiple languages (e.g. C, C++, Rust, Go, etc.) as long as the language supports it.Currently, almost all of the top 20 programming languages in RedMonk are adding WASM support.

WebAssembly usage scenarios

1. Application migration to the browser side

   Before WASM, JavaScript was the primary programming language on the browser side, but the performance issues inherent in JavaScript prevented many large applications from running directly on the browser side. Today, with support for WASM in browsers and front-end frameworks, it is easier for developers to compile and execute other popular languages such as C, C++, Rust, and Go in the browser. Languages designed from WASM have even emerged, including AssemblyScript, Grain, Motoko, and others. Some companies are also starting to use WASM to migrate previous desktop applications to the browser side, such as Google Earth, Photoshop, AutoCAD, etc., as well as some mature video and game projects such as Unity WebGL, Unreal Engine, etc. As the WASM system interface WASI continues to be refined, the interaction between WASM modules and the operating system will be standardized and WASM programs will access system resources in a consistent manner.

2. Server side

   • Serverless - Service-less platforms rely heavily on optimized cold start technologies, so the lightweight and efficient nature of WASM makes the WASM runtime, such as WASMEdge, ideally suited to power the next generation of serverless platforms, which continues to penetrate the edge computing space.

   • Data Analytics and Machine Learning at the Edge - WASM portability and efficiency features make it suitable for applications that support machine learning scenarios at the edge. WASM machine learning modules can be deployed on edge devices with widely varying form factors and computing power, with data computed close to the source of data generation, whether running at the edge of the network or at the edge of the device.

   • Service Mesh - Leveraging the flexibility of WASM allows the ability to scale a service mesh (such as Istio) down from the control plane to the data plane (such as extending Envoy with WASM), where the WASM extension itself runs in a sandbox environment and does not affect the operation of data plane programs and resource access is restricted.

   • Platform Extensions - Thanks to WASM’s multilingual support and sandbox isolation technology, WASM can provide a scalable model and the ability to execute third-party (trusted or untrusted) code on top of existing applications.

WASM Ecosystem Landscape.

The convergence of WebAssembly and container technology

It is believed that as the technology iterates, the WASM runtime will become a “first-class citizen” in the cloud-native space, as the WASI continues to improve and the OCI Registry supports the WASM program module, WASM may take application management to a new level. Just like the spread from virtual machine technology to containers, WASM may replace some of the functionality of container technology. With WASM’s cold-start optimization, WASM containers will be well suited for short-lived serverless and edge workloads; however, traditional container workloads will be dedicated to long-running services (such as caching servers) that require a lot of I/O or need access to network sockets.

Further, it is too early to tell how a mainstream container orchestration engine like Kubernetes will integrate with WASM, but we have seen the emergence of projects such as Krustlet, runwasi, Containerd WASM Shims, and crun’s WASM Handler, all of which aim to elevate WASM to first-class citizenship in container environments as the new runtime for Kubernetes.