The Immersive Web and WebXR Matter More Than Ever

disclaimer: the below represents my thoughts and opinions and are not representative of Frame or Virbela at large. - Gabe Baker

The Immersive Web Matters More Than Ever

The ongoing kerfuffle between Apple and Epic Games, a legal wrangle which puts Epic's Unreal Engine at risk as a viable creation tool for iOS and Mac apps, has made clear that native 3D app development pipelines aren't as secure as developers need them to be. Unity3D developers had a collective sigh of relief, and they might be feeling even more relieved now that Unity revealed their plans to IPO.

That's all good and fine, but it's worth remembering that Facebook floated the idea of acquiring Unity a few years back. That is to say: Unity3D and their developers are not immune to the vicissitudes of app store economics, distribution models, subscription models, and the tenuous, shifting relationships between technology giants that keeps the ecosystem of native 3D app development and distribution chugging along.

Facebook, a company willing to take a well-funded stab at just about anything, now seems to be getting into the 3D creation space. Their new Horizon creator tools give a glimpse of what might be in store for the future. It seems likely that stuff built with those tools, though, will work exclusively on Facebook VR hardware.

The Pull: The Web Can Be The Win We Need

Amidst all of this native app development tumult, the web browser is often seen as a bastion of hope. A garden with no walls. A place where the utopian dream of cross-platform, standards-based technology can be realized without fear of having the keys to the development kingdom snatched away by any particular company next month. A development pipeline where you really can "build once, deploy everywhere". Desktops, chromebooks, mobile devices, VR headsets - generally speaking, they all have a browser.

For 3D experiences in particular, the new WebXR browser API makes it possible to create immersive experiences that run right from the browser and can be displayed across devices and displays: mobile devices, desktop, chromebook, VR headsets, AR hardware, etc. Rather than using proprietary, third-party engines, developers can use traditional web development languages, tooling, and standards to create immersive sites/experiences.

Sounds dreamy, right? So why isn't WebXR already huge?

The Catch: Who Wants The Web To Win?

There are plenty of people interested in helping the web become a viable, low-friction platform for experiences of all kinds. The FRAME team relies on WebXR, for example, as do projects like Mozilla Hubs and many others. Developers who want to work outside of proprietary engines love the freedom that WebXR provides, and they love the ability to create no-download experiences for users that can work across devices and operating systems without needing separate build processes.

Beyond just taking advantage of WebXR, we're willing to invest in its sustainability and evolution. Really - anyone who was recently let go from Mozilla who wants a job that lets you work on WebXR standards, please reach out.

There are also many users who appreciate being able to visit websites without being forced into downloading apps. Many corporate work environments prefer browser-based tools instead of desktop applications.

This is great, but the dream of WebXR can only be fully realized if web browsers support the API. In other words, this vision can only be a reality if organizations that build web browsers are committed to seeing the web be a viable vehicle for powerful experiences, a vehicle that cruises happily outside of any app store economics. This isn't to say that WebXR stuff needs to be free. Companies have been charging for browser-based SAAS since the web browser has been around.

So, what's the current state of browser support for WebXR? And what does the trajectory look like for the future? TLDR - it's murky, browsers aren't all the same, and maybe we need to rethink the overall concept of the "browser".

Mozilla

From the beginning, Mozilla was one of the biggest drivers of WebVR/WebXR and open source development frameworks built on top of it. They also built one of the browsers that can run from stand-alone VR headsets and AR hardware: Firefox Reality. Just recently, however, they laid off 250 people, including many of the people working on WebXR standards. Mozilla then followed this up with a somewhat vague but encouraging blog post about how they are continuing to invest in web standards, while reducing investments in other areas. They are also continuing to invest in Hubs, a WebXR-powered site.

As a whole, things seem a little bit in flux. Mozilla also doesn't seem to have any viable, sustainable revenue stream outside of a deal they with Google that makes Google the default search engine in Firefox. These are troubling signs, and it's not clear to me that the Firefox browser specifically, or the Mozilla organization at large, has a viable future. This is a shame for many reasons, including what it might mean for the future of WebXR and the web at large.

But hey - surely the future of WebXR doesn't hinge on an underdog organization like Mozilla? Surely some big companies are doing what they can to pave the way for the success of WebXR? Right?

Let's see how other browsers treat WebXR. Sadly, it's certainly not the case that "if it works on one browser, it will work on the others".

Apple

Apple, for one, seems invested in keeping iOS Safari just shitty enough so that people are forced into using mobile apps to access any powerful experience. Apple likes this because it means more $$ from app-derived revenue. So it's no real surprise that Safari doesn't yet support the WebXR API, although there are rumors that this is in the works. As Apple readies their own immersive hardware, it remains to be seen whether they want Safari to be an actual gateway for 3D experiences, or if they will push everything into native applications.

