I wish the web platform settled on constraints based layout rather than flex and grid. Autolayout on iOS was always so much fun to use and made intuitive sense in a way the css layout options never did. Constraint-based layout predates flex and grid so it’s a little weird it never caught on.
While I agree with this wholeheartedly, one aspect of the Web that constraint systems don't play nice with is flowing content. Typical example would be text.
The reason is that the width/height of an element with flowing content cannot be described by a linear constraint. (not even a quadratic constraint, since there's a discontinuous jump when text wraps from N lines to N+1 lines) So when you mix these kinds of elements into a Cassowary-based system, you're trying to fit a square into a circle-shaped hole, and run into weird edge cases that require workarounds like manually adjusting constraints based on ad-hoc logic, or running the layout solver multiple times to try different sizes for a flowing element, etc.
The limiting factor is what can the UI designer wrap their head around. If your system is pure and elegant but can only be understood by the top 5% of developers, it will never catch on. To be blunt, it has to be simple enough to be usable by the least smart hire-able developer. If it requires more thinking than writing FizzBuzz, forget about it.
This depends on how well this abstraction can be encapsulated. The systems with rigorous mathematical foundations often result in simple to use products that compose well. The 3d modelling relies on linear algebra, but the designers don't need to understand those details. The regular CSS involves very complex layout calculations too.
I see you're getting downvoted (wrongly, because you're discussing in good faith), but I agree with the sentiment. 5% is a bit harsh, but having been on multiple iOS teams where AutoLayout is essential, it has always been a challenge to get people to understand what's going on, do the correct thing, and write code that doesn't barf constraint conflict warnings to the console. Seasoned iOS engineers have learned to do the right thing, but it's easy for one person to introduce a new conflict that nobody notices until months later when it's tedious to debug.
A shorter way of saying this is that the ergonomics of the most broadly-deployed constraint solving UI layout system—AutoLayout for iOS—still cause pain. It's not better pain than the massive complexity of CSS, it's just different pain. And it's also not sufficient; Apple themselves introduced collection views and stack views, each of which has its own special behavior. Their new framework, SwiftUI, does not use AutoLayout. Even the maintainers don't consider AutoLayout "superior" enough to adopt in a fresh UI framework.
It's a shame, because there is elegance in having a layout system you can explain in one or two pages, with enough power to almost support an entire OS and ecosystem of apps. It's just not quite across the finish line for developer experience and education.
Eh, I understood AutoLayout back when I was a naive junior dev doing iOS. Formal definition of constraint solvers can be complex, but if you wrap it in an intuitive API, it’s consumable by a wide variety of people.
