🧵 Run Multi Threads With Rust On Browser — Rayon And 2 Layers Web Worker Mechanism

There are no OS threads in the browser — so how does Rust's parallel processing library Rayon actually work?
Here's a summary.

🤔 Why Do We Need This?

When you run heavy computation (taking seconds to tens of seconds) on the browser's main thread, the UI completely freezes. Buttons become unclickable, scrolling stops, and you get the dreaded "This page is not responding" warning.

The solution is multithreading — offload heavy computation to the background, and split the work across multiple threads.

🏗️ Two-Layer Web Worker Architecture

Parallel computation in the browser requires Web Workers serving two distinct roles.

┌─────────────────────────────────────┐
│  🖥️ Main Thread (UI Thread)          │
│                                      │
│  User interactions, screen rendering │
│  → Always responsive                 │
└──────────┬───────────────────────────┘
           │ 📨 postMessage
           ↓
┌─────────────────────────────────────┐
│  👷 Layer 1: Worker Thread (1)       │
│                                      │
│  Takes on heavy computation          │
│  → Zero impact on the main thread    │
│                                      │
│  ┌─────────┬─────────┬─────────┐     │
│  │ 🏃 #1   │ 🏃 #2   │ 🏃 #3   │     │
│  │ rayon   │ rayon   │ rayon   │     │  ← Layer 2
│  │ Worker  │ Worker  │ Worker  │     │    N Web Workers
│  │         │         │         │     │
│  │ Part of │ Part of │ Part of │     │
│  │ the work│ the work│ the work│     │
│  └─────────┴─────────┴─────────┘     │
└─────────────────────────────────────┘

🛡️ Layer 1 — Protecting the UI

The role of the Layer 1 Web Worker is to move heavy computation out of the main thread.

Rayon doesn't come into play here yet — the purpose of this worker thread is simply to decouple from the main thread and keep it free.

An important note: even if you call a Rust async function from WASM, the internal CPU work synchronously blocks the thread. Being async doesn't prevent UI freezing. It's the Web Worker that sets the UI thread free.

⚡ Layer 2 — Splitting the Work

With Layer 1 alone, computation still runs sequentially on a single thread. Layer 2 splits the computation itself across multiple threads for actual speedup.

🦀 Rayon — Parallelise with .par_iter()

Rayon is Rust's parallel computation library. Usage is simple:

// 😴 Normal (single-threaded, sequential)
let results: Vec<_> = data.iter()
    .map(|x| heavy_computation(x))
    .collect();

// ⚡ Rayon (multi-threaded, parallel)
let results: Vec<_> = data.par_iter()    // ← just add par_
    .map(|x| heavy_computation(x))
    .collect();

Change .iter() to .par_iter() — that's it. Splitting, dispatching, and collecting results is all handled automatically by Rayon.

😴 1 thread:
  Thread 1: [Task 1, Task 2, ..., Task 524,288]
  → One thread does everything sequentially

⚡ 8 threads (Rayon):
  Thread 1: [Task      1 –  65,536]  🏃
  Thread 2: [Task 65,537 – 131,072]  🏃
  ...
  Thread 8: [Task 458,753 – 524,288]  🏃
  → 8 threads working simultaneously → ~8x faster

🌍 Same Rust Code, Different Backend

The beauty of Rayon is that the same Rust code runs on both native and browser. Only the underlying thread implementation differs.

         Same Rust code
         data.par_iter()
              │
     ┌────────┴────────┐
     ↓                 ↓
 🖥️ Native         🌐 Browser
     │                 │
  OS threads      wasm-bindgen-rayon
  (pthread)            │
     │            Web Worker × N
     ↓                 ↓
  Parallel ✅      Parallel ✅

• Native: Rayon → OS threads (pthread). No configuration needed — it just works.
• Browser: OS threads don't exist → wasm-bindgen-rayon translates Rayon's thread requests into Web Workers. initThreadPool(N) spawns N Web Workers.

initThreadPool() is only needed in the browser. On native, Rayon automatically uses OS threads.

🔒 Requirements for Browser Multithreading

Browser multithreading requires several conditions to be met for security reasons.

⚛️ Why is build-std needed?

The pre-built version of Rust's standard library (std) does not include atomics (shared memory operations). To share memory between threads, std must be rebuilt from source.

# ❌ Pre-built std → no atomics → no multithreading
wasm-pack build --release --target web

# ✅ build-std rebuilds std → atomics enabled → multithreading works
CARGO_UNSTABLE_BUILD_STD=std,panic_abort wasm-pack build --release --target web

💡 We pass this as an environment variable because Cargo's [unstable] section is global and cannot be scoped to WASM targets only. Putting it in the config file would break native builds.

🎯 Summary

User triggers an action 🖱️
  │
  ↓ postMessage
  │
👷 Layer 1: Worker Thread (1)
  │  → Does not block the UI
  │
  ├→ Rayon par_iter()
  │   │
  │   ├→ 🏃 Worker #1: part of the work
  │   ├→ 🏃 Worker #2: part of the work
  │   ...
  │   └→ 🏃 Worker #N: part of the work
  │
  │   → All workers complete → results collected
  │
  ↓ postMessage({ status: 'done' })
  │
🖥️ Main Thread: display result ✅
   → UI stayed responsive throughout 🎉

🔑 Three Key Takeaways

1. Layer 1 = Protects the UI. Just one worker. Moves heavy computation off the main thread.
2. Layer 2 = Makes computation faster. N workers. par_iter() automatically splits the work.
3. The same Rust code runs on both native and browser. Only the underlying thread implementation differs.

How was that?

Speed up your browser computation with Rust's parallel processing library Rayon ⚡⚡⚡