aframe
aframe copied to clipboard
aframevr
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.
I started an experiment here to see if this was possible (plus TypeScript and Custom Elements v1): https://github.com/edsilv/aframe-ts-webpack
It's possible to target es5 too. TypeScript is obviously not required, I just like it :-)
threejs will deprecate js and switch complete to ES6 module, should be a good start to rebuild aframe to es6
@arpu @EricEisaman I feel like there's an opportunity coming up to modernise A-Frame's architecture while retaining es5 support. My webpack setup above allows this using webcomponents.org polyfills. I know types can be a fairly contensious thing... I find them super helpful, especially on larger projects, but they're not strictly necessary.
Speaking to @dmarcos recently on the slack, I asked about the idea of a "pure ecs" library being separate to the DOM. It sounds like this is currently under consideration, but would require being worked on in a separate project. I've been looking at things like https://encompass-ecs.github.io/why/architecture/hyper_ecs/ as potential candidates. Would be pretty great to be using a generic underlying library that could also be used in games made with Lua etc.
If it's agreed that a separate project is necessary for the pure ecs stuff, perhaps that's a way to test out some of these other ideas too? An "A-Frame Labs" kind of thing?
@edsilv That's some good food for thought. I recently finished reading all the source code for A-Frame, which isn't really that much. There are many neat and efficient stylistic approaches to learn from. An entirely new DOM decoupled ECS project, if built with a good base set of abstractions and APIs, could be very beneficial to the greater community.
mozilla has done some perf testing in esc systems https://github.com/brianpeiris/TowerDefenseECS
Interesting! I know the Hubs team are working on a library-agnostic ECS here: https://github.com/MozillaReality/ecsy
I found out about Encompass through this project:
https://github.com/linonetwo/react-encompass-ecs-example
react-three-fiber is quite an exciting project. A-Frame custom elements could be used in a react app too, but equally elsewhere without requiring react.
A-Frame is potentially a nice abstraction layer between libraries, ECS's, and Frameworks.
--- Framework (react, vue, ember) --- --- A-Frame --- --- ECS (encompass, ecsy, tiny-ecs) --- --- library (three, babylon) ---
Looks like my suggestion for an A-Frame style declarative abstraction layer is a VX milestone for ecsy!
https://github.com/MozillaReality/ecsy/issues/10
I am interested in the progress of this. I wanted to try out the lightweight snowpack bundler with A-Frame, however it only works with ESM imports, so A-Frame is not compatible.
Thread: https://twitter.com/BenHouston3D/status/1265617674509389824?s=19 🙏🏻 https://github.com/aframevr/aframe/issues/4242#issuecomment-526530618
this issue is quite old, is there a recommended way to import threejs into javascript module?
@antonkulaga What are you trying to accomplish? THREE is bundled with A-Frame and exposed globally on the THREE variable.
No plans for now to modularize. Gains from tree shaking would be negligible. For most content assets dwarf the library size. I don't know anything about Vite but I suppose there should be a way to import non-module dependencies? Maybe this is a good starting point? https://vitejs.dev/guide/dep-pre-bundling.html#dependency-pre-bundling
In case it's helpful to anyone, I proposed some changes to allow for async loading: https://github.com/aframevr/aframe/pull/5419
