Make A-Frame ES Modules Compliant to Enable Tree Shaking

A-Frame can now be written based upon the new modular Three.js to enable proper ES modules tree shaking. This would be a much welcomed great leap forward for A-Frame.

Such a rewrite would reduce bloat and improve library extensibility.

Let me expand on "reduce bloat". It is true that a 3D application may be asset heavy however, then again, it may not. For example, a powerful and commercially valuable VR application may spawn the user in a scene within range of a few well designed and shaded primitives with some enhanced VR interactive features using let's say the aframe htmlembed component. Such a design may very well require less than 20kb of the underlying Three.js modules. Furthermore, imagine that application was for an E-Commerce site which gave the user the chance to explore various categories of items in 3D. The modern web has dynamic import enabling lazy loading of only the logic code and assets required by the user interaction and can be further customized to the user device through the Network Information API by being responsive to the NetworkInformation.downlink value. Also, user position in the 3D space can be used with quadtree or octree logic to control lazy loading. The end result is that users from low end flip phones on 2G to high end flagship devices on 5G can all have satisfying custom experiences. Even if the user has a flagship device, it doesn't mean we should require an unnecessary consumption of data.

The issue names no A-Frame files, tests, or entry points. Start by reviewing the linked modular Three.js and webpack tree-shaking guidance, then map A-Frame’s current module boundaries; done means A-Frame is ES-module compliant and unused Three.js code can be removed through tree shaking.