WebAssembly in Action you own this product

With examples using C++ and Emscripten

Gerard Gallant

November 2019
ISBN 9781617295744
448 pages

Included with a Manning Online subscription

printed in black & white

available in Italian, Japanese, Korean, Russian, Simplified Chinese

catalog / Software Development / Software Engineering / Application Development / Frontend Development / Web Development

table of content

Part 1. First steps

1. Meet WebAssembly

1.1. What is WebAssembly?

1.1.1. Asm.js, the forerunner to WebAssembly

1.1.2. From asm.js to MVP

1.2. What problems does it solve?

1.2.1. Performance improvements

1.2.2. Faster startup times compared with JavaScript

1.2.3. Ability to use languages other than JavaScript in the browser

1.2.4. Opportunity for code reuse

1.3. How does it work?

1.3.1. Overview of how compilers work

1.3.2. Loading, compiling, and instantiating a module

1.4. Structure of a WebAssembly module

1.4.1. Preamble

1.4.2. Known sections

1.4.3. Custom sections

1.5. WebAssembly text format

1.6. How is WebAssembly secure?

1.7. What languages can I use to create a WebAssembly module?

1.8. Where can I use my module?

Summary

2. A look inside WebAssembly modules

2.1. Known sections

2.2. Custom sections

Summary

3. Creating your first WebAssembly module

3.1. The Emscripten toolkit

3.2. WebAssembly modules

3.2.1. When would you not use a WebAssembly module?

3.3. Emscripten output options

3.4. Compiling C or C++ with Emscripten and using the HTML template

3.5. Having Emscripten generate the JavaScript plumbing code

3.5.1. Compiling C or C++ with Emscripten-generated JavaScript

3.5.2. Creating a basic HTML web page for use in browsers

3.6. Having Emscripten generate only the WebAssembly file

3.6.1. Compiling C or C++ as a side module with Emscripten

3.6.2. Loading and instantiating in a browser

3.7. Feature detection: How to test if WebAssembly is available

Real-world use cases

Exercises

Summary

Part 2. Working with modules

4. Reusing your existing C++ codebase

4.1. Using C or C++ to create a module with Emscripten plumbing

4.1.1. Making the C++ modifications

4.1.2. Compiling the code into a WebAssembly module

4.1.3. Creating the web page

4.1.4. Creating the JavaScript that will interact with the module

4.1.5. Viewing the results

4.2. Using C or C++ to create a module without Emscripten

4.2.1. Making the C++ modifications

4.2.2. Compiling the code into a WebAssembly module

4.2.3. Creating the JavaScript that will interact with the module

4.2.4. Viewing the results

Real-world use cases

Exercises

Summary

5. Creating a WebAssembly module that calls into JavaScript

5.1. Using C or C++ to create a module with Emscripten plumbing

5.1.1. Adjusting the C++ code

5.1.2. Creating the JavaScript that you want included in Emscripten’s ge- enerated JavaScript file

5.1.3. Compiling the code into a WebAssembly module

5.1.4. Adjusting the web page’s JavaScript code

5.1.5. Viewing the results

5.2. Using C or C++ to create a module without Emscripten plumbing

5.2.1. Making the C++ modifications

5.2.2. Compiling the code into a WebAssembly module

5.2.3. Adjusting the JavaScript that will interact with the module

5.2.4. Viewing the results

Real-world use cases

Exercises

Summary

6. Creating a WebAssembly module that talks to JavaScript using function pointers

6.1. Using C or C++ to create a module with Emscripten plumbing

6.1.1. Using a function pointer given to the module by JavaScript

6.1.2. Adjusting the C++ code

6.1.3. Compiling the code into a WebAssembly module

6.1.4. Adjusting the web page’s JavaScript code

6.1.5. Viewing the results

6.2. Using C or C++ to create a module without Emscripten plumbing

6.2.1. Using function pointers given to the module by JavaScript

6.2.2. Making the C++ modifications

6.2.3. Compiling the code into a WebAssembly module

6.2.4. Adjusting the JavaScript that will interact with the module

6.2.5. Viewing the results

Real-world use cases

Exercises

Summary

Part 3. Advanced topics

7. Dynamic linking: The basics

7.1. Dynamic linking: Pros and cons

7.2. Dynamic linking options

7.2.1. Side modules and main modules

7.2.2. Dynamic linking: dlopen

7.2.3. Dynamic linking: dynamicLibraries

7.2.4. Dynamic linking: WebAssembly JavaScript API

7.3. Dynamic linking review

Real-world use cases

Exercises

Summary

8. Dynamic linking: The implementation

