I find this layout model annoying to work with. Everything is like a loaded spring, and if you forget one constraint, it may rip the whole layout into 0-sized pieces.
This model can't express wrapping, so it can't gracefully scale layouts down from desktop to mobile sizes (when you have a 3-column layout you have lots of control over column widths, but no way of turning them into 3 rows instead).
CSS Grid and Flexbox are pretty good. Conceptually they're messier than mathematically-beautiful constraints, but in practice they're more powerful and more robust.
> so it can't gracefully scale layouts down from desktop to mobile sizes (when you have a 3-column layout you have lots of control over column widths, but no way of turning them into 3 rows instead).
On Apple platforms (UIKit on iOS) handling such layout changes is done with another mechanism on top of auto layout. Something they call "Size Classes". You get a callback saying eg. "view has changed to Regular width, Compact height" and you switch to a another set of auto-layout constraints + animate as desired.
This size class system is used for stuff like handling rotation on the iPhone and transitioning to split-screen mode on iPad.
Yeah I actually like AutoLayout and InterfaceBuilder but it is incredibly frustrating when it doesn’t work. It hates being over constrained, so your layout in IB makes logical sense to you but then the debugging console will clog with autolayout complaints about which constraint it had to break.
Also anything with scroll views and/or stack views has been a nightmare in my experience. What should happen is that the stack view and scroll view should “expand” outward from their sub views based on those sub views intrinsic content sizes. Instead a lot of the time autolayout seems to try to start with the scroll view or stackviews size and compress “inwards” and so the only way Autolayout thinks it can satisfy everything is for everything to have a size of zero and your views disappear.
Also mobile devices don’t seem to conform well with rigid grid systems from a design standpoint. System provided UI conponents(like tab bars and nav bars on iOS) have their own sizes that won’t conform to your grid, users can change text size (a good thing), and animations and “physics” (like UIKitDynamics) necessarily mean you won’t have a grid.
It’s not anecdotal. We used Anchorage for some time before dropping it for this very reason. There’s a compiler warning available to you to let you know if any line or function takes more than a certain amount of time to compile. Our autolayout code that used Anchorage became the #1 source of warnings when we enabled it.
I've been using my operators for a long time without a problem. I think the secret is the fact that I'm using custom operators that have no other overloads, which avoids the combinatorial type system explosion during evaluation. The operators I use are ≈, ≤, and ≥ (which can all be typed on a US English keyboard using the option key). I admit there are overloads on the normal arithmetic operators for doing constants/multipliers too, but those haven't ended up as a problem (it's quite possible that the use of the custom operators constrains the expression enough that the arithmetic ones aren't a problem).
For context, I've had the options on to warn on expensive expressions for a long time and we use a lot of these operators everywhere and I think only once did we ever have an autolayout line flagged, and that was due to a complicated expression used to come up with the constant value.
Auto layout is not user-friendly enough to make sense on the web. 99% of the time the format is not readable at all. Does anyone honestly think this: [
'H:|[view1(==view2)]-10-[view2]|'
'V:|[view1,view2]|'
] is readable?
Especially since Apple admitted their mistake and is moving towards SwiftUI.
> Does anyone honestly think this: [ 'H:|[view1(==view2)]-10-[view2]|' 'V:|[view1,view2]|' ] is readable?
This is not Auto layout, it is just an alternative string-based API to express constraints in Auto layout. In practice no-one (that I know) uses Visual Format Language, as it is called, but instead sets up constraints in code or in Xcode Interface builder. In Swift code it would look something like this:
view1.leadingAnchor.constraint(equalTo: view2.leadingAnchor, constant: 10)
view2.topAnchor.constraint(equalTo: view1.bottomAnchor)
...
I was tasked with building a bespoke JavaScript framework for the web last year because that's just what the world needs right? :) Anyway, one of the requirements was that it be similar to building an iOS app so all the views, layouts, and styling needed to be done with code. This would have been really cool to have to jump start some of that work.
P.S. I know there are a bunch of frameworks out there that do the same thing I built. The company I built it for specifically wanted a custom one for themselves. It's decisions like that that led me to leave. Still, fun project and I learned a ton.
Here’s the umbrella website for these auto layout libraries using the Cassowary algorithm http://overconstrained.io/
It seems this was Apple’s auto layout, but links to the developer documentation are now broken. My conclusion the last time I looked into this is that it seems Apple has switched to a different approach with their new SwiftUI layout engine.
This is impressive but I think it's interesting that Apple is seemingly jettisoning Auto Layout with the introduction of SwiftUI with Stacks and Alignments.
Having worked with a lot of different layout and alignment systems, Auto Layout seemed to me to be considerable overkill. I found it generally not worth all the brain power needed to understand it and more importantly debug it when it isn't doing what you want.
This model can't express wrapping, so it can't gracefully scale layouts down from desktop to mobile sizes (when you have a 3-column layout you have lots of control over column widths, but no way of turning them into 3 rows instead).
CSS Grid and Flexbox are pretty good. Conceptually they're messier than mathematically-beautiful constraints, but in practice they're more powerful and more robust.