Comment by ridiculous_fish | Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

ridiculous_fish

Disclaimer: I was the owner and maintainer of autolayout at Apple for a few years. I think the article makes a fair point, but focuses on just a detail.

The article criticizes what it calls "source-order independence" where "you can have two unrelated components be involved in a constraint." We called this "cross-cutting constraints," and discouraged their use for exactly the reason the author gives. Most constraints attached to you should be to yourself, a sibling, or a parent. Cross-cutting constraints are not a primary benefit of constraint-based layout.

So what do constraint-based layouts give us? A key one is that constraints regularize layout under a uniform language. You are given a handful of properties (width, height, two centers, four edges, and baseline) and constants, and can relate them using equalities, inequalities, and priorities. From those primitive elements, you can build a lot of stuff that other frameworks handle in an ad-hoc manner.

Want to set a fixed width? Equate the width to a constant. Make it a minimum width? Change the relation to >=. Right align? Equate the two right edges. Centering? Equate the two centers. Two containers ought to have equal widths? Relate their widths to each other. Aspect ratio? Relate the width to the height. All this stuff just falls out naturally, requiring no special support.

Compare to CSS, which supports many of these features, but in a completely arbitrary, ad-hoc way. Right-aligning requires setting a position, but center-aligning requires setting margin-left and margin-right, and vertical centering requires a completely different set of hackish techniques. Or compare to Android, which has lots of ad-hoc methods to achieve specific layout tasks (setMeasureWithLargestChildEnabled, setBaselineAligned, etc).

Autolayout has its share of problems: it's verbose, has a steep learning curve, works poorly with grid-type layouts, struggles with nonlinear layouts like text reflowing, and more. But its approach of a uniform layout language is powerful and elegant, compared to ad-hoc "bag of properties" layout mechanisms.

Autolayout is definitely planned out better than the jumble of thoughts and improvements that has become CSS. Personally, my biggest issue was the learning curve, like you said. Trying to do very simple layouts (that were trivial on older versions of iOS/XCode) required a lot of reading through documentation just to get started. And a lot of fighting with strange errors I hadn't seen before. I imagine that as the XCode constraints/layout UI continues to improve this will be less of an issue.

In my experience, android layout is significantly easier to 'get right' and significantly more understandable at a glance than iOS autolayout. I really like what autolayout is trying to accomplish, but it isn't at the level of Android for me yet (I really like the idea of the visual format, however). I appreciate that the constraint system is a general solution to the problem, but, as we see in the grid layout case, sometimes specific solutions are a better answer.

We do all our iOS layout in code, and all our Android layout in XML (or all that we can, save the 1% that necessitates munging in the Java). This probably affects my opinion, since Java layout code for Android is just as obtuse as the objective-c autolayout, if not more so.

I'm a weird case (electrical engineer with ~a BSc in CS as well). When I first saw the WWDC 2012 sessions about AutoLayout, I was blown away! After all these years dicking around with specific pixel sizes for things, and basically doing my own linear constraint solving on paper to make things work (web, mobile, desktop, etc), I just breathed a sigh of relief to see that it was finally done the right way. I've since done a few layouts with it and am super impressed, especially with the text DSL for specifying constraints. Sure, it's a little finicky sometimes, but that's generally when I haven't thought through the constraints well enough :)

Another thing to keep in mind is that while cross-cutting constraints are a bad idea in gross quantities, they do appear in many well-designed UIs and as such are not something that you can disallow completely. If you have a system that doesn't support them (such as Android), you force developers to kludge their own constraint solving on top of the existing system. The occasional need for such things isn't going to go away if you structure your framework correctly, it's just a question of how much you're going to make your developer hate you when they need to implement one.

Actually CSS is not arbitrary. I don't know what you mean by "setting a position" but if you use float to right or left align an element, it will cause text to wrap on the opposite side. How would text wrap on float: center? It doesn't make sense, that's why you'd just want blank space on each side (hence margins.)

Everything else works well with absolute positioning. Need something vertically aligned?

    position: absolute;
    top: 50%;
    margin-top: (1/2 height of element)

What if you can't know the height of the element?

as mentioned in another comment this only works if you know the height. Your example is exactly the issue that the original comment was talking about.

Your intention is to align both centers. Why do we need to be dealing with 'top' and 'margin-top' to achieve this? It is a poor way to describe your intention.

It's much easier to say:

  box1.center == box2.center

The cassowary solver allows you to specify exactly your intentions in relation to the edges and centers of boxes. It's easier to reason about and doesn't require the bag of weird tricks that are needed in CSS (eg. margin: 0 auto; to center??? wtf?)

Reply on news.ycombinator.com