As GUI dev who worked with Apple's AutoLayout extensively I can confidently say constraint-based layout is a trap. It looks like more intuitive way to go on simple examples, but complexity spikes quickly as number of controls goes up. It's more complicated, more resilient to changes (harder to maintain), easy to get wrong, hard to understand and debug, bugs generally look uglier (what would be minor misplacement in CSS often becomes overlapping or clipping). It does not support word wrapping without hacks and restrictive assumptions about width. It is a real mess to insert/remove controls dynamically.
Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.
I saw the headline , didn't even read the article and came here to say this and saw your comment.
I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver.
I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code.
Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff.
The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints.
I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width.
I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex.
Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.
Every time I see mention of grids and CSS, I get a little bit excited. Then I see it's not based on canonical grids and I leave sad.
Maybe I should have "ported" DGL to HTML/CSS/JS, but I haven't figured out how (yet).
For mobile, I reserve judgement. I've heard good things about AutoLayout. But it'll be hard to replace my strategy of creating custom managers as needed.
(1) Except maybe for dynamic insertion and removal of controls. I'd have consider a few cases.
When I first heard of GSS I thought it was the holy grail of layout systems for app (not document) layout. On the surface, and as you mention, with simple examples it is deceptively alluring. However it quickly becomes apparent that the issues with regard to bugs and broken/cyclical dependencies far outweigh any benefits the system brings.
Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.
I agree with your assessment, but for certain use cases, I've found it to be pretty useful. Box-based layout forces you to arrange your view hierarchy in a Towers of Hanoi kind of way, whereas constraint-based layout lets you define relationships between free-floating sibling views directly. Here's[1] a little test I recently worked on; the amount of code to do this was pretty small and conceptually simple.
My wife and I had a big fight several years back because of photoshop. She was a photographer and she wanted to know the constraints of an image in inches and resolution. I told her that those didn't count for screen use and to just use the height and width in pixels. She had not understood until she googled it and watched a youtube video.
* you can't express text wrapping which is a huge issue. You've got to do workarounds in order to support it
* the api is very reference based. You need to say that the right of this element is left of this other one. whereas in react you don't want to assign every element you create to a local variable to get that reference the best api with react is one based on containers. <HorizontalLayout>... This is what I started with in react native but then, i realized that this was so close to flexbox that I could just use it instead :) you could use cassowary as an implementation detail of flexbox but that doesn't give you much
* also, when i tested cassowary, the js version, it was extremely slow. The version that we have in react native barely appears in traces for real code that we have
One of the absolute worst things about iOS development is struggling with auto layout. Sure there are some things you can do with it that are hard to do in a box layout method but 95% of the time it's just a massive headache to achieve something you could do with flexbox or even Bootstrap in a much more transparent way. In fact, one of the most appealing things about React Native is that it lets you do iOS layout with flexbox.
So I'll pass on similar constraint-based approaches to HTML layout, thanks!
Agreed completely. Constraint-based layout solvers are very appealing to programmers because they seem intuitively like the "right" solution -- but that intuition is based on the programmer's mental model of user interfaces. Constraints don't match the way designers think and work, so they're not good as a non-programmer's interface.
As often happens with solutions that are abstractly "right", constraint-based layout engines do a great job of fixing complex theoretical non-problems that nobody was asking to have fixed, while at the same time failing to address real-world issues that impede users' everyday workflows.
Autolayout is really nice once you figure out what it's good for. And it's certainly not good for everything.
Making a keyboard? Don't even bother. Too brittle, too slow.
Making something with dynamically-loading views? Probably not a good idea. Too unpredictable.
Trying to animate something fancy? Just change the frames directly. Doing it through an intermediary system is just too finnicky.
But the other day, I was designing a toolbar for my app. I needed floating menu buttons all along the top of the screen. Whenever a menu opened, it would grow horizontally and vertically; any existing menu buttons along its edges had to slide out of the way accordingly, or shrink if they hit the edge of the screen (with the distance between menu buttons being paramount). The specifics of the menu's expanded dimensions were left to the menu controller itself, and they could change at any time. For this, autolayout was absolutely the perfect tool for the job.
Whenever you have a small, finite set of static elements that can push each other around, autolayout makes things a lot simpler.
(The programmatic interface is just awful, though, and the visual formatting language doesn't do enough.)
And for all that effort you get an avatar that is horizontally misaligned by 10px and a webpage that falls apart when you vertically shrink your browser window.
Because you're so macho, right? And anything you don't understand shouldn't be used.
[EDIT] I find the sample code quite readable -- as long as one understands that it does more than constraints in that example, and that you of course have to read on the symbols to get them, like you'd have to read on Ruby's @, C's * and &, on regular expressions, etc.
But this macho talk from "team leaders" I dislike.
What exactly does it try to prove, even "metaphorically"? That the leader is so arrogant that wont discuss but bully his team? How about we reverse it: who would want to work in a team with some slap happy lead? Who'd want to hire that team or acquire that "talent"?
(And would this talk help the IT industry attract more female programmers?)
I can't tell if you're complainin about inherent difficulty in this stylesheet language, or just about introducing a new stylesheet language with a learning curve. If the former, I would disagree—it seems easier and much more useful than CSS to me. If the latter, well, any new language or technology has a learning curve, and it's rarely easy to know whether it will be worth learning.
Sass might make it more complex, but after learning it you save an extraordinary amount of time. I also don't find CSS that hard to work with anyway though.
Demos were all slightly wrong on Android chrome until I rotated screen at which point they completely broke. Using js to augment layouts with useful functionality is a great idea, but relying on it for core styling is a terrible choice.
I'd love to use this. But in the back of my head I still think javascript should be optional if possible ... not that 99% of the rest of the world cares ...
Any page that requires javascript and I don't need to use (at the level of do my taxes) or that I don't trust the owners of gets the same treatment.
So yeah optional javascript is a thing unless 100% of your audience are absolutely required to use your site.
EDIT
given that sites today use google analytics instead of their own server logs I wonder if non-javascript users just don't even get logged by the javascript-for-everything brigade?
I watched video of a talk by one of the guys who made this - he said they thought about making a static website generator like jekyll or something which would use the in-browser version to let you preview things live, then they'd have a tool to autogenerate with mediaqueries different versions of the stylesheet for different common screen sizes so you don't need JS. Sounds like a pretty cool compromise to me!
edit: the video I saw is actually that o'reilly video that's linked in the GSS website
> I'd love to use this. But in the back of my head I still think javascript should be optional if possible ... not that 99% of the rest of the world cares ...
Stop worrying about Javascript. HTML+CSS is Turing-complete [1]
As should CSS. From what I understand of GSS, it's entirely possible to use it to augment CSS rather than replace it. Granted, with certain layout problems it's trying to solve, that might be tricky/impossible.
The trouble with this is that it's expressed as a programmer's approach; everything is about variables, not geometry. Constraints should be input from a GUI, like Dreamweaver. To see what this looks like done right, try sketch mode in Autodesk Inventor, where you can draw lines, circles, and arcs and constrain them to each other in various ways. Designers would love it if they could do layout that way, and we could lay off a few thousand Javascript programmers.
As a non-designer, I disagree. I played around with FreeCAD a bit, and I was constantly wishing "just let me enter the damn formula" while messing with those graphical constraints.
Or could be it's just implemented badly there...
XCode does it this way - constraints, but expressed graphically in Interface Builder. It's still a pain in the ass. I'd much rather work with Flexbox than figure out why my iOS layout isn't resizing properly. Even if you get your mental model right perfectly, there's still a large mouse-twitching problem with auto-layout in XCode where it's hard to select exactly which element you're lining up with.
Auto-Layout is the worst. I used to spend so much time trying to figure out why things didn't line up or behave like they are supposed to. Luckily pods like Masonry and Paper make things easier but still, it is frustrating. To have it in CSS sounds like an absolute nightmare.
Autolayout is great once you've spent the first three days pulling your hair in anger.
Yet, i would absolutely not use it without the wysiwyg tools xcode provide, such as warnings on conflicts or automatic preview after changing the uppermost container's frame.
I just watched this GSS intro talk from last year:
https://vimeo.com/91393694
It looks interesting, but obviously from this and the demo page it needs alot of work to be ready for the mass market.
One piece of advice for Dan if you are reading HN, you have a nice relaxed speaking style but please stop using the word "crazy" or "it gets pretty crazy" which for me at least parses as: "too complex to work with".
I've been thinking about constraint satisfaction solver for layout, and keep it in mind as a possible project for a future. Great to see someone shares this view and went on to implement it.
I haven't studied this concrete project deeply, but the idea in general seems appealing, because CSS is hell.
(The site says this constraint language is used in Apple products - I didn't know that).
Not sure what you mean that "css is hell", although I understand from working with a lot of programmers (I do front end they do back end) that CSS is seen as something you might also want to learn but not really because it isn't proper programming. CSS as it is now is incredibly powerful and works almost as it should (almost int he way all languages/technology are works in progress).
I can see this (GSS) as having its place amongst a developers list of tools, but ultimately I can't see how it is better than Flexbox, or why I would want to a javascript library to do layout, or who in their right mind would want to pass a project using this on to someone else.
I must admit a certain trepidation anytime I hear the phrase, "and replace it with a constraint solver!" Not that they aren't useful and powerful tools. That's exactly the problem, they're very powerful tools. I'm not entirely convinced that doing website layout should require so much computing power.
Also, ironically, the site looks pretty bad on mobile and the entire left side of the page is chopped off. I don't take any "new ideas in style" page seriously if the mobile (or desktop, or whatever I'm using) experience on that page is bad.
I found the picture at the top to be a funny reflection of the problems of layout. The bird (I believe that's a cassowary as on the book cover) in a spacesuit is an interesting juxtaposition artistically, but the helmet face plate won't be able to rotate down over the birds beak and seal the helmet. A 'layout' case that the image didn't consider. Layout is hard.
I don't trust a layout engine whose webpage advertising the engine has centering issues... iPhone 5s in portrait does not center the section starting with 'Polyfills' but does so in landscape mode; I'm pretty sure this was not the expected design.
[+] [-] hamstergene|10 years ago|reply
Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.
[+] [-] thewarrior|10 years ago|reply
I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver.
I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code.
Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff.
Here's an example :
http://stackoverflow.com/questions/25766747/emulating-aspect...
The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints.
I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width.
I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex.
Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.
[+] [-] specialist|10 years ago|reply
The correct answer (for desktop) is canonical grid based layout. (1)
I created DesignGridLayout, a manager for Java Swing. You add rows of widgets, the manager figures out optimal placement.
https://designgridlayout.java.net/grids.html
Every time I see mention of grids and CSS, I get a little bit excited. Then I see it's not based on canonical grids and I leave sad.
Maybe I should have "ported" DGL to HTML/CSS/JS, but I haven't figured out how (yet).
For mobile, I reserve judgement. I've heard good things about AutoLayout. But it'll be hard to replace my strategy of creating custom managers as needed.
(1) Except maybe for dynamic insertion and removal of controls. I'd have consider a few cases.
[+] [-] ux-app|10 years ago|reply
Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.
[+] [-] archagon|10 years ago|reply
[1]: https://github.com/archagon/ABExpandingViewController/blob/m...
[+] [-] joegyoung|10 years ago|reply
[+] [-] masklinn|10 years ago|reply
His main points:
* you can't express text wrapping which is a huge issue. You've got to do workarounds in order to support it
* the api is very reference based. You need to say that the right of this element is left of this other one. whereas in react you don't want to assign every element you create to a local variable to get that reference the best api with react is one based on containers. <HorizontalLayout>... This is what I started with in react native but then, i realized that this was so close to flexbox that I could just use it instead :) you could use cassowary as an implementation detail of flexbox but that doesn't give you much
* also, when i tested cassowary, the js version, it was extremely slow. The version that we have in react native barely appears in traces for real code that we have
[+] [-] cageface|10 years ago|reply
So I'll pass on similar constraint-based approaches to HTML layout, thanks!
[+] [-] pavlov|10 years ago|reply
As often happens with solutions that are abstractly "right", constraint-based layout engines do a great job of fixing complex theoretical non-problems that nobody was asking to have fixed, while at the same time failing to address real-world issues that impede users' everyday workflows.
[+] [-] archagon|10 years ago|reply
Making a keyboard? Don't even bother. Too brittle, too slow.
Making something with dynamically-loading views? Probably not a good idea. Too unpredictable.
Trying to animate something fancy? Just change the frames directly. Doing it through an intermediary system is just too finnicky.
But the other day, I was designing a toolbar for my app. I needed floating menu buttons all along the top of the screen. Whenever a menu opened, it would grow horizontally and vertically; any existing menu buttons along its edges had to slide out of the way accordingly, or shrink if they hit the edge of the screen (with the distance between menu buttons being paramount). The specifics of the menu's expanded dimensions were left to the menu controller itself, and they could change at any time. For this, autolayout was absolutely the perfect tool for the job.
Whenever you have a small, finite set of static elements that can push each other around, autolayout makes things a lot simpler.
(The programmatic interface is just awful, though, and the visual formatting language doesn't do enough.)
[+] [-] coob|10 years ago|reply
https://github.com/robb/FLXView https://github.com/joshaber/SwiftBox
[+] [-] rimantas|10 years ago|reply
[+] [-] SchizoDuckie|10 years ago|reply
WTF is this voodoo? Less and Sass aren't complex enough? CSS isn't hard enough to work with as it is?
[+] [-] Torn|10 years ago|reply
It's constraints-based CSS. Of course it's going to look different to CSS/LESS/SASS. It's solving the problem of layout positioning a different way.
> If you inject stuff like this into a project, make sure you're doing it solo.
Well, yes. Project teams shouldn't be jumping on the latest shiny web things just for the sake of it, especially on unproven frameworks.
> 'cause if you're on my team, i'll slap you.
Grow up.
[+] [-] reinviting|10 years ago|reply
[+] [-] coldtea|10 years ago|reply
Because you're so macho, right? And anything you don't understand shouldn't be used.
[EDIT] I find the sample code quite readable -- as long as one understands that it does more than constraints in that example, and that you of course have to read on the symbols to get them, like you'd have to read on Ruby's @, C's * and &, on regular expressions, etc.
But this macho talk from "team leaders" I dislike.
What exactly does it try to prove, even "metaphorically"? That the leader is so arrogant that wont discuss but bully his team? How about we reverse it: who would want to work in a team with some slap happy lead? Who'd want to hire that team or acquire that "talent"?
(And would this talk help the IT industry attract more female programmers?)
[+] [-] baddox|10 years ago|reply
[+] [-] rkangel|10 years ago|reply
[+] [-] comrh|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] weego|10 years ago|reply
[+] [-] Qantourisc|10 years ago|reply
[+] [-] thrownaway122|10 years ago|reply
I got a blank page so I closed the tab.
Any page that requires javascript and I don't need to use (at the level of do my taxes) or that I don't trust the owners of gets the same treatment.
So yeah optional javascript is a thing unless 100% of your audience are absolutely required to use your site.
EDIT given that sites today use google analytics instead of their own server logs I wonder if non-javascript users just don't even get logged by the javascript-for-everything brigade?
[+] [-] empyrical|10 years ago|reply
edit: the video I saw is actually that o'reilly video that's linked in the GSS website
[+] [-] amelius|10 years ago|reply
Stop worrying about Javascript. HTML+CSS is Turing-complete [1]
[1] http://lemire.me/blog/archives/2011/03/08/breaking-news-html...
[+] [-] oneeyedpigeon|10 years ago|reply
As should CSS. From what I understand of GSS, it's entirely possible to use it to augment CSS rather than replace it. Granted, with certain layout problems it's trying to solve, that might be tricky/impossible.
[+] [-] freyr|10 years ago|reply
http://i.imgur.com/KkxICEw.png
[+] [-] Animats|10 years ago|reply
[+] [-] ambrop7|10 years ago|reply
[+] [-] nostrademons|10 years ago|reply
[+] [-] jongold|10 years ago|reply
https://medium.com/@almonk/design-like-it-s-1999-48ce5f5be14 https://medium.com/bridge-collection/modern-design-tools-ada...
[+] [-] electic|10 years ago|reply
[+] [-] bsaul|10 years ago|reply
Yet, i would absolutely not use it without the wysiwyg tools xcode provide, such as warnings on conflicts or automatic preview after changing the uppermost container's frame.
[+] [-] robogimp|10 years ago|reply
One piece of advice for Dan if you are reading HN, you have a nice relaxed speaking style but please stop using the word "crazy" or "it gets pretty crazy" which for me at least parses as: "too complex to work with".
[+] [-] Otik|10 years ago|reply
[+] [-] AdamTReineke|10 years ago|reply
[+] [-] amatera|10 years ago|reply
[+] [-] avodonosov|10 years ago|reply
I've been thinking about constraint satisfaction solver for layout, and keep it in mind as a possible project for a future. Great to see someone shares this view and went on to implement it.
I haven't studied this concrete project deeply, but the idea in general seems appealing, because CSS is hell.
(The site says this constraint language is used in Apple products - I didn't know that).
[+] [-] kagamine|10 years ago|reply
I can see this (GSS) as having its place amongst a developers list of tools, but ultimately I can't see how it is better than Flexbox, or why I would want to a javascript library to do layout, or who in their right mind would want to pass a project using this on to someone else.
[+] [-] jjar|10 years ago|reply
I'm opposed to most CSS grid styles as I feel they trade accessibility for a faster production speed. This seems to have neither of those benefits.
[+] [-] TazeTSchnitzel|10 years ago|reply
http://i.imgur.com/MLhaheD.png
Perhaps this is why the web uses box-based rather than constraint-based layout.
[+] [-] usaphp|10 years ago|reply
[+] [-] TazeTSchnitzel|10 years ago|reply
http://i.imgur.com/flVGSe4.jpg http://i.imgur.com/IemE3cm.jpg
[+] [-] x0054|10 years ago|reply
[+] [-] CodexArcanum|10 years ago|reply
Also, ironically, the site looks pretty bad on mobile and the entire left side of the page is chopped off. I don't take any "new ideas in style" page seriously if the mobile (or desktop, or whatever I'm using) experience on that page is bad.
[+] [-] ColinDabritz|10 years ago|reply
[+] [-] dyarosla|10 years ago|reply
[+] [-] msie|10 years ago|reply