WebAssembly: Integration, security, and scalability for the future of development

With the promise of near-native performance and the ability to use compiled languages like C, C++, or Rust, WebAssembly is positioned as a fundamental tool for tackling intensive tasks and improving the user experience on the web.

WebAssembly is a binary instruction set that runs on a lightweight virtual machine and is designed to work alongside JavaScript in modern browsers. Its goal is to allow code to run at near-native speeds, thanks to a much more efficient parsing and compilation process than traditionally interpreted languages on the web.

Furthermore, WASM is not limited to the browser environment. With the introduction of WASI (WebAssembly System Interface), the door is being opened to code execution on the server and embedded devices, offering portability and security through sandboxed execution environments.

Operation and technical characteristics

Binary format and virtual machine

• Compact binary format: WebAssembly code is distributed in a binary format (.wasm) that is much smaller and faster to load and execute compared to traditional source code.
• Lightweight Virtual Machine: WASM runs on a stack virtual machine that quickly translates instructions into machine code, enabling near-native performance.
• Textual representation: In addition to the binary format, there is a textual representation (.wat) that makes it easier to read and debug the code.

Integration with JavaScript

WASM is designed to work with JavaScript . While WASM handles the more computationally expensive operations, JavaScript remains responsible for DOM manipulation and user interaction. This allows you to combine the best of both worlds in a single application.

Security and portability

One of the main advantages of WebAssembly is that it runs within a sandbox, which prevents code from affecting the host system without the appropriate permissions.

Furthermore, being architecture independent , the same WASM module can run independently of the device.

Similar and alternative tools on the market

asm.js

Before the arrival of WebAssembly, there was asm.js, a subset of JavaScript that allowed browsers to run low-level code with improved performance. While asm.js was an important first step toward running “near-native” code on the web, WASM has quickly replaced it thanks to its more efficient binary format and its adoption as a W3C standard.

Other alternatives and runtimes

In the WASM ecosystem, several runtimes have been developed:

• WASI: A system interface that allows WASM modules to run outside of the browser, offering functionality similar to that of POSIX systems.
• Wasmer, Wasmtime, and WasmEdge: These are examples of runtimes that allow WASM code to run in non-web environments, making them easier to use in serverless applications, containers, and embedded systems.
• Comparison with traditional containers: Some initiatives, such as runwasi, allow WASM modules to be integrated into container environments (for example, with Docker), taking advantage of WASM's lightness and speed compared to container solutions that require a full operating system.

What does WebAssembly bring?

Near-native performance

WASM allows compiled code to run with performance very close to that achieved with a native solution. This is especially useful for applications that require processing large volumes of data, 3D graphics, or video games.

Multilingual and flexible

It's not programmed directly in WebAssembly, but rather written in high-level languages (such as C, C++, Rust, Go, and even .NET and Java) that are then compiled to WASM. This opens the door to more flexible development and allows you to leverage the existing ecosystem and tools for these languages.

Security

The fact that WASM code runs within a sandbox provides an additional level of security, as it restricts direct access to memory and operating system functionality without proper authorization. This significantly reduces the risk of vulnerabilities that could compromise user or system security.

Portability

Being architecture-independent, a compiled WASM module can run on different platforms and devices without code modification, facilitating portability and universal application deployment.

Use cases and practical applications

• Interactive web applications: Games, image editors, simulations, and other processing-intensive applications can benefit from the improved performance offered by WASM.
• Server-side execution: With WASI and runtimes like Wasmer, it's possible to run WASM-compiled applications on the server, enabling a new generation of serverless applications and ultra-lightweight containers.
• Integration into existing ecosystems: By working alongside JavaScript and other languages, WASM integrates easily into modern web projects. This approach allows you to take advantage of the best of both worlds without having to rewrite entire applications from scratch.

Programming Languages and WebAssembly

Supported and widely supported languages:

• C and C++: Thanks to tools like Emscripten and Clang, these languages have become the basis for many WASM projects. Their compiled and strongly typed nature allows for the generation of high-performance WASM modules.
• Rust: Rust is a favorite in the WASM ecosystem. Its focus on memory safety and LLVM compatibility make it easy to compile to WASM, resulting in secure applications with near-native performance.
• Go: Starting with version 1.11, Go includes experimental support for compiling to WASM. Although its ecosystem is still evolving, it allows Go applications to be ported to the browser with some limitations compared to C/C++ or Rust.
• AssemblyScript: A variant of TypeScript designed specifically to compile to WASM. It allows developers familiar with JavaScript and TypeScript to take advantage of compiled code without having to learn a completely new language.
• C# (with Blazor): Through Blazor WebAssembly, it is possible to run applications written in C# directly in the browser, combining the robustness of the language with the advantages of the WASM environment.

Languages with limited support or requiring additional workarounds:

• Interpreted or dynamically typed languages (e.g., Python, Ruby, PHP): These languages don't compile natively to WASM. However, there are projects like Pyodide (for Python) or Ruby WASM, which allow some of their functionality to be ported to the browser, albeit with some compromises in terms of performance and binary size.
• Java: Although Java is a widely used language, its virtual machine model and garbage collection make it less suitable for direct compilation to WASM. There are initiatives such as TeaVM or CheerpJ that attempt to translate Java code to WASM, but integration still presents challenges.

Evidence

In order to test the functionality of WASM, we have created a small test bench in which the same code is executed in three different ways:

• C compiled with gcc: Using various configurations.
• C compiled to WASM using Emscripten: To take advantage of compilation to an optimized binary format.
• Pure JavaScript: Implementing logic directly in the web language.

The test bench incorporates representative functions that are commonly used to evaluate performance

• Mandelbrot: Calculates the Mandelbrot fractal by iterating a mathematical function on each pixel to determine its membership in the set, putting intensive floating-point calculations to the test.
• N-Body: Simulates gravitational interactions between multiple bodies, evaluating efficiency in numerical calculations and dynamic state updates.
• Spectral Norm: Estimates the dominant eigenvalue of a matrix by iterated matrix multiplications and transposes, measuring intensive multiplication and floating-point arithmetic operations.
• Binary Trees: Recursively builds a binary tree up to a given depth, calculates a checksum by traversing it, and frees the memory, evaluating memory management and efficiency in recursive functions.