A-Frame 1.8.0 Ships, and the Independent WebXR Framework Just Quietly Grew Up

Open-source projects almost never get big splashy launches. They get changelogs. And this month, the WebXR world got one that is worth paying attention to.

A-Frame 1.8.0 shipped, and while its release notes look like every other quiet maintenance drop from a mature open-source project, this one is a small tell about where the browser-first VR world is heading. The most-used framework for building WebXR scenes without JavaScript-heavy boilerplate is now caught up to modern Three.js, has finally retired its Oculus branding, has dropped WebVR support entirely, and quietly fixed a bug that was preventing developers from correctly requesting the exact feature the W3C just moved forward this month, WebXR Layers.

None of that is a headline that gets a keynote. All of it matters if you are one of the people actually building on the immersive web.

What actually shipped

A-Frame is the HTML-first framework for VR and AR in a browser. You write scene markup like it is a webpage, and the framework handles Three.js underneath. That means whenever Three.js moves forward, A-Frame has to move with it. Version 1.8.0 catches the framework up to Three.js r184, closing a gap that had been growing since Three.js started leaning harder into modern rendering primitives and its ongoing WebGPU transition.

The maintainers also shipped more than twenty bug fixes and about fifteen improvements aimed at controllers and peripherals. Some are unglamorous: recycling internal component objects to prevent memory leaks, better pooling on the component update path, fixes on the WebXR input-source detection so controllers no longer rely on a polling loop and instead react to the standard inputsourceschange event. If you have ever profiled a WebXR scene on a mobile Quest and watched the frame budget vanish into garbage collection, these are exactly the kind of fixes you want.

Others matter more than they sound. The release includes a fix for a typo in the requiredFeatures list that was affecting layer requests. That is the kind of change that gets one line in a changelog and never a blog post. It is also the thing that determines whether your Quest browser session can actually use the compositor-based layers that the W3C moved to a Working Draft on 12 June 2026. If you were trying to prototype against WebXR Layers Level 1 in A-Frame in the last few weeks and getting nothing, that one-character fix is why.

Meta Touch, not Oculus Touch

The rename in 1.8.0 is the kind of janitorial work that only open-source maintainers ever get around to. The controller component previously called oculus-touch-controls has been renamed to meta-touch-controls to match the actual current branding on the hardware.

Meta stopped shipping devices under the Oculus brand back in 2022. A-Frame's controller component kept the old name because renaming a public API is disruptive, and years of tutorials and Stack Overflow answers still reference the old path. The 1.8.0 change finally closes the gap between what you type in your scene and what is written on the box. That matters if you are new to WebXR and trying to read documentation without knowing that Oculus and Meta are the same brand for the same controller, or if you are onboarding a junior developer who has never heard the word Oculus at all.

A-Frame also finally removed the last vestiges of WebVR support in this release. WebVR was deprecated years ago in favor of WebXR, and browsers have long since dropped it, but old code paths persisted in the framework's codebase for backward compatibility. Cleaning them out makes the codebase easier to reason about for new contributors and cuts a class of bugs that only affect devices nobody has anymore. It is closing time on an entire generation of browser VR.

The unglamorous math of open-source WebXR

A-Frame does not have a marketing team. It is maintained by a small group of contributors working around day jobs, and its release cadence looks like it. Version 1.7.1 shipped, then months of quiet, and now 1.8.0. This is the exact rhythm of most independent WebXR tooling. The commercial platforms release monthly with keynote-quality messaging. The open web catches up when someone has time.

What has changed in 2026 is that keeping up is easier than it has been in years. The Interop 2026 initiative is publicly tracking browser gaps in WebXR. The Device API just hit Candidate Recommendation at W3C on 9 June. The Layers API Level 1 followed with a fresh Working Draft on 12 June. Chrome, Meta Quest Browser, Samsung Internet, and Safari on visionOS are all moving in the same direction at more or less the same time. That means an incremental release like A-Frame 1.8.0 does not have to reinvent input handling for every browser. It just has to bind to the standard event, ship the fix, and move on.

The pattern is repeating across the open ecosystem. Three.js keeps shipping WebGPU-first releases with r184 as the current line. Babylon.js keeps polishing its integrated WebXR manager. Godot 4.7 landed this month with a growing XR asset store on the side, and it is starting to show up seriously across the industry from Android XR to visionOS. None of these projects are, on their own, a threat to Unity or Unreal in commercial VR. Together, they are quietly building a WebXR stack that a solo developer can actually use to ship a real thing without a platform account, an SDK license, or an app store review.

That is the story A-Frame 1.8.0 is telling. It is a small release that will make no one's homepage. It matters because the stack it lives in is finally growing up. And if you have been putting off writing your first WebXR scene because you assumed you would need a Meta developer account and a build pipeline and a native toolchain, this is the release that says: no, actually, an HTML file and a browser are still enough.