When to use AFrame or ThreeJS?

[georgebutler]

Hey all, I've noticed that in the custom client code some things use ThreeJS and some use AFrame. I'm wondering what the philosophy is behind using AFrame or ThreeJS for 3D objects.

[netpro2k]

The only thing that HAS to be in AFrame currently is any networked properties, and anything that needs properties deserialized from a GLTF file. For everything else we prefer to use ThreeJS as directly as possible (both for performance reasons as well as simplicity). The codebase has some things that strictly follow this rule, but also still has a bunch of AFrame code that we haven't bothered to try and port over to being more direct.

Its definitely still something we are figuring out as we go, but the kind of general model I use for new code is to define the data I need to be networked and the data that needs to come from a scene/avatar GLTF file first. Then make an AFrame component (or set of components) that mostly just holds that data and registers itself with a "hubs system" that does most of the work. The component also sometimes contains some utility functions for working with the particular entity instance and dealing with updates. Note that "Hubs Systems" are nothing more than objects, that usually have a tick function, that we manually call each frame inside the hubs-systems AFrame component. We do this so that its crystal clear what order everything is running in each frame. (default AFrame systems don't have quite as strict an ordering). We also now tend to prefer more directly passing around dependencies or calling functions rather than broadcasting events as the code flow tends to be much easier to follow this way.

An example of something more recent done closer to this "ideal" style would be the Media Frames: https://github.com/mozilla/hubs/blob/master/src/systems/media-frames.js - Definitely not perfect but its getting in the direction I think we like.