[HN Gopher] The Cassowary Linear Arithmetic Constraint Solving A...
___________________________________________________________________
The Cassowary Linear Arithmetic Constraint Solving Algorithm [pdf]
(2002)
Author : andsoitis
Score : 45 points
Date : 2025-03-14 13:36 UTC (9 hours ago)
(HTM) web link (constraints.cs.washington.edu)
(TXT) w3m dump (constraints.cs.washington.edu)
| phaedrus wrote:
| See also: https://github.com/nucleic/kiwi
| n8cpdx wrote:
| 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.
| Asooka wrote:
| 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.
| lykahb wrote:
| 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.
| danielvaughn wrote:
| 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.
| ken47 wrote:
| Is the limiting factor preventing all websites from being
| written in assembly also the intelligence of the developer
| base? What an obtuse take.
| irskep wrote:
| 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.
| meindnoch wrote:
| 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.
| vsksp wrote:
| What course or resource should one look into if one is interested
| in learning more about constraint solving
| gjbadros wrote:
| 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/
| malthejorgensen wrote:
| 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/
| pianoben wrote:
| > in the ancient times > 2014
|
| Rage successfully baited - that was like three months ago,
| tops!
|
| I wonder what ever happened with Grid - they were indeed very
| hyped, but fairly-obviously vaporware too IIRC. At least in
| terms of marketing, where they claimed AI web-property
| generation.
| jgalt212 wrote:
| Very ahead of the times for 2014.
|
| > GSS was created by Dan Tocchini, leader of the TheGrid, the
| first AI website platform.
| bsimpson wrote:
| I consulted with them briefly. Felt like it was stimulant-
| fueled hustleporn. They had an interesting concept, but not
| surprised they didn't turn out a sustainable product.
| aaronbrethorst wrote:
| 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.
| dalanmiller wrote:
| Oh wow - I met Alan back in 2012 when I was working on a
| project called WhichBus. How cool!
|
| Thank you for your continued involvement and contributions to
| OneBusAway!
| kleiba wrote:
| Good memories! I used to use the Cassowary solver back in the day
| for planning multi-media presentations where you could specify
| constraints that were to hold between the different elements of
| the presentation. Think: "play this audio clip at most two
| seconds after this other video ended", while the inherent lengths
| of the elements were only available at run-time.
|
| In addition, you could combine quantitative with qualitative,
| i.e., Allen-style constraints [0].
|
| This all feels like ages ago to me now, but I suppose >20 years
| actually _is_ quite a long time.
|
| [0] https://en.wikipedia.org/wiki/Allen%27s_interval_algebra
| ge96 wrote:
| Isn't the Cassowary a mean-ass bird
| joshka wrote:
| We use a cassowary based constraint solver within Ratatui [1].
| It's kind of neat once you understand the algorithm and add your
| own UI rules system on top of it. Unfortunately the library[2]
| that we use for the actual solving is unmaintained for many years
| now. I've been meaning to rewrite[3] a bunch of things in the lib
| to be more ergonomic, but it hasn't bubbled to the top of my todo
| list yet.
|
| [1]: https://github.com/ratatui/ratatui/blob/main/ratatui-
| core/sr...
|
| [2]: https://crates.io/crates/cassowary/
|
| [3]: https://crates.io/crates/kasuari
___________________________________________________________________
(page generated 2025-03-14 23:01 UTC)