search

supermedium / aframe-react

:atom: Build virtual reality experiences with A-Frame and React.
https://ngokevin.github.io/aframe-react-boilerplate/
MIT License
1.42k stars 151 forks source link

Explanation of README recommendation against this lib #116

Closed meatwallace closed 6 years ago

meatwallace commented 6 years ago

I currently recommend using vanilla A-Frame and aframe-state-component with static templating over aframe-react.

Can you elaborate on this recommendation @ngokevin? Not suggesting it's a bad recommendation, but I'm curious on the rationale. As someone quite invested in integrating A-Frame & React, the key reason I see is that React lifecycle doesn't simply align with A-Frame's or Three's lifecycle.

Additionally, I'm happy to tidy & summarize any rationale provided and append it to the README in a PR. Seems worthwhile; we've been happily using this lib in production for over a year now.

Cheers.

promontis commented 6 years ago

I would love some insights in this as well... seems you are very experience in how to use a-frame.

ngokevin commented 6 years ago

lmk if you have more questions.

https://github.com/ngokevin/aframe-react#aframe-react

I recommend using vanilla A-Frame and aframe-state-component with static templating over aframe-react. React wastes a lot of cycles and incurs a lot of memory garbage. aframe-react is often abused where it is too easy to place 3D/real-time logic at the React layer, causing poor performance (e.g., doing React renders on ticks). aframe-react applications frequently ignore the prescribed ECS framework of A-Frame. Internally, React does tons of computation to compute what changed, and flushes it to the entire application. It is apparent React ecosystem does not care much about memory as most examples allocate functions and objects in the render method, and where immutables are popular. With only ~10ms per frame to do all computation, there is little room for React's massive system.