How A-Frame VR is Different from Other 3D Markup Languages
21 Dec 2015
Upon first seeing A-Frame, branded as “building blocks for the web” displaying
<a-cube>, developers may conceive A-Frame as yet another 3DML (3D
markup language) such as X3Dom or GLAM. What A-Frame brings to
the game is that it is based off an entity-component system, a pattern
used by universal game engines like Unity which favors composability
over inheritance. As we’ll see, this makes A-Frame extremely extendable.
The entity-component system is a pattern in which every entity, or object, in a scene are general placeholders. Then components are used to add appearance, behavior, and functionality. They’re bags of logic and data that can be applied to any entity, and they can be defined to just about do anything, and anyone can easily develop and share their components. To imagine this visually, let’s revisit this image:
An entity, by itself without components, doesn’t render or do anything. A-Frame ships with over 15 basic components. We can add a geometry component to give it shape, a material component to give it appearance, or a light component and sound component to have it emit light or sound.
Each component has properties that further defines how it modifies the entity. And components can be mixed and matched at will, hence the “composable” word root of “component”. In traditional terms, they can be thought of as plugins. And anyone can write them to do anything, even explode an entity. They are expected to become an integral part of the workflow of building advanced scenes.
Other 3DMLs, or any markup languages at all for that matter, are based on an inheritance pattern. This is sort of the default pattern to go towards given the heirarchichal nature of HTML and XML. Even A-Frame was initially built in this way. The problem is that this lacks composability. Customizing objects to do something more than basic becomes difficult, both to the user and to the library developer.
The functionality of the language then becomes dependent on how many features the maintainers and the library add. With A-Frame however, composability brings about limitless functionality:
Putting it logically, the different kinds of functionality you can squeeze out of an object is the permutation of the number of components you have. With the basic 16 components that A-Frame comes with, that’s 65536 different sets of components that could be used. Add in the fact that components can be further customized with properties, and that there is an ecosystem of components to tap into, the previous use of the word “limitless” was quite literal.
With other 3DML libraries, if they ship 50 different kinds of objects, then you get only get 50 different kinds of objects with fixed behavior.