WebCompute
Portable computation for the Web.
WebCompute is an open research project investigating portable computation across existing Web capabilities. It asks a simple browser-engineering question: can a Web application describe useful computation once, and let a small runtime choose the best available way to run it on each device?
Research projectNot a Web standard
The Web gives developers many ways to run code. It does not help them choose.
The Web platform already offers several ways to run computational work: JavaScript, Web Workers, WebAssembly, WebAssembly SIMD, and WebGPU. Each is portable. Each is well-specified. What the platform does not offer is a portable way to decide among them.
Today that decision belongs to the application. Developers who care about performance write multiple implementations, detect capabilities, tune thresholds, manage data movement, and keep fallbacks alive. The right answer still changes from device to device.
Application
- 1JS implementation
- 2Wasm implementation
- 3WebGPU implementation
- 4capability detection
- 5thresholds
- 6transfers
- 7fallback
Application
Computation
Planning layer
Execution strategy selected at runtime
Describe what. Let the runtime decide how.
WebCompute separates two concerns that today’s Web applications are forced to combine:
The work
the computation is
The path
CPU or GPU, JavaScript, WebAssembly, or WebGPU
The application owns the meaning of the computation. The runtime owns the execution strategy. Whether this separation can be made efficient enough to be worth having is the central question of the project.
Four commitments
These are not achievements. Each is written at the level of claim WebCompute can honestly make while the research is still in progress.
- Portable
- Describing computation independently of one execution mechanism, so a runtime could choose among JavaScript, WebAssembly, and WebGPU per device.
- Safe
- Staying inside the security and privacy boundaries the Web platform already enforces. No new hardware exposure.
- Open
- Publishing the research reports, the explainer, and eventually the experiment results in the open, including results that do not support the hypothesis.
- Part of the Web platform
- Not a replacement for JavaScript, WebAssembly, WebGPU, Web Workers, or WebNN. WebCompute investigates a coordination layer that would use them, built incrementally.
The full research goals go into more depth on each of these.
Architecture under investigation
An application expresses computational work as a semantic graph that describes operations and data dependencies without naming a specific execution mechanism. A planning layer analyzes the graph together with the capabilities of the current device and produces an execution plan: an assignment of graph regions to concrete execution strategies across the CPU and GPU domains.
Why investigate this
Performance portability. The same computation can have a different best execution strategy on different devices. A strategy that is optimal on a discrete-GPU desktop can be the slowest available option on a low-end phone. A per-device decision cannot be compiled into the application ahead of time.
Less coupling to execution details. Application logic would no longer be shaped around WebGPU, WebAssembly, JavaScript selection, capability checks, and fallback chains. The computation is described once; the selection logic lives in the runtime.
Whole-graph decisions. A runtime that sees the entire graph can weigh data-transfer costs and resource residency, not just per-kernel speed. Moving work to the GPU is only a win if the data movement doesn’t cost more than the compute saves. That judgment requires seeing more than one operation at a time.
Browser policy, eventually. A future browser implementation could fold device, resource, and privacy knowledge into execution decisions without exposing raw hardware information to applications. This is a potential long-term benefit of the abstraction, not a capability of anything that exists today.
Same graph. Different plans.
Consider a simple image pipeline, described once as a graph. A planning layer working per-device could produce different execution plans for the same graph.
| Device | decode | transform | filter | reduce |
|---|---|---|---|---|
| Desktop A (discrete GPU) | GPU | GPU | GPU | GPU |
| Laptop B (no WebGPU) | WebAssembly | WebAssembly | WebAssembly | WebAssembly |
| Device C (low-end) | JavaScript | WebAssembly | WebAssembly | WebAssembly |
The application code is identical in all three cases. The execution strategy is not.
Relationship to the Web platform
| Technology | Primary role |
|---|---|
| JavaScript | General application and runtime language |
| Web Workers | Concurrency topology |
| WebAssembly | Portable CPU execution |
| WebGPU | Explicit GPU computation |
| WebNN | ML-specific, hardware-independent graph execution |
| WebCompute | Investigatesa general-purpose execution abstraction over the above |
WebCompute is not a Web standard and has not been proposed to any standards body. The row above describes the subject of this research, not a platform capability. See the FAQ for direct answers on what WebCompute does and does not replace.
What WebCompute is not
WebCompute is not any of these:
- Replacement for WebGPU
- Replacement for WebAssembly
- New shader language
- New programming language
- Machine-learning API
- Hardware enumeration API
- Distributed-compute platform
These exclusions are part of the research scope, not marketing restraint. Several of them exist specifically to keep the security and privacy surface tractable. WebCompute deliberately avoids exposing hardware details that the Web platform has chosen not to expose.
Requirements and non-goals in the canonical repository
The same exclusions, phrased as direct questions, are on the FAQ.
Research status
The project proceeds through explicitly gated research phases. The repository now has a draft explainer, planned foundation reports, and a planned first experiment. The evidence work still has to be written before implementation begins.
- Report 1
Prior Art & Landscape
Planned
- Report 2
Problem Definition
Planned
- Report 3
Use Cases & Workload Taxonomy
Planned
- Report 4
Requirements & Non-Goals
Planned
- Report 5
Compute Representation
Planned
- Report 6
Execution Mechanism & Capability Model
Planned
- Report 7
Planning Layer, Cost Model & Scheduling
Planned
- Report 8
Security, Privacy & Web Platform Constraints
Planned
Explainer draft
Draft
Current phase
Research reports in preparation
The hypothesis
A structured, execution-independent compute graph can enable a lightweight runtime to select execution strategies across existing Web compute mechanisms with low enough planning and data-movement overhead to provide meaningful performance portability across heterogeneous client devices.
This hypothesis is not assumed true. The first experiment is being scoped to test it.
If the first experiment shows that planning overhead or data-movement costs consistently erase the gains, that result will be published with the same prominence as a positive one.
First experiment
Before any API design is finalized, the core hypothesis should be tested on a deliberately small surface.
- Map, reduce, stencil, and chained map work
- JavaScript, WebAssembly, and WebGPU
- latency, transfer cost, planning overhead, oracle regret, and cross-device portability
The key metric is oracle regret: how much slower the planning layer’s chosen strategy is than the best strategy available on that device, chosen with perfect hindsight. A planning layer with low regret across heterogeneous devices is what would validate the hypothesis; a planning layer with high regret would refute it.
isprotocol planned.Seeexperiments
Canonical repository
Everything that defines WebCompute beyond this website, the foundation reports, the explainer, the architecture notes, and eventually the first experiment’s code and results, lives in one place. This site presents that work. It does not extend it.