Volume 06 · synthesis

Where glyph3d-js Sits

Locating glyph3d-js in the taxonomy of the previous five volumes: the slot it occupies, the projects that occupied it before, why the slot keeps emptying out, and the references that anchor the lineage.

The first five volumes are a survey of the field. This one is bookkeeping: given that map, where does glyph3d-js fall on it, and what's the company in that neighborhood — past and present.

The slot

The combination that defines it:

• Renders the actual source text — real glyphs, as the visual primitive. Not buildings (the city tradition), not nodes, not an LLM's summary.
• Whole repo at once — the entire codebase in one navigable space, not one file in an editor pane.
• GPU-instanced at scale — one draw call across all the glyphs, not a mesh per text run (where troika and friends stall at a few hundred).
• Browser-deliverable — no headset, no Unity build to download; a URL.
• Maintained and openable today — not a thesis PDF, not an archived repo, not a "lights are out for now" page.

Drop any one requirement and the slot has occupants. Drop renders text and the city tradition fills it. Drop whole repo and it's Primrose, Zed, every editor. Drop GPU-instanced and it's troika demos. Drop browser and it's Code Park, CodeHouse, VRIDE. Drop maintained and it's Code Canvas, Codemap/pfff, most of the graveyard. Across the search behind these notes, the count of other tools meeting all five at once is zero.

Who got closest

Six prototypes (and one company) covered real distance toward this. Each failed in a way worth recording — the failures aren't about the idea:

• Code Park — UCF / LaViola, 2017. 3D rooms, real syntax-highlighted source on the walls, walkable, real C# projects. The closest published 3D precedent. Failure mode: it was a master's thesis — Unity, never open-sourced, no successor.
• Code Canvas — Microsoft Research, 2010. An infinite zoomable plane of every file, editable in place, semantic zoom, overlays. The closest UX precedent. Failure mode: never released; only the debugger-overlay slice shipped, as Debugger Canvas, which is itself now retired.
• CodeHouse — Hitachi, 2019. Code Park's instinct in VR, from a corporate lab. Failure mode: never released; one paper, one video.
• Primitive — commercial, ~2017–2020. Real codebases, millions of lines, VR, IDE plugins, org licenses. Failure modes: it rendered architecture (graphs, blocks, labels), not source text; and it ran out of funding.
• VRIDE — Universidad de Chile, 2021. Pharo/Python source on cube faces in VR, full browser/inspector, repo public. The closest open-source precedent. Failure mode: Unity, solo thesis project, dormant since 2021, not repo-scale.
• Codemap / pfff — Padioleau / Facebook, ~2010–2016. Real semantically-highlighted source, whole monorepo, zoom-to-read navigation. The closest on fidelity at scale. Failure mode: 2D, and it went quiet — never became a maintained general-purpose tool.

Of the six: three were academic artifacts with no path past publication; one ran out of money; one was a solo thesis; one went quiet. None failed on the merits of the idea, and the idea kept being independently re-derived — which is the part worth noting. What's been scarce is the transition from "prototype that exists" to "tool that's still openable and still maintained."

Why the slot stays empty

Three structural forces, drawn straight from the previous volumes:

1. The metaphor is cheaper to render than the text. A few hundred buildings is a 1996-era graphics problem. Tens of thousands of legible glyphs at sixty frames a second in a browser is not — the standard web text libraries stall at hundreds of instances (troika #117 is the canonical case), and the standard way to render code on the web — DOM-based editors, Monaco and CodeMirror — collapses well before "the whole repo, visible." So the field reached for buildings, which is why the city tradition dominates the literature and the rendered-text branch is thin. glyph3d-js renders glyphs as GPU instances in a single draw call across the field — the architecture the Three.js text libraries don't use, and the one the Web3D 2024 instanced-glyph work measured as scaling.

2. VR carries a field-of-view cost. Code Park, CodeHouse, Primitive, IDEvelopAR, VRIDE all put the reader inside a room or a headset, which narrows the legible code to roughly one class at a time and adds the eye-strain documented in the Reading-in-VR work; the Clemson studies found programmers can comprehend code in immersive 3D but at higher cognitive load than on a monitor. glyph3d-js is screen-based 3D — spatial layout and navigable depth, no headset — which keeps the whole-repo overview without the per-glance narrowing. The VR cohort couldn't take that option because VR was the premise.

3. Shipping and maintaining is the scarce part. The graveyard is theses, archived repos, and shut-down hosting — not bad ideas. The work almost nobody did is packaging it so a stranger can run it, keeping it building, and iterating on what they say. glyph3d-js's form factor is built around that: a single Go binary (embedded IDE, HTTP + WebSocket, sandboxed filesystem, ~8 MB) plus a public deployment. The five prior occupants of this slot had no recorded users; this one has had users and their feedback. Whether it stays out of the index above is, at this point, an execution question rather than an open research one.

The citations

References that anchor the lineage glyph3d-js sits in — useful for a paper, a pitch, or a README:

Summary

The idea of rendering a whole codebase as readable text you move through has been arrived at independently since at least 1992 and built, in some form, at least six times. What's been missing is a maintained, browser-deliverable implementation that renders real source at repo scale. That's the slot. glyph3d-js is an attempt to occupy it; whether it does is a function of execution, of which user feedback is the relevant input — the previous occupants didn't get that far.

← back to the index  ·  01 · 02 · 03 · 04 · 05