An Introduction to WebAssembly: Origins, Performance Benefits, and Practical Example

On December 5, 2019 WebAssembly joined the Web standards family after HTML, CSS and JavaScript, sparking great excitement in the JavaScript community about its speed and potential impact on web development.

W3C project lead Philippe Le Hégaret noted that WebAssembly expands the range of applications that can run on an open web platform and is especially important for machine‑learning and AI workloads that need high performance without compromising user security.

What is WebAssembly? According to MDN, it is a low‑level, portable binary format designed for efficient execution and compact representation on modern processors, including browsers. It is not a programming language but a compilation target that allows code written in languages other than JavaScript to run in the browser with near‑native performance.

Key characteristics:

WebAssembly is a file format, not a language, that runs in browsers.

It enables using non‑JavaScript languages for web development.

Its compact binary format delivers performance close to native code.

Background JavaScript was created in 1995 for simple page interactions and lacked performance for complex applications. Over the years JIT compilation improved speed, leading to ecosystems like Node.js and Electron, but JavaScript’s dynamic typing and flexible syntax caused scalability and performance problems. Alternative solutions such as TypeScript, Dart, and asm.js each addressed parts of the issue but remained incompatible, prompting the need for a unified standard—WebAssembly.

WebAssembly was first released in 2015, demonstrated with a Unity game, and became an official W3C standard on December 5, 2019, marking a major shift in how browsers execute code.

Why is WebAssembly faster? The performance advantage is evident across several execution stages:

Fetch stage: WASM files are binary and typically smaller than equivalent JavaScript bundles, reducing download time.

Parse stage: Browsers decode WASM directly to bytecode; JavaScript must first be parsed into an abstract syntax tree and then compiled to bytecode.

Compile & optimize stage: Strongly‑typed languages can be statically compiled and heavily optimized before shipping, so the browser does little work at runtime. JavaScript’s dynamic typing forces the JIT to perform type‑based optimizations on the fly.

De‑optimization stage: JIT may discard optimized code when assumptions fail, incurring extra cost. WASM’s static types eliminate this re‑optimization step.

Execution stage: WASM instructions are closer to machine code, leading to faster execution; JavaScript must go through additional abstraction layers.

Garbage‑collection stage: JavaScript’s automatic GC adds overhead, while current WASM implementations require manual memory management, avoiding GC pauses.

Overall, WebAssembly can improve execution speed by 10 % to 800 % depending on the workload.

Will WebAssembly replace JavaScript? No. WebAssembly is designed to complement JavaScript, not replace it. JavaScript remains essential for DOM manipulation, dynamic typing, and its vast ecosystem, while WebAssembly provides a high‑performance path for code written in other languages.

Small practical example

1. Module generation – Install Emscripten and compile C code to a .wasm file:

git clone https://github.com/juj/emsdk.git
cd emsdk
# On Linux or macOS
./emsdk install --build=Release sdk-incoming-64bit binaryen-master-64bit
./emsdk activate --global --build=Release sdk-incoming-64bit binaryen-master-64bit
# If you encounter errors, install the latest version instead
./emsdk install latest
./emsdk activate latest

Activate the environment:

source ./emsdk_env.sh

Compile a C source file to WebAssembly:

emcc math.c -Os -s WASM=1 -s SIDE_MODULE=1 -o math.wasm

Or generate a full HTML/JS wrapper:

emcc hello.c -s WASM=1 -o hello.html

The above command produces hello.wasm , hello.js (glue code), and hello.html for loading the module in a browser.

2. Module loading – Fetch the .wasm file and instantiate it:

# JavaScript calling WebAssembly example
// Assume the compiled module is available as "math.wasm"
fetch('math.wasm')
  .then(response => response.arrayBuffer())
  .then(bytes => WebAssembly.instantiate(bytes))
  .then(results => {
    const { add, square } = results.instance.exports;
    console.log('add(2,3)=', add(2,3));
    console.log('square(4)=', square(4));
  });

This demonstrates that functions defined in C (e.g., add and square ) can be called from JavaScript after the module is instantiated.

References

WebAssembly basic introduction – https://juejin.cn/post/6970606101943451684#heading-1

MDN WebAssembly documentation – https://developer.mozilla.org/zh-CN/docs/WebAssembly

Compiling C/C++ to WebAssembly – https://developer.mozilla.org/zh-CN/docs/WebAssembly/C_to_wasm

Getting started with WebAssembly – https://juejin.cn/post/6844904190905417741#heading-2

Visual guide to WebAssembly – https://www.jianshu.com/p/bff8aa23fe4d

Frontend guide to WebAssembly – https://juejin.cn/post/6844904192541196295#heading-40