I find constraints-based layout superior to boxing. First, it is truly declarative way of what you (and a user) want to see. Boxes and tables are just parasitic invisible guides which force you to re-hierarchy everything after additional requirements, or to slap new things around because a layout is too fragile to patch in a minute. I’ve seen frontend guys designing cool grids only to stumble upon them later and trying to avoid re-debugging all the scrolls, unintended protrusions and pixel imperfections. And it wasn’t even a quick job in the first place. And even if you like guides, why not define them via constraints without any physical hierarchy?
Second, since it is just a set of equations, it allows to create higher-level design languages like “a remark below that input, same width and x” or automagic “every element has right-margin of min:20px to the edge”, which allows any dynamically created row to function without poisoning all elements with specifically located paddings/margins/etc. Tables and boxing always forces you to think in terms of their clumsy and situational size request/allocation process, which is usually too complex to reason about without an experiment.
That said, I have yet to see a constraints library which is powerful enough to do all the modern ui yadda yadda.
As a contrary view, I find most forms of automatic layout tedious and error prone. For the vast majority of interfaces, a fairly rigid absolute layout of all components typically works with less computation of the client machine. Yes, you have to do some computation on laying out the components. And you have to set what you are planning on supporting. But the rube Goldberg machine that is most web automated layouts is a literal tar pit.
I think there is a sweet spot between automatically laid out elements on a fixed sized canvas.
Responsive design is the root of all evil, and we would have a lot less headaches with something like hypercard, where modularity and responsiveness happens at a functionality level, i.e. more screen estate? -just show more cards.
I suspect that automation at construction time is also generally positive. Basically, have a tool that will lay everything out, but then leave it in such a way that you can manually move things around. And once things are "built", have them be fairly locked in to what was chosen at construction.
This would move web design to be a lot more like many other design tasks. Even if something parametric goes into designing type faces, as an example, on build, that is all gone.
Also, this is what designers do anyway. Nobody draws a full-screen sketch and expects a css guy to infer all other form factors. We literally have source materials for all widths. If designers just left their designs in an (x,y) format and sent it to a constraint programmer with notes on what expands/wraps where, it would be a very natural job continuation. But instead they re-cipher these results into a grid-boxed-media-query pepe silvia form which entangles everything beyond all repair.
It is an amusing clash of trying to make semantic markup that is both describing the interface and describing the data in the document at the same time. And generally gets everyone yelling/focusing on different parts.
Second, since it is just a set of equations, it allows to create higher-level design languages like “a remark below that input, same width and x” or automagic “every element has right-margin of min:20px to the edge”, which allows any dynamically created row to function without poisoning all elements with specifically located paddings/margins/etc. Tables and boxing always forces you to think in terms of their clumsy and situational size request/allocation process, which is usually too complex to reason about without an experiment.
That said, I have yet to see a constraints library which is powerful enough to do all the modern ui yadda yadda.