Sometimes I feel like the only one who's totally fine with AutoLayout as-is. IMO it is hands-down the most straightforward and easy to understand way of constructing UI, and I've dealt with an insane number of UI toolkits over the years.
Furthermore, anytime I see someone complaining about it and I check out their solution with AL... they've overcomplicated how they're setting constraints and doing the layout, and it ends up usually being the issue more than AL itself.
> Sometimes I feel like the only one who's totally fine with AutoLayout as-is.
Agreed. It took me a while to find some idioms I like, but once I did that I like it quite a bit more than what I was doing in HTML land (note: not a webdev). It probably helps in my case that this is a solo project so I had the freedom to try a bunch of different styles until I found one I like.
I find the bad part is how user events are handled, particularly when multiple parts of the UI need to be changed. This, like autolayout, could be an issue of inexperience.
Same. Especially now that we have NSLayoutAnchor. Sure, it wasn't ideal when VFL was more widely used, but these days it works great and is as readable as any DSL I've seen.
For one, you can't create a hierarchy of UIStackViews and their contents declaratively. But UIStackView also forces you to think in terms of content hugging and compression resistance priorities, which (to me) isn't as natural as widths, heights, or weights.
And honestly the stuff I needed to do to get CSS working let alone cross-browser until very recently was really not as consistent, clean or predictable as auto layouts. I think you just got used to the suffering.
The only thing I really like about CSS is the arbitrary lines you can draw in the sand like "if it gets over 1000px wide then move the menu to the right".
Well storyboards are declarative if you view the source but they're burdened with a ton of legacy. If a view is constrained by auto layouts the frame values should disappear but they don't, leading to a ton of false positives when committing changes. You only have cryptic ID's not real names as references. Also making a mistake in the XML format tends to crash the parser without giving a usable clue to what went wrong.
Last problem is that everything in Interface Builder still lives apart from the code. I think in Android everything gets compiled and is safe to use from there, with IBOutlets you're always either taking the risk (!) or dealing with optionals everywhere (?)
No, I believe it is the case that Gruber conflated two separate projects (which might both be part of the same overall vision). The first was codenamed "Marzipan" and has been announced (and leaked and reported by Gurman). The second is what Gruber is speaking of in that article, and relates to laying out views. It has not been announced, but is codenamed Amber. Gruber clarified this post-Marzipan announcement in a tweet [0]. More info from Gurman [1].
That would be amazing. I really like using Storyboards if only just to better separate layout from logic but there are so many downsides to them that I just don't really use them all of the time.
UIStackView is a step in the right direction, but it doesn't go far enough. It's still not truly declarative; it requires you to think in terms of content priorities; and it doesn't support z-ordering.
I used to think that but now completely disagree. I’ve been making iPhone apps for too long, and storyboard/ib is so much faster and easier then any of the other options. I only use it for building constraints, and sometimes need to make them programmatically.
There’s a lot of stuff in there though that I ignore because of the issues you mentioned above. If you just keep it to simple constraints it’s great
Even before iOS 9 (anchors) the verbose autolayout was better than anything available for the web. Now there is CSS Grid which makes it easier but there is no mechanis that could describe relationship between elements like AL can.
Throw in a couple extensions for NSLayoutAnchor and it’s a very pleasant experience.
As for IB—it’s a matter of taste. I had no real problem with it, but at the end layout purely in code is the best option for me.
Furthermore, anytime I see someone complaining about it and I check out their solution with AL... they've overcomplicated how they're setting constraints and doing the layout, and it ends up usually being the issue more than AL itself.