Humans are not constraint solvers

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.

CSS has one main problem w.r.t. layout: it does not have a universal way of specifying whether the size of an element should be determined by its contents or its container. So you can say, for example, "Make this element take up the remaining horizontal space" (that's the default for display:block) or "Make this element just wide enough and just tall enough to contain its contents" (the default for display:inline) but it is not possible to say, "Make this element tall enough to consume the remaining vertical space." The result is that some simple layouts (e.g. a fluid layout with same-height columns underneath a header with dynamic content) are not possible in CSS. All this could be solved by simply allowing the user to specify width and height of an element in terms of either the element's contents or the element's container (or, of course, as a fixed size).

There are two issues here. One is doing layout with a constraint solver. The other is the user interface for the person doing the page layout.

A constraint solver interface is a good match to a GUI. It's not a good match to a textual interface. Web designers should be using a layout tool like Dreamweaver, not hand-coding constraint expressions.

For an example of a constraint-based tool for a much harder problem, see Autodesk Inventor, which is a 3D CAD system. It has 2D sketches, and those are controlled by constraints. You can draw rectangles, and if they have coincident points or edges when drawn, those are constrained to stay together. You can explicitly dimension something, and it becomes that length. If you try to apply inconsistent constraints, the system rejects them. You can make all constraints visible as icons, then delete any you don't want. Web designers would probably love the power of Inventor sketch mode, because it's not restricted to horizontal and vertical lines, or even to straight lines. That might be overkill for web design, although being able to wrap text around a curved image would make some people happy. Inventor demonstrates that a much harder constraint problem than web design has been successfully solved with a good GUI.

Asking visual designers to write constraint expressions by hand is pounding a screw with a hammer. Use the right tool for the job.

I don't understand the title. Humans are constraint solvers (I have personal experience in this), although they are not fast at it, so humans also use constraint solvers.

If you don't have a constraint solver in your layout engine, you had better be a good one yourself, because somebody has to do it.

And yet that is exactly the direction that Computer Aided Design - such as Autodesk Inventor & Dassault SolidWorks - has gone in. And it makes building things a shit load easier, let me tell you.

I don't think there is a single way to do layout that is perfect for all needs. Both CSS style layout and Autolayout work well for many cases and fail miserably for others.

I never could get onboard with constraint based layouts. It feels like someone got a little too clever and really over-solved a problem. Realistically, you want your content to look decent on small screens (phones), medium sized screens (tablets), and fill larger ones (everything else). In the case of iOS dev you really have 3-4 specific targets. CSS media queries (or 2-3 nibs with boxes and springs) solve this problem adequately. Trying to create a system of linear inequalities that guarantees perfection on every possible resolution is just asking for mistakes and headaches. I agree with the author that most of the "power" lays in a space of things you really don't want to touch.

Isn't the real question whether humans are good at generating constraints?

If somebody writes an incomprehensible sentence it's not his language's fault for him doing so - and the solution is not to simplify English.

All you need to understand this problem is better language.

All of this has been solved long time ago at Java Swing. Checkout Mig Layout.