yoga

Glad to see some agreement there. I'm interested in building an ECS-based approach for a UI system at some point. The Yoga layout engine (implements flexbox -- https://github.com/facebook/yoga/tree/master/yoga) seems to actually be pretty amenable to just incorporating as a `Layout` or `Flex` component, then you could have components for platform-specific renderings (eg. `iOSTextInput`, `AndroidTextInput`, `DOMTextInput` in wasm, ...) that could read from cross-platform common components (`TextInput`). A core aspect would also be a `Hierarchy` component that just has a parent entity id and a list of child entity ids (that it keeps in sync properly). Then bind things to JS and allow you to code it from React, while still being able to eg. run an animation thread for some specific animations that just queries and reads/writes the `Layout` a

I'm a layout implementor for Planimeter's Grid Engine. Implementing a naive subset of the algorithm for calculating the box sizes in the visual formatting model and calculating layout for normal flow, relative positioning, and absolute positioning is far easier to implement than flexbox.[1] There's nothing insane about this. And you'll learn even more when trying to draw to the screen. Normal flow also doesn't require multiple passes, whereas flexbox does.[2] Even Yoga doesn't implement a conforming model.[3] I'd even speculate that flexbox performs slower than the standard visual formatting model just because of the differences in the algorithm. Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.[4] [1]: https://github.com/Planimeter/grid-sdk