8.1. Creating the WebAssembly modules

8.1.1. Splitting the logic in the validate.cpp file into two files

8.1.2. Creating a new C++ file for the Place Order form’s logic

8.1.3. Using Emscripten to generate the WebAssembly side modules

8.1.4. Defining a JavaScript function to handle an issue with the validation

8.1.5. Using Emscripten to generate the WebAssembly main module

8.2. Adjusting the web page

8.2.1. Adjusting your web page’s JavaScript

8.2.2. Viewing the results

Real-world use cases

Exercises

Summary

9. Threading: Web workers and pthreads

9.1. Benefits of web workers

9.2. Considerations for using web workers

9.3. Prefetching a WebAssembly module using a web worker

9.3.1. Adjusting the calculate_primes logic

9.3.2. Using Emscripten to generate the WebAssembly files

9.3.3. Copying files to the correct location

9.3.4. Creating the HTML file for the web page

9.3.5. Creating the JavaScript file for the web page

9.3.6. Creating the web worker’s JavaScript file

9.3.7. Viewing the results

9.4. Using pthreads

9.4.1. Adjusting the calculate_primes logic to create and use four pthreads

9.4.2. Using Emscripten to generate the WebAssembly files

9.4.3. Viewing the results

Real-world use cases

Exercises

Summary

10. WebAssembly modules in Node.js

10.1. Revisiting what you know

10.2. Server-side validation

10.3. Working with Emscripten-built modules

10.3.1. Loading a WebAssembly module

10.3.2. Calling functions in the WebAssembly module

10.3.3. Calling into the JavaScript

10.3.4. Calling JavaScript function pointers

10.4. Using the WebAssembly JavaScript API

10.4.1. Loading and instantiating a WebAssembly module

10.4.2. Calling functions in the WebAssembly module

10.4.3. The WebAssembly module calling into JavaScript

10.4.4. The WebAssembly module calling JavaScript function pointers

Real-world use cases

Exercises

Summary

Part 4. Debugging and testing

11. WebAssembly text format

11.1. Creating the game’s core logic using WebAssembly text format

11.1.1. The module’s sections

11.1.2. Comments

11.1.3. Function signatures

11.1.4. The module node

11.1.5. The import nodes

11.1.6. The global nodes

11.1.7. The export nodes

11.1.8. The start node

11.1.9. The code nodes

11.1.10. The type nodes

11.1.11. The data node

11.2. Generating a WebAssembly module from the text format

11.3. The Emscripten-generated module

11.3.1. Creating the C++ file

11.3.2. Generating a WebAssembly module

11.4. Creating the HTML and JavaScript files

11.4.1. Modifying the HTML file

11.4.2. Creating the JavaScript file

11.5. Viewing the results

Real-world use cases

Exercises

Summary

12. Debugging

12.1. Extending the game

12.2. Adjusting the HTML

12.3. Displaying the number of tries

12.3.1. The generateCards JavaScript function

12.3.2. Adjusting the text format

12.3.3. Generating the Wasm file

12.3.4. Testing the changes

12.4. Incrementing the number of tries

12.4.1. The updateTriesTotal JavaScript function

12.4.2. Adjusting the text format

12.4.3. Generating the Wasm file

12.4.4. Testing the changes

12.5. Updating the summary screen

12.5.1. The levelComplete JavaScript function

12.5.2. Adjusting the text format

12.5.3. Generating the Wasm file

12.5.4. Testing the changes

Exercises

Summary

13. Testing—and then what?

13.1. Installing the JavaScript testing framework

13.1.1. The package.json file

13.1.2. Installing Mocha and Chai

13.2. Creating and running tests

13.2.1. Writing the tests

13.2.2. Running the tests from the command line

13.2.3. An HTML page that loads your tests

13.2.4. Running the tests from a browser

13.2.5. Making the tests pass

13.3. Where do you go from here?

Exercises

Summary

Appendixes

Appendix A: Installation and tool setup

A.1. Python

A.1.1. Running a local web server

A.1.2. The WebAssembly media type

A.2. Emscripten

A.2.1. Downloading the Emscripten SDK

A.2.2. If you’re using Windows

A.2.3. If you’re using a Mac or Linux

A.2.4. Working around installation issues

A.3. Node.js

A.4. WebAssembly Binary Toolkit

A.5. Bootstrap

Appendixes

Appendix B: ccall, cwrap, and direct function calls

B.1. ccall

B.1.1. Building a simple WebAssembly module

B.1.2. Building the web page that will talk to the WebAssembly module

B.2. cwrap

B.2.1. Adjusting the JavaScript code to use cwrap

