A preprint on a parallel web-programming library reports striking speedups on some compute-heavy tasks, including a 414x gain for one image-convolution test. But the results were uneven: some workloads fell below the sequential baseline, and the GPU version was slower than the best 16-thread CPU version for Filter.
ParaWeb packages 10 parallel programming patterns in a typed API, with three variants of each: message-passing, shared-buffer and GPU. The authors describe message-passing as simpler but copy-heavy, while shared-buffer avoids copies at the cost of coordination and a typed-array restriction.
The benchmark covered all 30 implementations at three input sizes, using a sequential baseline and parallel runs with 2, 4, 8 and 16 threads in both Node.js and the browser. Each configuration was run five times after two warmups, and the paper reported mean execution time and speedup against the sequential run.
Some array patterns scaled well
At 16 threads, Shared reached 10.48x speedup for Map, 10.44x for Filter and 11.54x for Scatter. The corresponding message-passing figures were 9.03x, 7.16x and 5.34x.
The result depended on how much computation each element carried. With fused per-element transforms, Reduce reached 11.62x with Shared and 7.77x with message-passing, while Scan reached 9.88x and 5.74x. Pure associative sum and pure prefix-sum workloads fell below 1x, meaning they were slower than the sequential baseline.
The workload changed the result
On Extremely Large inputs, Farm produced about 11x speedup at 16 threads. In Node.js, message-passing reached 11.25x and Shared 9.99x; in the browser, the figures were 11.11x and 11.85x.
Divide-and-conquer was a tougher test. On 8M complex points, Shared reached 2.73x in Node.js and 2.62x in the browser at 16 threads. Node.js message-passing was 0.23x at 2 threads and just 0.57x at 16 threads, remaining slower than sequential execution.
GPU gains came with exceptions
For Farm, the GPU reached 260.5x over sequential execution in Node.js and 222.6x in the browser. Against the best 16-thread CPU variant, the gains were 22.9x and 21.9x, respectively.
That advantage did not carry across every pattern. For Filter, GPU performance was 0.8x of the best 16-thread CPU result in Node.js and 0.7x in the browser, so the GPU was slower in both.
In an image-convolution case study, the GPU reached 414x speedup for an emboss filter at kernel radius 20: 75 milliseconds versus 31 seconds sequential. Across all three reported resolutions, that peak stayed between 380x and 414x.
A benchmark with clear boundaries
The experiments were run on an Apple MacBook Pro with an M3 Max chip, 16 CPU cores, 48 GB of unified memory and an integrated 40-core Apple GPU. That is one reported hardware and software environment, so the figures do not establish how the library will perform across other devices and runtimes.
The study reports mean times from five runs after two warmup runs, but no uncertainty intervals, inferential statistics or dispersion estimates. The benchmark's run protocol therefore gives averages without showing how much individual results varied.
The technical trade-offs are concrete: message-passing is copy-heavy, Shared is coordination-heavy and restricted to typed arrays, and GPU is described as the highest-throughput option but is limited by WGSL and f32 precision.
The practical message is conditional: ParaWeb posted double-digit CPU speedups and, for selected workloads, hundreds-fold GPU gains, but pure sum and prefix-sum jobs fell below sequential performance and GPU Filter trailed the best 16-thread CPU.
Paper data and sources
Original title: ParaWeb: Parallel Programming Patterns for Web Development
Authors: Suejb Memeti
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-20
DOI: Not available
Original paper · Full text