A-Frame is a framework that makes it easy to build virtual reality (VR) content for the Web. It provides:

The ability to build 3D scenes with declarative HTML.

Responsive WebVR scenes that work out of the box on multiple platforms.

An entity-component-system pattern which promotes composability and extensibility.

After three fun and busy months of development, we are proud to announce the release of A-Frame version 0.2.0. This version’s overarching theme is extensibility. For WebVR to evolve quickly, in a period in which VR is dominated by closed native ecosystems, A-Frame needs to enable open experimentation and rapid iteration. A-Frame’s inherent extensibility grants developers permissionless innovation, making it the VR-flavored embodiment of the Extensible Web Manifesto.

*If you’re not familiar, read A-Frame’s previous introduction on Mozilla Hacks.

Since Launch

A-Frame has received an overwhelmingly positive response by democratizing immersive 3D content creation on the Web. By the numbers:

Over 1500 stars, 25 contributors, 550 commits on the A-Frame GitHub repository.

Over 470 people have joined the A-Frame community Slack channel to ask questions, show off projects, and just generally socialize.

Over 100 awesome creations by people listed on the awesome-aframe repository.

Over 50 projects showcased on the Made With A-Frame Tumblr.

Members of the community have used A-Frame for some interesting use cases:

And A-Frame has received some high-profile use:

Amnesty International UK, in partnership with design firm Junior, created 360 Syria, an experience that transports viewers to the besieged city of Aleppo, Syria to witness the devastation of barrel bombing on its citizens.

The Washington Post published Mars: An Interactive Journey which transports people to the surface of the Red Planet to learn about space exploration programs.

Improved Extensibility in A-Frame 0.2.0

A-Frame brought the entity-component-system pattern to HTML. Everything in a scene is an entity. An entity is a general placeholder object that inherently does nothing and renders nothing. Components are buckets of reusable data and logic; when plugged into entities, components provide them appearance, behavior, and functionality. Developers can write components to do whatever they want, with direct access to three.js, and then share them with the community. Anything that is possible with three.js and WebGL is possible in A-Frame.

Since A-Frame’s initial release, we have been largely refining the component API. We went through cycles of creating components, discovering limitations in the API, and then writing patches to improve A-Frame. By dogfooding our own framework, we were able to discover obstacles in extending A-Frame:

Component API has been enhanced with property types, schema configurations, and more lifecycle methods ( pause , play , tick ).

, , ). Primitives (convenience elements such as <a-sphere> ) are able to take components.

In addition, we opened up more escape hatches for developers to delve deeper. They can now:

Define custom property types for more flexible component APIs.

Register GLSL shaders or three.js materials.

Register primitives.

Register systems to provide global scope and services to components.

Read the full version 0.2.0 release notes for more detail.

Incarnation of the Extensible VR Web

The Extensible Web encourages healthy competition between ideas and APIs. Only once emerging ideas and APIs are established should they be standardized. Embracing this philosophy is mandatory in order for WebVR to succeed, else it’ll be another case of the Web being late to the party when all the chips have already been eaten. A-Frame is an embodiment of these ideas.

As mentioned before, with A-Frame being built upon an entity-component-system pattern, developers can write, share, and plug in components that extend new features. If a feature doesn’t yet exist or isn’t up to par, the community can run with it. The ecosystem already features community-built components that enable gamepad controls, speech recognition, and physics. With this short-term innovation scheme, developers can rapidly experiment with ideas in order to help advance not only A-Frame but WebVR.

For example, Don McCurdy iterated on standard A-Frame components in his A-Frame playground repository, while the core A-Frame team worked on enabling extensibility. From that, he has refactored and enhanced A-Frame’s entire controls system alongside physics. With those components proven, we will upstream them to the collection of standard A-Frame components.

Several people in the community were looking for a way to render text and HTML elements as textures in A-Frame. Student Max Krieger stepped up and wrote components to enable using a <canvas> element as a texture and to enable text wrapping.

Also, Ben Nolan of SceneVR recently ported his client-side code to use A-Frame. He is developing components that enable interactive and multi-user experiences, features the core A-Frame team was targeting for later this year. What’s more, Ben is working on an WYSIWYG editor for A-Frame scenes. We are working on an editor as well.

This virtuous cycle of the community enabling features and sharing components continues to be a huge boon for the WebVR ecosystem. Rather than designing slowly behind closed doors, we built A-Frame to pull the entire web community into the effort. Together we’ll try lots of things and slowly focus on the ones that work.

Looking Ahead

We’ll be working on building more demos, improving interactivity, and crunching down on performance. Once the polyfill is stabilized, we will quickly release WebVR 1.0 support into A-Frame.