Why You Should Be Paying Attention to WebXR

And What it Could Mean for the Future of Virtual Reality and Augmented Reality

Web-XR-image 030520 First things first: what is “XR”? It’s a somewhat abstract term that is meant to call to mind VR (Virtual Reality) and AR (Augmented Reality) and is sometimes considered “eXtended Reality.” More commonly, the X is considered to be a placeholder for the spectrum of reality-enhancing technologies.

As hardware platforms evolve and converge into devices that can support both VR and AR (and even AR in VR), the “X” stands for the future of this technology: it intends to support whatever comes next.

What is WebXR?

All right, so how about WebXR? As you might suspect, this is a technology (formally known as the WebXR Device API) that allows XR compatibility via web technologies, namely HTML, CSS, and JavaScript. In fact, WebXR originally was split in the same way as hardware is generally categorized currently: into WebVR and WebAR.

The team behind WebXR has combined these frameworks and created a forward-thinking and straightforward set of goals to integrate XR technologies into our browsers:

  • Detect if XR capabilities are available
  • Query the XR device capabilities
  • Poll the XR device and associated input device state
  • Display imagery on the XR device at the appropriate frame rate

Benefits of WebXR

This simple standardization has incredible potential in the field of XR development, particularly when combined with frameworks/tools such as A-Frame, three.js, and React360. It provides:

  • Interoperability: in the web context, this means that it is compatible across browsers, operating systems, and devices.
  • Accessibility: many developers don’t have familiarity with C# or C++, which VR developers used to need to build projects in Unity and Unreal. With WebXR, every web developer knows enough to get started.
  • Modularity: it achieves its goal of allowing XR content to be displayed in browsers, and nothing more. It’s not opinionated about how that content is built or what device is used to display it. Developers can plug in whatever libraries are optimal for their use cases and build from there.

Why Standardization?

Consider when developers first started to build apps for smartphones: it was simple to support what was out there because there weren’t many options. In the same way, it was straightforward to build for the Oculus Rift DK1 when that was the major VR headset to build for. However, it didn’t take long for the smartphone market to explode, and suddenly there were dozens of screen sizes and different options to support, turning mobile development into a much more complex operation.

XR is no different: there are now lots of headsets, frame rates, and supporting capabilities. A standard that allows developers to easily build for all (or at least most) devices and browsers provides a radical simplification that has the potential to be very valuable: both for the developers and for the overall proliferation of XR tech to general consumer use.

WebXR intends for its applications to work in a flat, non-XR mode as well, but users are prompted to view using whatever their device’s XR capabilities are, encouraging use of XR features while remaining accessible to those who may not have them or don’t wish to use them.

Mozilla WebXR example

An example of a WebXR app rendered in a flat web view, a VR headset,
and handheld AR. (Source: Mozilla’s Mixed Reality Blog)

What’s Next for WebXR?

As WebXR continues to evolve, it could integrate in even more natural ways, encouraging the use of XR with devices that people already have on hand instead of the need for expensive hardware that many currently expect (while still supporting those expensive devices for those who do have them). It will affect various parties:

  • Consumers: Everyday users become more familiar with XR in their lives through regular use of the web.
  • Businesses: As consumers acclimate to this changing landscape, WebXR gains more value to businesses looking to leverage the new media for marketing, training, and generally increasing customer engagement. WebXR should also allow for easier, more standardized deployment and use of immersive technologies within businesses and across organizational networks.
  • Developers: This becomes a self-feeding loop: as more businesses want XR experiences that are broadly accessible, more web developers make the transition into XR work without the hurdle of learning entirely new platforms and are able to deliver content to growing audiences of consumers.

Of course, WebXR is currently in its early stages. While it’s certainly usable, those who want to create VR or AR experiences that fully take advantage of their technology’s capabilities are likely better off using Unity/Unreal (VR) or native ARKit/ARCore (AR). And big players in the industry may choose to gain business advantages by maintaining proprietary hardware/software and not fully supporting interoperability, which could limit WebXR’s ability to grow.

Regardless, CrossComm is excited to keep an eye on WebXR and where it’s going as we continue to implement solutions in the XR space.