Hello everyone,
Today, I’m excited to announce a project I’ve been working on for some time: XR-Tag, a web framework for creating games and experiences in HTML.
As you can probably guess, XR-Tag is intended to be Babylon’s answer to A-Frame. However, whereas A-Frame places a heavy emphasis on using the Entity-Component-System pattern, XR-Tag relies on Babylon’s Observables, resulting in cleaner, less complicated, more performant code.
Some key features:
- Declarative HTML: I used A-Frame as an example of what not to do. Look at any medium-sized A-Frame project on GitHub, and your head will quickly get dizzy as you race back and forth between files, trying to figure out what each element is used for. With XR-Tag, you should be able to look at any given line and say, “Yes! I understand the purpose of this!”
- Event-driven: I’ve long been a fan of the signals and slots concept from Qt. I find it makes programming much more natural when you think of each object in terms of what data flows in (a slot) and what data flows out (a signal). Each XR-Tag component declares state in the form of attributes. Users then declaratively bind element attributes using the
<xr-connect>tag, which uses Babylon’s Observables to notify listeners of changes and calls the correspondingon<AttributeName>Changedslot when the value has been updated. - Modern web standards: A-Frame was released ten years ago. The web has evolved in more ways than we ever could’ve imagined in that time. WebVR is gone, and we now have an official specification for modules. Even tools have evolved: bundling should be done at the last mile, rather than during the package build stage. By working with the web rather than against it, XR-Tag makes the developer experience much smoother for everyone.
- User-friendly: IMHO, A-Frame never fully lived up to its promise of being usable by people with little or no programming experience due to its heavy coupling with ECS. Only people who work in the game development industry are likely to have heard the term ‘Entity-Component-System’ before, and it’s inherently procedural, which often results in JS-logic-as-XML-attribute-strings. XR-Tag should be usable by anyone who knows what Hypertext Markup Language is.
The source code is available here: https://github.com/XR-Tag/xr-tag
I haven’t published to NPM yet, as there are still a few things I’d like to finalize first:
- Commas in attributes (
position="x, y, z"vsposition="x y z")? The latter is more common in official web specs, but the former seems to increase readability. - Use
object3Dormeshas the internal variable name? Not every tag encapsulates an object derived from Babylon’s Mesh class, but the former comes from Three. - Decide on syntax for Materials.
- Changesets or release-please?
Once the initial release is ready, some of the things on my roadmap include:
- Hosted website for TypeDoc documentation.
- Interactive playground for experimenting.
- Better test coverage.
- Custom shaders tags.
- Support for WebGPU.
Many thanks to the Babylon community for making this possible. From SDF playground examples to bug fixes from Babylon.js team members, numerous people have helped make XR-Tag ready for use. I’m honored to be able to contribute back and hope my work will be of use to many more developers. With enough help, I believe we can make XR-Tag into a worthy rival to A-Frame.
If you’d like to contribute, I’d first and foremost appreciate any sponsors on GitHub. I’m just not at a point where I can afford hosting for documentation or a playground, let alone devote as much time to XR-Tag as I’d like. Besides that, keep an eye on the GitHub repo for contributing guidelines. I welcome any and all feedback and constructive criticism, especially while XR-Tag is in its early stages. If you see any glaring problems, please don’t wait to bring them to my attention.
Thanks again to Babylon.js for an incredible game engine.