For a stretch of 2021 and 2022, it looked like computing was about to move somewhere else entirely. Meta rebranded around the idea, Microsoft bet HoloLens and Mesh on it, and a wave of startups raised on the premise that avatars and virtual land were the next platform shift — on the scale of mobile after the web. Reality, the pitch went, was just one interface among several, and not necessarily the best one.
Then the capital dried up, the headsets stayed in drawers, and generative AI took over every keynote slot the metaverse used to occupy. Augmented reality didn't get a rebrand or a eulogy — it just went quiet.
That quiet turns out to be useful. Once you strip away the promise of replacing reality wholesale, what's left is a narrower, more tractable engineering problem: how do you register digital content to physical space accurately enough, and cheaply enough, that it's worth doing at all?
Virtual worlds assumed people wanted an alternative to physical space. Most contexts where technology actually gets used — classrooms, labs, hospitals, workshops, museums — don't work that way. Nobody wants to put on a headset to replace a dissection table; they want something layered on top of it.
That reframes the interesting question. Not "what if we replaced the physical world," but: what's the minimum viable way to attach information to a specific point in physical space, and have it stay there as the user moves?
That's a tracking and rendering problem, not a platform problem. A chemistry student manipulating a rotatable molecular model gets more out of six degrees of freedom on a real desk than out of a mouse-drag on a 2D projection. An anatomy student benefits from a heart they can walk around. None of that requires an immersive world — it requires accurate spatial anchoring and a rendering pipeline that runs on a mid-range phone.
Most science pedagogy is still built on projections of 3D structure onto flat media — textbook diagrams, static slides, pre-rendered video. That's a reasonable compromise when the alternative is expensive lab equipment, but it has a specific failure mode: anything where spatial relationships carry information (protein folding, orbital mechanics, stratigraphy, tensor fields) gets flattened into a representation that hides the thing you're trying to teach.
AR doesn't fix pedagogy by itself — plenty of AR experiences are gimmicks with no learning value. What it changes is the input: instead of inferring 3D structure from a 2D projection, you register the 3D object in your own frame of reference and let parallax and occlusion do work that annotation used to have to do manually.
We tested this directly with AstroFlow, a university project combining WebXR-based 3D visualization with device AR, covering astronomical structures and human anatomy.
The interesting part wasn't the final experience — it was how little specialized infrastructure the pipeline needed.
Pipeline: research → architecture → UI design → prototyping → asset production → implementation → animation → deployment → maintenance.
A few years ago, "building AR" meant native development against ARKit or ARCore, a computer vision background helpful for anything beyond marker tracking, and either Unity/Unreal or a hand-rolled OpenGL pipeline. That's a real barrier — it selects for teams with existing 3D engineering experience.
The WebXR Device API changes the economics, not because it's more powerful than native SDKs (it isn't — you lose some low-level camera and depth API access), but because it collapses distribution to a browser link. navigator.xr.requestSession('immersive-ar')
, a hit-test source, an anchor, and you have a session without an app store review cycle. For education specifically, that's not a minor convenience — it's the difference between "install this app before Tuesday's lab" and "click this link."
Combine that with Blender's glTF export pipeline (which handles Draco compression and PBR material export cleanly enough now that most beginner mistakes are poly count, not format), and a huge amount of the traditional AR skill floor disappears. You still need to understand coordinate spaces, anchor drift, and lighting estimation if you want something that doesn't look obviously fake — but you don't need six months of computer vision coursework to place a rotatable model on a desk.
If someone wanted to start from nothing, the sequence that actually gets you to a working demo fastest looks roughly like this:
immersive-ar
session type, hit-test API for surface detection, and anchors for keeping content spatially locked. This is where most of the actual learning curve lives — session lifecycle management and reference space types (local
, local-floor
, bounded-floor
) trip up almost everyone at first.Don't start with a multi-user persistent world. Start with something you can describe in one sentence and implement in an afternoon: place the solar system on a desk.
GLB model (Blender export)
↓
Three.js scene graph
↓
WebXR hit-test → surface detected
↓
Anchor created at hit-test result
↓
Model attached to anchor
↓
Rendered via ARCore pose tracking
↓
Visible through phone camera, spatially locked
Once that pipeline works end to end, the next questions are the ones that actually matter: Does the object respond to touch input? Does it carry queryable data (tap a planet, get orbital parameters)? Does it need to persist across sessions (cloud anchors), or is per-session tracking enough? Can more than one device see the same anchor at once? Those are real engineering problems, and they're much easier to reason about once the base pipeline isn't the bottleneck.
The metaverse's collapse removed the pressure to make every AR demo look like a platform launch. That's arguably better for the technology, not worse — it means the interesting work is happening in contexts that don't produce keynote moments: anatomy visualization, geological cross-sections, molecular modeling, museum object reconstruction, engineering prototypes viewed at scale before fabrication.
None of that requires convincing anyone to wear a headset eight hours a day. It requires a tracking pipeline accurate enough to be useful, a distribution model light enough that a student opens a link instead of installing an app, and content pipelines cheap enough that a single developer with Blender and a phone can ship something real.
That's a smaller claim than "the next computing platform." It's also one that's already true.