3 ms·

Here is some extensive discussion on that very issue: https://twitter.com/nikitonsky/status/561941079038390273?__hstc=114081816.f76a75a67c7899992519d5ce8d6f27e8

by woah 11y ago

Here is some extensive discussion on that very issue: https://twitter.com/nikitonsky/status/561941079038390273?__hstc=114081816.f76a75a67c7899992519d5ce8d6f27e8.1432297175947.1432297175947.1432297175947.1&__hssc=114081816.1.1432297175948&__hsfp=554760146 https://twitter.com/nikitonsky/status/561941079038390273?__h... Basically, constraint solving is harder to understanding, doesn't support wrapping, and is slow.

Ygg2 11y ago
This is the kind of response I was looking for. Though I have to ask, is this specific to Cassowary.js or to Cassowary constraint solver in general? Because from what I've seen/heard, the Cassowary constraint solver is used extensively in Mac OS X/iOS for UI layout, which AFAIK isn't really referred to as slow. Plus the constraint solver does operate on a matrix of constraint, which should make it easier to work on GPU.
- pcwalton 11y ago
  GPU based Web page layout has so many practical hurdles to overcome that the fact that Cassowary can be described in terms of a matrix isn't relevant.
- recuter 11y ago
  There's no reason why constraint solving wouldn't work just as well in the browser as AutoLayout works on OSX/iOS if it was natively implemented. It is not natively implemented however. Also, to take it further, Cassowary.js could solve for and output to flexbox as a backend.
- panic 11y ago
  Autolayout is very slow compared to manual layout on iOS. It limits the complexity of the UI you can build, especially if you need to update the layout at the display's refresh rate.