If Apple wants to neuter Safari on Apple Glasses, or not even have Safari be an application on it, then the future of WebXR is made even murkier. It also wouldn't be unlike Apple to try to push "their own version" of WebXR - another unhelpful move. If anyone from Apple is reading this - please embrace WebXR and help give XR a future outside of native applications. Or, at the very least, let other browser engines run on iOS so that Chrome and Firefox aren't just awkward skins of Safari.

Microsoft

Microsoft has been doing great work in the WebXR space. The new chromium-based Edge browser has solid WebXR support, they have people contributing to the WebXR standards, and Microsoft is investing in their own WebXR development framework, Babylon.js. They are also ensuring that WebXR will work on devices like the Hololens. Nice work, Microsoft! FRAME, for one, runs really nicely on the new Edge (a welcome step up from Internet Explorer).

The catch with this new chromium-based Edge is that this shift makes the web ecosystem more reliant on the chromium engine, the engine that powers Chrome (among other browsers). This has pros and cons. For those interested in learning more about that, there are smarter people than me who have written thoughtful things about the implications of the new Edge. For the purposes of this article, Microsoft seems committed to supporting the WebXR ecosystem with Edge and their own development tools.

Google

Google likes WebXR. Google is heavily invested in Chrome because Chrome is a key piece of their advertising engine. The idea of people using Chrome instead of using a native app is probably bit more palatable to Google than it is to Apple. Chrome is usually the first to adopt some of the more experimental Web APIs (some people are frustrated at how quickly Google does this), and Chrome was the earliest adopter of the WebXR spec. There are people at Google doing great work on supporting WebXR. In fact, with the retirement of Daydream headsets, Google's key contribution to VR overall right now largely seems to revolve around tools that support 3D from the browser, including but not limited to WebXR.

Oculus

The Oculus Browser is a chromium-based browser that runs on the Oculus Quest, the standalone VR headset from Facebook. It has solid support for WebXR, and the Oculus Browser team seems committed to making the Oculus Browser a great vehicle for the immersive web via WebXR. FRAME runs from the Oculus Quest just fine from the Oculus Browser, and because of this we didn't need to rely on Facebook approval to make it into the official Quest App Store. This is a big deal. Unsurprisingly though, the Oculus Browser only runs on Oculus hardware. Other immersive hardware like the Hololens or HTC stand-alone VR headsets use Firefox Reality, a browser whose future is murky.

Many developers, outraged at the role Facebook has been playing in the fabric of our society and democracy, are now wondering how committed they want to be to a Facebook VR ecosystem. If WebXR is just a way to publish immersive web experiences to the Oculus Quest, then the promise of WebXR isn't being realized - it's just another way to publish to Facebook VR hardware (see Greg Fodor's twitter for the articulation of these concerns). This is why other VR browsers like Firefox Reality can play such an important role in the WebXR ecosystem.

Samsung Browser

The Samsung Browser is great. It's a browser that comes baked into Samsung Galaxy mobile hardware. At a high level, I think people are sleeping on it. It has solid support for WebXR and people on the Samsung Internet team are involved in the working standards group for WebXR. Samsung - make a browser that works on other hardware!

Final Thoughts

Apple's Safari alone, given its prevalence, makes the entire WebXR ecosystem a bit tenuous. Web browsers are complicated beasts, and integrating WebXR support is no small feat. Integrating anything into a modern web browser seems arduous, given the eye-popping complexity of web browsers themselves. There are lots of thoughtful people advocating for a re-think of the web browser. Instead of monolithic browsers that do it all, why not have smaller, focused micro-browsers that are dedicated to doing certain things particularly well, rather than trying to shoehorn an entire world of web standards into one clumsy beast?

The Supermedium project, which started out as a browser dedicated to the immersive web, was an early step in this direction and was arguably way ahead of its time. This seems like an interesting idea, but if Apple still doesn't let non-Safari browsers on iOS devices, this still doesn't solve the Apple problem. There's a bit of a chicken-and-egg problem here, too, as sometimes Apple doesn't adopt certain standards until big players and services begin to rely on them. The history of WebRTC adoption in Safari is instructive here.

Heck, maybe this whole WebXR thing is an attempt at making web browsers do what they shouldn't be trying to do.

However, when I see people using FRAME right from the web, with no download/install/nonsense, and loving that they can access it this way, I can't help but think that the immersive web matters.

It seems to matter now more than ever.