4 ms·

Apple’s Auto Layout for JavaScript

70 points by bpierre 5y ago

willio58 5y ago
My only question is.. why? Being someone who’s used autolayout on iOS and flex/grid on the web, I much prefer flex/grid.
- happytoexplain 5y ago
  I've also used both, and I strongly prefer autolayout. The ability to declaratively define relationships between any two attributes of any two views is like having a superpower. You can make incredibly complex, resilient, well defined interfaces in no time. That said, it has serious downsides, like cognitive load and debuggability.
  - atom_arranger 5y ago
    I second this. As someone who used to do iOS dev with autolayout, then switched to React Native/web, autolayout is way more powerful. IMO platforms should consider implementing autolayout, and from autolayout other simpler layout systems (e.g. flexbox) can easily be implemented and used when the full power of autolayout isn’t needed. Considering autolayout has been used for iOS layout for a long time performance seems not to be an issue (with native, not JS, implementations), even though it may seem more complicated (constraint solving).
- nexuist 5y ago
  For iOS developers transitioning to Web I think this would make a pretty great stepping stone between the platforms. Nothing wrong with bringing something familiar with you!
bergie 5y ago
There’s also this implementation we worked on way back http://gss.github.io/ http://gss.github.io/
junon 5y ago
For those that don't know, Auto Layout is just the cassowary linear constraint solving algorithm implemented in a nice UI library. There are a number of projects that already kind of do this (GSS being one of them, as someone else already mentioned) but with Houdini on the way this might become a very real contender in the near future. I've already done some work with it - you can see a POC here: https://github.com/qix-/casscade https://github.com/qix-/casscade One large problem (with GSS at least) was that it's difficult to "back-propagate" child layout values into parent containers. For example, if an element has a flexible width, then calculating what its width should be based on its textual content is very, very difficult with Cassowary - especially when that value should be used to influence its parent node's size.
- amelius 5y ago
  Is this the same kind of constraint solving algorithm as used in CAD packages like FreeCAD?
  - junon 5y ago
    Not sure, though I doubt it. Linear constraint solvers are generally good for layouts et al, but not great for more involved engineering tasks. I've seen finite domain constraint solvers used in more general cases as they better support more nuanced operations at the cost of memory and processing power.
    - amelius 5y ago
      Yes, now that I think about it more deeply, I think that with engineering problems you are more likely to get quadratic constraints because of pythagoras' theorem.
Vanit 5y ago
I don't know why any developer in their right mind would want to expose themselves to autolayout more than necessary.

70 points by bpierre 5y ago

My only question is.. why? Being someone who’s used autolayout on iOS and flex/grid on the web, I much prefer flex/grid.

happytoexplain 5y ago
I've also used both, and I strongly prefer autolayout. The ability to declaratively define relationships between any two attributes of any two views is like having a superpower. You can make incredibly complex, resilient, well defined interfaces in no time. That said, it has serious downsides, like cognitive load and debuggability.
- atom_arranger 5y ago
  I second this. As someone who used to do iOS dev with autolayout, then switched to React Native/web, autolayout is way more powerful. IMO platforms should consider implementing autolayout, and from autolayout other simpler layout systems (e.g. flexbox) can easily be implemented and used when the full power of autolayout isn’t needed. Considering autolayout has been used for iOS layout for a long time performance seems not to be an issue (with native, not JS, implementations), even though it may seem more complicated (constraint solving).
nexuist 5y ago
For iOS developers transitioning to Web I think this would make a pretty great stepping stone between the platforms. Nothing wrong with bringing something familiar with you!

bergie 5y ago

There’s also this implementation we worked on way back http://gss.github.io/ http://gss.github.io/

junon 5y ago

For those that don't know, Auto Layout is just the cassowary linear constraint solving algorithm implemented in a nice UI library. There are a number of projects that already kind of do this (GSS being one of them, as someone else already mentioned) but with Houdini on the way this might become a very real contender in the near future. I've already done some work with it - you can see a POC here: https://github.com/qix-/casscade https://github.com/qix-/casscade One large problem (with GSS at least) was that it's difficult to "back-propagate" child layout values into parent containers. For example, if an element has a flexible width, then calculating what its width should be based on its textual content is very, very difficult with Cassowary - especially when that value should be used to influence its parent node's size.

amelius 5y ago
Is this the same kind of constraint solving algorithm as used in CAD packages like FreeCAD?
- junon 5y ago
  Not sure, though I doubt it. Linear constraint solvers are generally good for layouts et al, but not great for more involved engineering tasks. I've seen finite domain constraint solvers used in more general cases as they better support more nuanced operations at the cost of memory and processing power.
  - amelius 5y ago
    Yes, now that I think about it more deeply, I think that with engineering problems you are more likely to get quadratic constraints because of pythagoras' theorem.

Vanit 5y ago

I don't know why any developer in their right mind would want to expose themselves to autolayout more than necessary.