ar.js vs. a-frame ar

by Michael Colonna

WebAR

Developer-ready mobile AR has been around for years with Apple's ARKit and Google's ARCore libraries. However, these AR applications rely on the processing power of a user's mobile device for plane detection and 3D model rendering, which are computer vision and graphics problems that can be expensive processing tasks for a smartphone. 

WebAR seeks to democratize high-fidelity AR experiences for users and developers. Leveraging the power of WebGL and fully fleshed-out VR libraries like A-Frame, a handful of WebAR libraries available have significant power and can create experiences that can be accessed by anyone with a mobile browser!

In this library review, I will be comparing the WebAR libraries AR.js and A-Frame AR. I will be discussing aspects of each library that I encountered while developing two simple applications with both libraries. Below is a table summarizing my results:

Supporting Libraries

AR.js

AR.js is built on top of A-Frame, three.js, and ARToolKit. It leverages ARToolKit to perform vision systems crucial to the AR experience, such as marker and plane detection. three.js is used to create and display 3D models, while A-Frame is used for its simple HTML-based Entity-Component structure that makes app development rapid and easy.

A-Frame AR

A-Frame AR is also built on top of A-Frame, and enables AR support for A-Frame using the three.ar.js library. Because both libraries use A-Frame for their structure, development for A-Frame AR is very similar to AR.js. However, A-Frame AR is only usable with the experimental browsers WebARonARKit/Core by Google and WebXR Viewer by Mozilla.

Support for Mobile and Desktop

AR.js

AR.js supports any device with a camera – i.e. mobile and desktop. I was able to get it to run on Safari on my iPhone 7 running iOS 12.2 using the https protocol. I was NOT able to get it run on Chrome on the same device. However, I WAS able to get it to run on Chrome on my MacBook. 

A-Frame AR

A-Frame AR only supports the above mentioned experimental browsers. I was able to get A-Frame AR apps to run on both WebARonARKit and WebXR Viewer, with similar experiences for both browsers.

Performance

AR.js

AR.js is a surprisingly capable library, capable of delivering AR experiences at a consistent 60 fps during display on both desktop and mobile. There was no drop in performance when interacting with 3D models either, on both desktop and mobile. This is most likely due to the marker-based system, which is an efficient method of doing fast plane detection.

A-Frame AR

Though capable of more environment-based experiences than AR.js, A-Frame AR lags behind the former library in terms of performance. Displays of 3D models were often laggy, and plane detection was faulty. In addition, when interactions with models were added, latency between events and results increased significantly. These could likely be due to the experimental nature of the AR browsers, which often crashed due to lack of memory.

Marker-based?

AR.js

Yes. AR.js is a marker-based system, enabling quick and efficient plane detection and model positioning. Being marker-based allows the library to create AR apps that utilize markers, which could, for example, be ideal for educational content and certain marker-based games. It also enables interactivity with the app from participants without control of the device being used, e.g. kids in a classroom moving the markers around on a table to see how the content being projected responds to the interaction. However, being marker-based limits these apps somewhat as well, as the marker must always be clearly within the field of view in order for models to be displayed properly.

A-Frame AR

No. A-Frame AR is not marker-based. In some ways, this allows A-Frame AR to create experiences that are "true" AR, i.e. not relying entirely on exterior markers. In the future, I believe this will allow A-Frame AR greater flexibility in the web AR development process, as researchers learn how to incorporate more efficient computer vision algorithms into the library. However, for now, the lack of a marker-based system leads to faulty plane detection and inefficient rendering and updating. The tech just isn't quite there, yet.

Hello World

AR.js 

Creating a Hello World app with AR.js was very easy (it only took ~10 lines of HTML!). Combining the rapid turnover of a web code editor like Glitch with the HTML-based Entity-Component structure of A-Frame makes web development rapid and effective. The marker-based system enables quick and accurate plane detection on which to place my 3D models. Event interactions are easy to incorporate, and respond rapidly to user input.

A-Frame AR

Creating a Hello World app with A-Frame AR was also easy, although a relatively non-insignificant amount of time must be dedicated to setting up one of the experimental browsers. Like AR.js, the use of a code editor like Glitch combined with the structure of A-Frame makes development quite rapid and effective. However, the inability to debug using the desktop browser console, the crashes of the experimental browsers, and the general lack of performance for the final web apps was disappointing and at times frustrating.

Conclusion

Both AR.js and A-Frame AR are powerful libraries that leverage the power of WebGL to bring AR experiences to the web. In terms of which library you should use to develop your next AR web app, there are pros and cons to both libraries.

The marker-based system of AR.js makes it well-suited for informative applications based on markers (e.g. in a school or museum) or marker-based games (think Skylanders). This system also enables high performances by simplifying plane detection. For developers looking to get into WebAR, this library offers a great chance to hit the ground running, with lots of support and documentation, being built off of well-supported libraries like three.js and A-Frame.

In theory, the non-marker-based system of A-Frame AR makes it a more flexible library. In the future, I predict that if Google can integrate its WebARonARKit/Core experimental browsers with Chrome and Mozilla can integrate WebXR Viewer with Firefox, then A-Frame AR will overtake AR.js for being the go-to web AR development library. However, as it currently stands, the technology that A-Frame AR is based on is simply not ready for production-level apps. The experimental browsers are buggy and introduce significant lag, making for a frustrating experience for both developers and users.

So, if you were to create a web AR app today, I'd say, without a doubt, go with AR.js! If you plan to make a bet on the future of web AR and want to get in on some ground-level web AR libraries being built by top tech companies, then check out A-Frame AR as well!