Skip to content
WebCompute

What already exists

Prior art

WebCompute is not the first attempt to make computation on the Web faster or more portable, and this page does not pretend otherwise. The projects below shaped the research questions; several of them demonstrate, in production, pieces of what WebCompute investigates in general form. The first foundation report is planned to examine this landscape in full.

  • River Trail

    Historical research from Intel

    What it does
    Data-parallel programming extensions for JavaScript (ParallelArray), executing deterministic parallel kernels on multi-core CPUs.
    What WebCompute learns from it
    There is long-standing demand for parallel computation on the Web. Proposals requiring new language surface face steep adoption barriers.
    How the investigation differs
    WebCompute investigates coordination over execution mechanisms the platform already ships, rather than introducing new parallel language constructs.

  • ParaWeb

    Academic research

    What it does
    Research work on bringing transparent parallel and accelerated execution to Web programs.
    What WebCompute learns from it
    Academic evidence that runtime-managed parallel execution in the browser is worth studying, along with the practical obstacles such systems hit.
    How the investigation differs
    WebCompute centers an explicit, structured graph representation and a measurable planning question (oracle regret) rather than transparent acceleration of unmodified code.

  • GPU.js

    Open-source library

    What it does
    Compiles a restricted subset of JavaScript functions into GPU kernels, with CPU fallback.
    What WebCompute learns from it
    Developers will adopt GPU compute when they don't have to author shaders. Single-kernel translation still leaves transfer costs and placement decisions to the application.
    How the investigation differs
    WebCompute investigates whole-graph planning across placement, transfer cost, and residency rather than per-kernel translation.

  • TensorFlow.js

    Open-source ML library

    What it does
    Runs machine-learning models in the browser across multiple execution mechanisms: CPU, WebAssembly, WebGL, and WebGPU.
    What WebCompute learns from it
    Production proof that multi-mechanism execution works on the Web, and a demonstration of how much selection machinery a single domain-specific library must carry.
    How the investigation differs
    TensorFlow.js selects execution mechanisms for ML tensor operations. WebCompute investigates whether a comparable capability can exist for general-purpose eligible computation, below the level of any one library.

  • ONNX Runtime Web

    Open-source ML runtime

    What it does
    Executes ONNX model graphs in the browser through pluggable execution providers (WebAssembly, WebGPU, WebNN).
    What WebCompute learns from it
    A working pattern: a portable graph format planned onto heterogeneous execution providers at runtime, inside real browser constraints.
    How the investigation differs
    The graph vocabulary is ML operations over tensors. WebCompute asks whether the pattern generalizes beyond machine learning.

  • WebNN

    W3C specification work

    What it does
    A Web API for ML-specific, hardware-independent graph execution, letting implementations choose how a neural-network graph runs.
    What WebCompute learns from it
    The closest standards precedent: a graph handed to the platform, with execution decisions made below the API. WebNN shows this shape can survive standards scrutiny for a bounded domain.
    How the investigation differs
    WebNN's operation set is ML-specific by design. WebCompute investigates the general-purpose case, which is a materially harder representation and planning problem and may not admit the same answer.

  • WebGPU

    Web standard

    What it does
    Explicit, portable access to GPU computation and rendering, with compute shaders written in WGSL.
    What WebCompute learns from it
    The portable GPU execution baseline WebCompute's GPU domain would build on. Its explicitness is a feature: experts get full control.
    How the investigation differs
    WebCompute is not an alternative to WebGPU and does not compete with its explicit model. It investigates a layer that could target WebGPU as one execution strategy among several.

  • WebAssembly

    Web standard

    What it does
    Portable, near-native CPU execution, with SIMD and threads as additional capabilities.
    What WebCompute learns from it
    The portable CPU execution baseline for the CPU domain, and evidence that low-level portable execution can be standardized well.
    How the investigation differs
    WebAssembly answers how portable code runs on a CPU. WebCompute investigates the decision above it: whether a given piece of work should run there at all.

  • Heterogeneous runtime research

    Systems research on native platforms

    What it does
    Task-based runtimes for native systems (e.g. StarPU, Legion) that place task graphs across CPUs and GPUs using cost models and data-locality tracking.
    What WebCompute learns from it
    Strong evidence that cost-model-driven, whole-graph placement across heterogeneous processors is viable on native platforms with full hardware visibility.
    How the investigation differs
    The browser removes the assumptions this literature relies on: hardware enumeration, stable profiling, offline tuning. Whether the approach survives Web-platform constraints is largely unstudied. That gap is where this project sits.

The planned full prior-art analysis lives in the canonical repository at simplbase/webcompute.