Yeah, I don't understand the point of Mozilla making their own flavor of this, rather than contributing to X3D. Or hell, any of the several other open source projects of a similar nature.
Well, a few major differences I'm seeing at a glance:
- X3DOM supports Flash as well as an X3D plugin. A-Frame is specifically targeting WebGL and has a much smaller surface area
- A-Frame is based on ThreeJS rather than a custom engine
- A-Frame seems to be embracing modularity a lot more than X3DOM, and it seems likely that users will be able to build highly specialized components published as npm modules (much like we see with React components)
- A-Frame is specifically focused on VR out of the box
- The markup language and intended target audience is significantly different
A-Frame is based on an entity-component system. It favors composability over hierarchy. Dig deep in the docs and see that's actually quite different than standard wrapping shapes in HTML elements.
Since A-Frame mentions this => "A-Frame is ultimately just the DOM, so developers can also manipulate it with standard JavaScript methods,"... it means D3.js should work beautifully with it (as should other frameworks that do data <==> DOM binding/manipulation)
Also it's based on three.js which is a solid 3D engine.