Bend 2 vs. JavaScript (Node.js, Bun, V8): Single-Threaded Event Loops vs. Lock-Free Interaction Parallelism

An execution-level comparison of JavaScript (V8, JavaScriptCore, Web Workers, SharedArrayBuffer) and Bend 2 (BendRT Task Cube and zero-dependency JS target) across 16 Apple M4 Max benchmarks.

Executive Summary: Bottom Line Up Front

JavaScript engines (Google V8 in Node.js/Deno and JavaScriptCore in Bun) excel at single-threaded Just-In-Time (JIT) compilation and asynchronous I/O, but their shared-nothing isolate architecture makes fine-grained multi-core and GPU parallelism expensive.

1. Keep JavaScript (Node.js, Bun, Browser DOM) for event-driven HTTP/WebSocket servers, SSR rendering, browser interactivity, and single-threaded workloads dominated by flat hash-map lookups (Map, object property inline caches).
2. Use Bend 2 (bend -o native binary or GPU kernel) whenever a CPU-bound or recursive computation blocks the JavaScript event loop. Spawning worker_threads or Web Workers in JavaScript forces recursive trees and object graphs through structuredClone serialization. By contrast, Bend 2’s BendRT Task Cube distributes 64-bit tasks across 16 CPU cores (PAR-CPU) and 16,384 GPU lanes (PAR-GPU) with zero serialization, zero locks, and zero garbage collection pauses (bendlang/bend). Across the 16 Apple M4 Max benchmarks, Bend 2’s 16-core CPU runtime outruns V8/Bun by 3.75x to 65.13x, and its GPU runtime outruns V8/Bun by up to 297.68x (benchmark dataset).
3. Use Bend 2’s JavaScript Target (bend prog.bend -o prog.js) when you want to ship mathematically proven, termination-checked algorithms (LAWS.bend / PROOF.bend) into browsers, Cloudflare Workers, or Node/Bun services with zero npm dependencies (bendlang/bend).

1. The JavaScript Concurrency Wall: Event Loop Blocking & structuredClone Overhead

Why does JavaScript struggle on parallel tree, graph, and simulation algorithms? The bottleneck is architectural:

1.1 One Thread Per Isolate

Every V8 or JavaScriptCore isolate runs user JavaScript on a single execution thread. If a request handler runs a 500 ms tree search, raytrace, or K-means clustering pass, the entire event loop stalls. That stall starves every concurrent HTTP socket, timer, and promise microtask in that process.

1.2 Why worker_threads and Web Workers Fail on Recursive Trees

To use multiple CPU cores in Node.js or Bun, developers must spawn worker_threads or Web Workers. Because each worker owns an isolated V8/JSC heap, passing a recursive data structure (such as an AST, Merkle tree, or BVH scene graph) between workers invokes the Structured Clone Algorithm (structuredClone / postMessage):

• Deep Copy Penalty: structuredClone walks the entire object graph on the sender thread, serializes it into an intermediate buffer, and allocates a fresh copy on the receiver thread’s heap. For fine-grained divide-and-conquer tasks (a b = f(left) f(right)), serialization takes 10x to 100x longer than the computation itself.
• The SharedArrayBuffer Escape Hatch Breaks High-Level Ergonomics: SharedArrayBuffer and Atomics allow workers to share raw byte buffers without copying. However, using them requires manually flattening JavaScript objects into typed-array byte offsets and writing error-prone spinlocks or futexes (Atomics.wait / Atomics.compareExchange).

1.3 How BendRT Eliminates Both Serialization and Locks

In Bend 2, a parallel let binding (a b = f(x) g(y)) executes inside a single unified 8 TiB virtual address space (MAP_NORESERVE) shared across all CPU threads and unified-memory GPU warps (bendlang/bend):

• Every value is a 64-bit word ([rfc(1) | tag(7) | aux(16) | loc(40)]).
• Forking a task pushes a 64-bit pointer into a lock-free ring buffer inside the 128 × 128 Task Cube (16,384 rings), copying zero heap bytes (benchmark dataset).
• Because BendTT enforces Church-Rosser confluence and affine variable usage (mechanized in 20,981 lines of Lean 4), two worker threads reducing different branches of a term can never observe a data race (bendtt.lean).

2. Empirical Benchmarks: V8/Bun vs. Bend 2 on Apple M4 Max

The table below compares JavaScript/TypeScript execution on V8/Bun (ts_sec) against Bend 2’s sequential CPU (SEQ-CPU), 16-core parallel CPU (PAR-CPU), and Metal GPU (PAR-GPU) runtimes across 10 representative workloads from /data/bend-ecosystem.json (benchmark dataset):

Honest Analysis: Where V8 Beats Sequential Bend (nbody, mandelbrot, hashmap)

Look closely at the JS / TS vs. Bend SEQ-CPU columns in the table above (benchmark dataset):

• On single-threaded scalar loops (mandelbrot: 3.837 s JS vs. 4.473 s SEQ-CPU; nbody: 5.332 s JS vs. 5.758 s SEQ-CPU) and single-threaded hash table lookups (hashmap: 0.892 s JS vs. 2.741 s SEQ-CPU), V8’s TurboFan JIT compiler actually beats single-core Bend 2! V8 unboxes IEEE-754 floats in tight loops and uses hidden-class inline caches for object properties.
• However, V8 is trapped on 1 core unless you manually rewrite your algorithm around worker_threads and SharedArrayBuffer. When Bend 2 switches to PAR-CPU (16 cores) or PAR-GPU (Metal), the unmodified source jumps from 5.758 s to 0.516 s (CPU) and 0.059 s (GPU) on nbody (benchmark dataset). On hashmap, it drops from 2.741 s to 0.238 s (CPU) (benchmark dataset).
• While a typical Node.js or Bun process consumes 45 MB to 120 MB RSS at baseline, Bend 2’s native binaries execute gameoflife, nbody, raytrace, and lexer in 2.0 MB to 3.0 MB RSS (benchmark dataset).

3. Inside Bend 2’s JavaScript Compiler Target (bend -o prog.js)

In addition to compiling to native C/CUDA/Metal (bend prog.bend -o prog), Bend 2 includes a first-class JavaScript code generator (js_book and js_lib in bend2/comp.ts) (bendlang/bend):

# Emit a standalone executable JS file
bend src/engine.bend -o dist/engine.js

# Emit an ES module for import in Node.js, Bun, or Browser bundles
bend src/engine.bend -o dist/engine.mjs

How Bend 2 Values Map to Native JavaScript

The generated JavaScript has zero external runtime dependencies and maps BendTT types directly onto fast V8/JSC primitives (bendlang/bend):

4. When to Choose JavaScript vs. Bend 2