Fun fact for any Seattleites out there: the co-author of this paper, Professor Alan Borning, was the advisor for the Ph.D. students who originally built OneBusAway and is on the board of the non-profit that runs it today.
n.b. I've been involved in the OneBusAway project for over a decade and run the non-profit as the very part time exec director today.
Cassowary's big differentiator 25+ years ago was that it is robust against cycles in constraints and supported inequalities. Those two facts made it instantly way easier to use than the local-propagation-based solvers that predated it (think spreadsheet-style formulas referencing cells where you can only compute values using equality assignment and you can't create cyclic references).
Cassowary being able to solve that broader class of problems in an efficient and incrementally (using prior solutions to the problem to make subsequent solutions even faster) was why Apple chose it for Autolayout in the later '00s. Their Visual Formatting Language was a nice ease-of-use enhancement, too.
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.
Fun fact for any Seattleites out there: the co-author of this paper, Professor Alan Borning, was the advisor for the Ph.D. students who originally built OneBusAway and is on the board of the non-profit that runs it today.
n.b. I've been involved in the OneBusAway project for over a decade and run the non-profit as the very part time exec director today.
Cassowary's big differentiator 25+ years ago was that it is robust against cycles in constraints and supported inequalities. Those two facts made it instantly way easier to use than the local-propagation-based solvers that predated it (think spreadsheet-style formulas referencing cells where you can only compute values using equality assignment and you can't create cyclic references).
Cassowary being able to solve that broader class of problems in an efficient and incrementally (using prior solutions to the problem to make subsequent solutions even faster) was why Apple chose it for Autolayout in the later '00s. Their Visual Formatting Language was a nice ease-of-use enhancement, too.
The original cassowary repo is https://github.com/gjbadros/cassowary and there was a nice improved port to Javascript 15 years ago: https://github.com/slightlyoff/cassowary.js/
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.
In the ancient times there was a startup called The Grid. Very hyped. They implemented the Cassowary layout algorithm for the web and called it GSS.
I loved the idea of GSS but it never caught on: https://gss.github.io/
See also: https://github.com/nucleic/kiwi