B.3. Direct function calls

B.4. Passing an array to a module

Appendixes

Appendix C: Emscripten macros

C.1. emscripten_run_script macros

C.2. EM_JS macros

C.2.1. No parameter values

C.2.2. Passing parameter values

C.2.3. Passing pointers as parameters

C.2.4. Returning a string pointer

C.3. EM_ASM macros

C.3.1. EM_ASM

C.3.2. EM_ASM_

C.3.3. Passing pointers as parameters

C.3.4. EM_ASM_INT and EM_ASM_DOUBLE

C.3.5. Returning a string pointer

Appendixes

Appendix D: Exercise solutions

D.1. Chapter 3

D.1.1. Exercise 1

D.1.2. Exercise 2

D.2. Chapter 4

D.2.1. Exercise 1

D.2.2. Exercise 2

D.3. Chapter 5

D.3.1. Exercise 1

D.3.2. Exercise 2

D.4. Chapter 6

D.4.1. Exercise 1

D.4.2. Exercise 2

D.5. Chapter 7

D.5.1. Exercise 1

D.5.2. Exercise 2

D.6. Chapter 8

D.6.1. Exercise 1

D.6.2. Exercise 2

D.7. Chapter 9

D.7.1. Exercise 1

D.7.2. Exercise 2

D.8. Chapter 10

D.8.1. Exercise 1

D.8.2. Exercise 2

D.8.3. Exercise 3

D.9. Chapter 11

D.9.1. Exercise 1

D.9.2. Exercise 2

D.10. Chapter 12

D.10.1. Exercise 1

D.10.2. Exercise 2

D.11. Chapter 13

D.11.1. Exercise 1

D.11.2. Exercise 2

Appendixes

Appendix E: Text format extras

E.1. Control flow statements

E.1.1. If statements

E.1.2. Loops

E.2. Function pointers

E.2.1. Test the code

Overview

1 Meet WebAssembly

Modern web experiences live and die by performance, yet browsers historically ran only JavaScript, which is being pushed to do ever heavier work. In 2017, all major browsers shipped support for WebAssembly (Wasm), a compact, low-level, assembly-like format that executes at near‑native speed. Designed as a compilation target, WebAssembly lets code written in languages such as C, C++, and Rust run on the web, enabling reuse of existing codebases, powering new high-performance libraries, and opening a path to run beyond the browser as well.

WebAssembly addresses performance from download to execution. Whereas JavaScript is interpreted and JIT-compiled around dynamic types, Wasm is statically typed and compiled ahead of time to a binary bytecode that is fast to transmit, validate, and compile—benefiting startup on the very first run and further boosted by streaming compilation. It improves on asm.js (a typed subset of JavaScript) by avoiding large, parse-heavy JS files and by being a true compiler target. The workflow compiles source to an intermediate representation and then to .wasm bytecode; the browser validates it in a single pass and compiles it to machine code before instantiating the module. Modules expose a small set of numeric value types, manage their own linear memory, include well-defined known sections plus flexible custom sections, and also have a human-readable text form based on s-expressions for tooling and debugging.

Security comes from running inside the hardened, sandboxed JavaScript VM and adhering to the same policies (such as same-origin). Modules receive bounded linear memory, access function tables indirectly, and cannot touch the execution stack directly, limiting attack surface. WebAssembly complements rather than replaces JavaScript: today modules interoperate with JS (which can call Web APIs on their behalf), with direct host bindings planned. While C/C++ and Rust are first-class, many other languages are experimenting with Wasm targets. Support spans all major desktop and many mobile browsers, as well as Node.js, making it practical to accelerate performance-critical parts of applications, reuse existing native code, and deliver faster, more responsive web experiences.

JavaScript compiled to machine code as it executes

C++ being turned into WebAssembly and then into machine code in the browser

Compiler front-end and back-end diagram

Compiler front-end with a WebAssembly back-end diagram

Wasm file loaded into a browser and then compiled to machine code diagram

Summary

As you saw in this chapter, WebAssembly brings a number of improvements with many being around performance as well as language choice and code reuse. Some of the key improvements that WebAssembly brings are the following:

Faster transmission and download times because of the smaller file sizes due to the use of a binary encoding.
Due to the way the files are structured, they can be parsed and validated quickly. Also because of how they’re structured, portions of the file can be compiled in parallel.
With streaming compilation, WebAssembly modules can be compiled as they’re being downloaded so that they’re ready to be instantiated the moment the download completes speeding up load time considerably.
Faster code execution for things like computations due to the use of machine level calls rather than the more expensive JavaScript engine calls.
Code doesn’t need to be monitored before it’s compiled to determine how it’s going to behave. The result is that code runs at the same speed every time it runs.
Being separate from JavaScript, improvements can be made to WebAssembly faster because it won’t impact the JavaScript language.
The ability to use code written in a language, other than JavaScript, in a browser.
Increased opportunity for code reuse by structuring the WebAssembly framework in such a way that it can be used in the browser and outside of the browser.

