WebAssembly is not used to replace JavaScript, but to make up for its computing performance shortcomings. It is a binary format close to machine code, run in a browser, and is suitable for high-density computing scenarios. 1. Image/video processing: such as filters, compression, FFmpeg compiled into WASM; 2. Audio analysis: real-time spectrum, noise reduction; 3. Game engine: Unity, Unreal runs C logic with WASM; 4. Cryptography: blockchain signature algorithm; 5. Large-scale application porting: such as Figma and Photoshop some modules. There are three ways to introduce WASM: 1. Use ready-made WASM packages, such as ffmpeg.js, to install and call through npm, without writing C code; 2. Compile C/Rust to WASM by yourself, use Emscripten or wasm-pack toolchain, and JS loads and calls export functions through fetch; 3. Use AssemblyScript, TypeScript subset, syntax friendly, and directly imports and uses it in JS after compiling it into WASM. When communicating with WASM and JS, please note: objects cannot be shared, numerical parameters are efficient, strings and arrays need to be read and written manually through linear memory to avoid frequent copying. Debugging WASM can be done through Chrome DevTools, which supports breakpoints and call stacks. AssemblyScript supports source maps. It is recommended to enable DEMANGLE_SUPPORT. Summary: WASM is a performance accelerator of JS. When JS computing performance is insufficient, WASM can be introduced to solve bottlenecks, and it can benefit without learning system languages from scratch.

If you are a JavaScript developer and are used to using JS to process front-end logic, call APIs, and operate DOM, then WebAssembly (WASM for short) may make you feel "Is this thing too far away from me?" - in fact, it is not. WASM is quietly changing the boundaries of front-end performance, and as a JS developer, you don’t need to learn from scratch, and you can get started quickly and benefit from it.

Simply put: WebAssembly is not used to replace JavaScript, but to make up for its shortcomings - computing performance.

What is WebAssembly? What does it have to do with JavaScript?

WebAssembly is a low-level, close to machine code binary format that the browser can run at near-native speeds. You can think of it as a "C/C/Rust program in the browser".

But it cannot operate the DOM directly, nor can it call the browser API. These things still have to rely on JavaScript.

So the real working mode is:

• JavaScript is responsible for interaction, UI, and network requests
• WASM is responsible for high-density calculations (such as image processing, audio and video encoding, game logic, cryptography)

They collaborate by calling functions with each other , just like JS calls an npm package, except that this "package" is compiled into WASM.

When should I use WASM? Typical usage scenarios

Not all projects require WASM, but it is particularly useful in these scenarios:

• Image/video processing : filter, compression, format conversion (such as FFmpeg compiled to WASM)
• Audio analysis : real-time spectrum, noise reduction algorithm
• Game Engine : Unity, Unreal Use WASM to run C game logic
• Cryptography and cryptographic wallets : such as signature algorithms in blockchain applications
• Large-scale application porting : For example, some computing modules of Photoshop Express and Figma

For example: You use JS to make an image blur filter, and the page is stuttering when processing large images. If you switch to WASM to implement the convolution algorithm, the speed may be increased by 5 to 10 times.

How to introduce WASM in JS project? Three common ways

1. Use ready-made WASM packages (recommended for beginners)

Many common libraries already provide WASM versions, you only need to use them like the npm package:

 npm install ffmpeg.js

 import { createFFmpeg } from '@ffmpeg/ffmpeg';

const ffmpeg = createFFmpeg({ log: true });

async function transcode() {
  await ffmpeg.load();
  ffmpeg.FS('writeFile', 'test.mp4', new Uint8Array(videoData));
  await ffmpeg.run('-i', 'test.mp4', 'output.mp3');
  const audioData = ffmpeg.FS('readFile', 'output.mp3');
}

The underlying layer of this type of library is to compile C/C into WASM using Emscripten, and you don't have to write C at all.

2. Compile C/Rust to WASM by yourself (advanced)

If you want to write high-performance modules yourself, you can use:

• Emscripten (C/C → WASM)
• wasm-pack (Rust → WASM)

For example, write an addition function in C:

 // add.c
int add(int a, int b) {
  return ab;
}

Compiled with Emscripten:

 emcc add.c -o add.wasm -O3 -s EXPORTED_FUNCTIONS='["_add"]' -s EXPORTED_RUNTIME_METHODS='["ccall"]'

Load and call in JS:

 fetch('add.wasm').then(response =>
  response.arrayBuffer()
).then(bytes =>
  WebAssembly.instantiate(bytes)
).then(result => {
  const add = result.instance.exports._add;
  console.log(add(2, 3)); // Output 5
});

Note: The function name is preceded by _ , which is the convention of Emscripten.

3. Write WASM in JS style)

If you don't want to learn C or Rust, try AssemblyScript - it's a subset of TypeScript designed for WASM.

Install:

 npm init assemblyscript

Write a function:

 // src/index.ts
export function add(a: i32, b: i32): i32 {
  return ab;
}

Compilation:

 asc src/index.ts -b build/output.wasm -t build/output.wat

Called in JS:

 import { add } from './build/output.js';

console.log(add(2, 3)); // 5

AssemblyScript is the most friendly to JS developers, familiar with syntax, and relatively easy to debug.

Notes on WASM and JS communication

WASM and JS cannot directly share memory objects. Communication must be passed:

• numerical parameter transfer (int, float) - fast
• Linear Memory - Memory that passes arrays and strings requires manual reading and writing memory

For example, passing a string from JS to WASM:

 const encoder = new TextEncoder();
const encoded = encoder.encode("hello");

// Write data to WASM memory const ptr = wasmModule.allocate_string(encoded.length);
wasmModule.memory.set(encoded, ptr);

wasmModule.process_string(ptr, encoded.length);

In turn, WASM returns strings also require JS to read from memory:

 const ptr = wasmModule.get_result();
const len = wasmModule.get_result_length();
const bytes = new Uint8Array(wasmModule.memory.buffer, ptr, len);
const str = new TextDecoder().decode(bytes);

Suggestions : minimize frequent memory copies, pass large chunks of data at one time, and avoid performance backlash.

Debug WASM? Actually not that difficult

• Chrome DevTools supports debugging WASM (requires -g to generate debug information when compiling)
• You can see the function call stack and even set breakpoints
• AssemblyScript supports source map, can map back to TS code
• For C/C, the symbol name may be confused. It is recommended to enable DEMANGLE_SUPPORT

Tips: In the development stage, use wasm-text format ( .wat ) to view the generated underlying code and understand the execution logic.

Basically that's it. WASM is not magic, but it gives JS developers a "performance accelerator". You don't need to be a system programmer, you can also solve actual performance bottlenecks by integrating off-the-shelf libraries or writing simple modules.

The key is not "whether to learn WASM", but "when should I use it" - when you find that JS can't be counted, it is when it appears.

The above is the detailed content of WebAssembly (WASM) for JavaScript Developers: A Practical Introduction. For more information, please follow other related articles on the PHP Chinese website!