01 · What it is
What Three.js is, and why it matters
Three.js is the dominant JavaScript library for 3D in the browser. Created by Ricardo Cabello (Mr.doob) and MIT licensed, it is the standard way to draw GPU-accelerated 3D on a web page. Product configurators, browser games, data-visualization dashboards, virtual showrooms: a large share of the 3D you meet on the web runs through it.
It matters here because of a property of general-purpose renderers. A Three.js application re-answers the same questions every frame: which objects share a program, which values changed, which changes affect which passes, what can be batched. Most apps have one stable answer to most of those questions, and they pay to rediscover it 120 times a second. Authors of closed, performance-critical apps (configurators, kiosk displays, casual games on mid-tier phones) hit frame-time ceilings and either hand-optimize or accept them. The idea behind this project is to recover those answers once, at build time, instead of re-deriving them every frame.
02 · Why build it
Why rewrite it in Rust?
The maintainer's answer is that he is not rewriting it. The packet records why the rewrite was rejected: a from-scratch renderer that keeps the full Three.js r186 surface, under the project's no-cut rule (compatibility work may be reordered, but nothing may be permanently omitted), is a multi-engineer-year undertaking one person cannot staff. So the project specializes around the upstream library instead of replacing it: leave Three.js untouched, detect the closed numeric parts of an application's frame loop, compile them into Wasm kernels at build time, and ship the answer plus a small invalidation condition. If the world isn't closed at runtime — an alias, an accessor, an unsupported shape — guards fall back to the original JavaScript.
The engineering case: specialization preserves compatibility by construction, because the library is never modified. The mechanism is real: a 779-line Acorn-based compiler that parses a closed JavaScript function body and emits an import-free Wasm module, plus a 536-line runtime of ownership and shape guards with fallback semantics. And the project's own honesty constraint is unusually strict: its design doc states that a compiled addon is not a measured acceleration, and its performance gates are defined on completed-frame throughput on real devices, not microbenchmarks.
The counter-argument, and it is load-bearing: the bar the Wasm kernels must beat is not the JavaScript interpreter. It is V8's JIT, which already optimizes closed numeric loops aggressively. A closed, side-effect-free numeric loop is exactly what modern JITs handle well. That compresses the headroom the project's 2×/3× targets need, and it is why the maintainer refuses to claim a speedup he has not measured.
03 · What was built
What the project actually built
The demonstrated slice is the MarchingCubes addon: the three.js demo that turns a volumetric field into a surface mesh, the familiar metaball blob. The pipeline: the ingest CLI's specialization flag routes the addon's triangulate body through the compiler into a Wasm kernel; a rollup plugin branches the numerical prefix of the addon's update around the compiled kernel; runtime guards re-verify the closed-world assumption on every entry.
The finding that matters is the differential harness. It runs the compiled kernel against a live instantiation of the actual pinned upstream r186 MarchingCubes class. All 256 cube topology cases times 8 flag combinations (2,048 kernel invocations per sweep), plus animated metaball sequences, 80 seeded random fields, and empty/NaN edge cases. Bit-comparable output is asserted throughout, with diagnostics requiring exactly 256 Wasm calls and zero fallback calls. The program's assessor independently re-ran all three gated suites on 2026-09-22: 61 of 61 pass in about 21 seconds on Node v24, against a sparse three.js checkout whose oracle blob hash was verified before use.
The second finding is what the project refuses to claim. The README states, verbatim, that zero speedup has been measured. The specialization doc: "A compiled addon is not a measured acceleration." The 2×/3× headline gates are targets, not results. "Will it hit 3×? Unknown. Nothing has been measured.
Evidence · CI status
What the project’s own CI said at the pin
- ✓It executes in CI (continuous integration: automated checks that run on every change), green at the pin (the commit the assessment was pinned to).
- !No" and lists two crates, while a compiler and CLI execute in CI and the workspace holds four; AGENTS.md still says the project has "zero implementation".
The uncomfortable findings
Uncomfortable finding
The public status surface is stale: the README's status table still says "Is there a compiler, renderer, or CLI? source All of this describes a project roughly ten days and 280 commits older than the pin. The staleness reaches inside the safety contract: the compiler's own refusal tests still demand rejection of x[i]++, which the compiler has since legitimately learned to compile. The test suite disagrees with the compiler it guards. And CI gates only the marching-cubes exemplar, not the compiler's full contract. Velocity is extreme (380 commits in 13 days), with Claude-Session links and named agent personas in commit bodies but zero Co-Authored-By trailers, so no outside reviewer can determine which artifacts agents produced or what the review gates were. And the license is MIT plus a rider barring OpenAI and Anthropic — the entities best equipped to evaluate a JS-to-Wasm compiler — from even analyzing the code. source
04 · Where it stands
Where it stands
In our program's terms: TRL 3–4, NODUS ring Explore. In plain English: the numeric-kernel slice is lab-validated. Real Wasm, real parity, green CI. But the application specializer as a whole sits at TRL 2–3. No renderer, no end-to-end specialized app, no measured frame on any device. Substantive but unproven.
Technology readiness
TRL 3–4 on a 1-to-9 scale.
NODUS ring
MonitorExplorePilotInvest
The program’s adoption ring for this project.
Verdict key
- NODUS ring
- Explore: The default for substantive-but-unproven work.
- TRL
- Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 3–4.
- CI
- Continuous integration: the project’s automated checks, run on every change.
- The pin
- The exact commit the assessment was pinned to. “At the pin” means as of that commit.
Evidence tiers
- Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
- Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
- Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
- Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
- Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.
What this verdict rests on. Tier labels are the assessment packet’s own annotations.
- Tier 1 · Verified: The assessor independently re-ran the marching-cubes differential suite: 61/61 pass; no tags, no releases.
- Tier 2 · CI-observed: The suite executes in CI, green at the pin.
- Tier: unassessed in packet: No measured frame-time number exists — the load-bearing missing evidence.
- Tier 4 · External: No independent validation.
- Tier 5 · Inference: The Explore ring at TRL 3–4.
Should you use it?
No.
There is no release, no measured workload, no independent validation.
Should you learn from it?
Yes.
The exportable artifact is the differential-parity admission pattern: closed body to compiler to import-free Wasm to exhaustive oracle comparison to CI gate. That is a reusable template for any project that compiles one language's hot loop into another's. And the "0× baseline" discipline (publish the overhead ledger before the speedup claim) is the honest order of operations.
What would change the verdict, in order
- one measured frame-time number on a real app. Even a sub-1× result, published with the overhead breakdown: a measured loss falsifies the thesis the way the project's own kill gates demand. Also: a second kernel from a different loop class (animation or skinning, not another closed numeric) passing the same differential gate
- any of the twelve kill-gate beads recording an actual PASS/FAIL decision.
Until then, the rational posture is the one the packet's own steelman recommends: admire the evidence machinery, mine the differential pattern, don't depend on the specializer.
05 · What it teaches
What this teaches about building with agents
Machine-check your claims, not just your code.
At roughly 29 commits a day, this project's own status table went stale within ten days. The "status table" claimed "no compiler" while a compiler ran in CI. The maintainer's disavowals are exemplary; the drift is the lesson. Prose candor decays at agent velocity. The project's own proposed fix is the takeaway: turn the status table into a CI check that fails when a row disagrees with the tree. Convert the self-audit discipline from documentation into a test.
The generalization: when agents write code faster than anyone can read it, the governance that survives is the kind a machine enforces. Status pages, contribution norms, refusal contracts — anything a human must remember to update will go stale. Gate it in CI or watch it rot. And keep the kill gates first-class: this project's plan defines twelve, with explicit pass/fail decision records. A gate that has never fired is a decoration. The experiment the project's own self-audit constraint demands is the one that would make the gates real: measure the frame-time delta, and publish it whatever the sign.