FAQ

What is WebAssembly (Wasm)?

WebAssembly is a low-level, assembly-like binary format designed as a compilation target for languages such as C, C++, and Rust. It runs at near‑native speed in modern desktop and many mobile browsers. In 2017, Chrome, Edge, Firefox, Safari, and other major browsers shipped support for its MVP (Minimum Viable Product). Wasm modules are compact, quick to download, and fast to validate and initialize.

What problems does WebAssembly aim to solve?

Primarily performance: faster downloads (compact binaries), faster parse/validation, and faster execution (ahead-of-time compilation from a statically typed format). It also enables using languages other than JavaScript in the browser and promotes code reuse by compiling existing native codebases to run on the web.

How does WebAssembly differ from JavaScript at runtime?

JavaScript is interpreted and JIT-compiled from dynamic types, so engines monitor code to optimize hot paths. WebAssembly is statically typed and compiled ahead of time to a binary bytecode that browsers can rapidly validate and compile to native machine code immediately, yielding predictable, fast startup and execution. Wasm runs in the same VM as JavaScript and currently relies on JavaScript to access Web APIs.

What is asm.js and how did it lead to WebAssembly?

asm.js is a typed, performance-oriented subset of JavaScript (triggered by "use asm") typically produced by transpiling C/C++ to JS. It improved performance via type hints and low-level operations but had drawbacks: large files from type hints, still parsed by the JS engine (costly on mobile), and adding features required changing JavaScript itself. WebAssembly keeps the performance wins while addressing these shortcomings with a compact binary and an independent evolution path.

How does WebAssembly achieve faster startup times?

Wasm binaries are compact and structured for single-pass validation and parallel compilation. Because types are known up front, browsers can compile to machine code immediately without warm-up profiling. Streaming compilation further accelerates startup by compiling as the file downloads, enabling instantiation as soon as the download completes.

How are Wasm modules loaded, compiled, and instantiated?

Today, JavaScript APIs fetch the .wasm binary, validate it, compile it to machine code, and instantiate it. Instantiation wires up imports, initializes module elements, optionally calls a start function, and returns an instance. Compiled modules can be transferred to Web Workers or other windows and used to create additional instances.

How is WebAssembly secured in the browser?

Wasm shares the hardened, sandboxed JavaScript VM and inherits policies like same-origin. Modules have no direct system access; they operate within a bounds-checked linear memory (an ArrayBuffer) provided at initialization. Function references live in a separate table accessed indirectly by index, and the execution stack is separate from linear memory, preventing pointer-based stack tampering.

What is the structure of a Wasm module?

A .wasm file begins with a preamble: magic number 0x00 61 73 6D ("\0asm") and version 0x01 00 00 00. It then contains optional sections. Known sections appear at most once in a required order and are validated on instantiation. Custom sections can appear anywhere, multiple times, and are not validated the same way (e.g., the post-MVP “name” section for debug symbols). Wasm currently supports four value types: i32, i64, f32, and f64; booleans use i32; other types (like strings) live in linear memory.

Which languages can target WebAssembly?

Production tooling focuses on C and C++, with Rust also well supported. You can also author in the WebAssembly Text format (s-expressions) and compile to binary. Languages experimenting with Wasm include AssemblyScript (TypeScript → Wasm), TeaVM (Java), Go (with its own GC), Pyodide (Python with scientific stack), and Blazor (C#). Lack of built-in GC in the MVP constrains some languages, though GC is a post-MVP goal.

Where can I run WebAssembly?

All major desktop browsers (Chrome, Edge, Firefox, Opera, Safari), several mobile browsers (e.g., Chrome, Firefox for Android, Safari), and Node.js (v8+) support Wasm. It was designed for portability, so usage extends beyond the browser as well. WebAssembly complements JavaScript—use each where it fits best, and interoperate within the same VM.

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

pdf, ePub, online

$39.99 $25.99

you save $14.00 (35%)

include audio $19.99 $12.99

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

$39.99 $25.99

you save $14.00 (35%)

include audio $19.99 $12.99

eBook

pdf, ePub, online

$39.99 $25.99

you save $14.00 (35%)

include audio $19.99 $12.99

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more