Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make A-Frame ES Modules Compliant to Enable Tree Shaking #4242

Open
EricEisaman opened this issue Aug 2, 2019 · 16 comments
Open

Make A-Frame ES Modules Compliant to Enable Tree Shaking #4242

EricEisaman opened this issue Aug 2, 2019 · 16 comments

Comments

@EricEisaman
Copy link
Contributor

EricEisaman commented Aug 2, 2019

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.

@edsilv
Copy link
Contributor

edsilv commented Aug 30, 2019

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 :-)

@dmarcos
Copy link
Member

dmarcos commented Sep 9, 2019

Relevant discussion #2390

@arpu
Copy link
Contributor

arpu commented Sep 24, 2019

threejs will deprecate js and switch complete to ES6 module, should be a good start to rebuild aframe to es6

@edsilv
Copy link
Contributor

edsilv commented Sep 24, 2019

@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?

@EricEisaman
Copy link
Contributor Author

@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.

@arpu
Copy link
Contributor

arpu commented Sep 24, 2019

mozilla has done some perf testing in esc systems https://github.com/brianpeiris/TowerDefenseECS

@edsilv
Copy link
Contributor

edsilv commented Sep 24, 2019

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) ---

@edsilv
Copy link
Contributor

edsilv commented Sep 24, 2019

It could be a de facto "WebECS" standard.

@edsilv
Copy link
Contributor

edsilv commented Oct 2, 2019

Looks like my suggestion for an A-Frame style declarative abstraction layer is a VX milestone for ecsy!

ecsyjs/ecsy#10

@mattrossman
Copy link
Contributor

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.

@edsilv
Copy link
Contributor

edsilv commented May 27, 2020

@antonkulaga
Copy link

this issue is quite old, is there a recommended way to import threejs into javascript module?

@dmarcos
Copy link
Member

dmarcos commented May 19, 2021

@antonkulaga What are you trying to accomplish? THREE is bundled with A-Frame and exposed globally on the THREE variable.

@ploddi
Copy link

ploddi commented Apr 12, 2022

Any update on this? Is there a way to use A-Frame with Vite?

@dmarcos
Copy link
Member

dmarcos commented Apr 12, 2022

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

@chrisirhc
Copy link
Contributor

In case it's helpful to anyone, I proposed some changes to allow for async loading: #5419

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants