Running Sandboxed Web Apps with WebAssembly & Web Workers

Introduction

Web browsers traditionally run on a single main thread. Executing heavy operations like bulk image compression or PDF document splitting directly on this thread blocks the UI, causing screen lag and poor user experience. To maintain 60FPS fluid interfaces, CoShareX delegates heavy utilities to background threads using Web Workers.

The Single Thread Bottleneck

When JavaScript compiles heavy tasks (like parsing massive binary document structures), the event loop gets blocked. This prevents CSS renders and hover actions, making the page look broken. Moving operations to background threads resolves this layout freezing.

Threading in JavaScript with Web Workers

Web Workers let developers spawn background tasks that communicate with the main thread using event messages. Below is a standard background worker script configuration:

// Main thread configuration
const worker = new Worker('/workers/pdf-compiler.js');

worker.postMessage({ fileBytes: pdfBuffer, action: 'SPLIT' });

worker.onmessage = (event) => {
  const { splitPdfBytes } = event.data;
  console.log('PDF document processed in background thread!');
};

Compiling Native Libs to WebAssembly

For processing tasks requiring raw CPU speed (like image rendering or PDF calculations), compiling C++ or Rust codebases to WebAssembly is the industry standard. This permits native execution speed directly inside the Web Worker thread.

WASM vs JS Processing Speeds

Below is a performance mapping of WebAssembly libraries compared to standard JavaScript loops for binary byte parsers:

Best Practices for WASM Sandboxes

• Transfer buffer ownership instead of copying byte arrays to avoid memory overhead.
• Compile WASM modules with optimization flags (-O3) to secure maximum parsing speeds.
• Isolate WASM instances to prevent cross-module memory namespace conflicts.