Apple's auto layout and visual format language for JavaScript (2016)(ijzerenhein.github.io)
ijzerenhein.github.io
Apple's auto layout and visual format language for JavaScript (2016)
http://ijzerenhein.github.io/autolayout.js/
31 comments
> so it can't gracefully scale layouts down from desktop to mobile sizes (when you have a 3-column layout you have lots of control over column widths, but no way of turning them into 3 rows instead).
On Apple platforms (UIKit on iOS) handling such layout changes is done with another mechanism on top of auto layout. Something they call "Size Classes". You get a callback saying eg. "view has changed to Regular width, Compact height" and you switch to a another set of auto-layout constraints + animate as desired. This size class system is used for stuff like handling rotation on the iPhone and transitioning to split-screen mode on iPad.
On Apple platforms (UIKit on iOS) handling such layout changes is done with another mechanism on top of auto layout. Something they call "Size Classes". You get a callback saying eg. "view has changed to Regular width, Compact height" and you switch to a another set of auto-layout constraints + animate as desired. This size class system is used for stuff like handling rotation on the iPhone and transitioning to split-screen mode on iPad.
Yeah I actually like AutoLayout and InterfaceBuilder but it is incredibly frustrating when it doesn’t work. It hates being over constrained, so your layout in IB makes logical sense to you but then the debugging console will clog with autolayout complaints about which constraint it had to break.
Also anything with scroll views and/or stack views has been a nightmare in my experience. What should happen is that the stack view and scroll view should “expand” outward from their sub views based on those sub views intrinsic content sizes. Instead a lot of the time autolayout seems to try to start with the scroll view or stackviews size and compress “inwards” and so the only way Autolayout thinks it can satisfy everything is for everything to have a size of zero and your views disappear.
Also mobile devices don’t seem to conform well with rigid grid systems from a design standpoint. System provided UI conponents(like tab bars and nav bars on iOS) have their own sizes that won’t conform to your grid, users can change text size (a good thing), and animations and “physics” (like UIKitDynamics) necessarily mean you won’t have a grid.
Also anything with scroll views and/or stack views has been a nightmare in my experience. What should happen is that the stack view and scroll view should “expand” outward from their sub views based on those sub views intrinsic content sizes. Instead a lot of the time autolayout seems to try to start with the scroll view or stackviews size and compress “inwards” and so the only way Autolayout thinks it can satisfy everything is for everything to have a size of zero and your views disappear.
Also mobile devices don’t seem to conform well with rigid grid systems from a design standpoint. System provided UI conponents(like tab bars and nav bars on iOS) have their own sizes that won’t conform to your grid, users can change text size (a good thing), and animations and “physics” (like UIKitDynamics) necessarily mean you won’t have a grid.
I stopped using the visual format language. It was great for a while. The new constraints are much better with type checking:
NSLayoutConstraint.activate([
button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
button.centerYAnchor.constraint(equalTo: view.centerYAnchor, constant: 0)
])They're even better when you define some operators for them:
NSLayoutConstraint.activate([
button.centerXAnchor ≈ view.centerXAnchor,
button.centerYAnchor ≈ view.centerYAnchor + 10
])Anecdotally, that way lies ballooning Swift compile times.
It’s not anecdotal. We used Anchorage for some time before dropping it for this very reason. There’s a compiler warning available to you to let you know if any line or function takes more than a certain amount of time to compile. Our autolayout code that used Anchorage became the #1 source of warnings when we enabled it.
I've been using my operators for a long time without a problem. I think the secret is the fact that I'm using custom operators that have no other overloads, which avoids the combinatorial type system explosion during evaluation. The operators I use are ≈, ≤, and ≥ (which can all be typed on a US English keyboard using the option key). I admit there are overloads on the normal arithmetic operators for doing constants/multipliers too, but those haven't ended up as a problem (it's quite possible that the use of the custom operators constrains the expression enough that the arithmetic ones aren't a problem).
For context, I've had the options on to warn on expensive expressions for a long time and we use a lot of these operators everywhere and I think only once did we ever have an autolayout line flagged, and that was due to a complicated expression used to come up with the constant value.
For context, I've had the options on to warn on expensive expressions for a long time and we use a lot of these operators everywhere and I think only once did we ever have an autolayout line flagged, and that was due to a complicated expression used to come up with the constant value.
Same for Cartography.
[deleted]
Using vanilla autolayouts is pretty masochistic.
Auto layout is not user-friendly enough to make sense on the web. 99% of the time the format is not readable at all. Does anyone honestly think this: [
'H:|[view1(==view2)]-10-[view2]|'
'V:|[view1,view2]|'
] is readable?
Especially since Apple admitted their mistake and is moving towards SwiftUI.
Especially since Apple admitted their mistake and is moving towards SwiftUI.
> Does anyone honestly think this: [ 'H:|[view1(==view2)]-10-[view2]|' 'V:|[view1,view2]|' ] is readable?
This is not Auto layout, it is just an alternative string-based API to express constraints in Auto layout. In practice no-one (that I know) uses Visual Format Language, as it is called, but instead sets up constraints in code or in Xcode Interface builder. In Swift code it would look something like this: view1.leadingAnchor.constraint(equalTo: view2.leadingAnchor, constant: 10) view2.topAnchor.constraint(equalTo: view1.bottomAnchor) ...
This is not Auto layout, it is just an alternative string-based API to express constraints in Auto layout. In practice no-one (that I know) uses Visual Format Language, as it is called, but instead sets up constraints in code or in Xcode Interface builder. In Swift code it would look something like this: view1.leadingAnchor.constraint(equalTo: view2.leadingAnchor, constant: 10) view2.topAnchor.constraint(equalTo: view1.bottomAnchor) ...
I mean, it doesn't look any less readable than CSS.
Maybe CSS is syntactically easier, but the relationships between elements are much more hidden (width: 100%; of what?) so I'd call it a wash.
Maybe CSS is syntactically easier, but the relationships between elements are much more hidden (width: 100%; of what?) so I'd call it a wash.
You don't think CSS grid[0] is more usable than that? Templates are basically a ASCII-visible representation of the layout.
[0] https://css-tricks.com/snippets/css/complete-guide-grid/
[0] https://css-tricks.com/snippets/css/complete-guide-grid/
I was tasked with building a bespoke JavaScript framework for the web last year because that's just what the world needs right? :) Anyway, one of the requirements was that it be similar to building an iOS app so all the views, layouts, and styling needed to be done with code. This would have been really cool to have to jump start some of that work.
P.S. I know there are a bunch of frameworks out there that do the same thing I built. The company I built it for specifically wanted a custom one for themselves. It's decisions like that that led me to leave. Still, fun project and I learned a ton.
P.S. I know there are a bunch of frameworks out there that do the same thing I built. The company I built it for specifically wanted a custom one for themselves. It's decisions like that that led me to leave. Still, fun project and I learned a ton.
Commonly known as "not invented here" syndrome
https://en.m.wikipedia.org/wiki/Not_invented_here
https://en.m.wikipedia.org/wiki/Not_invented_here
I am aware of the concept.
Wait, HTML / CSS and JS aren't code?
i also worked with a company that decided to create their own framework instead of using something with community support
On the other hand I've spent a lot of time in the last few years replacing third party dependencies.
what are you working on now?
Reminds me of https://gss.github.io/guides/ccss
Headline reads like this is open source Apple code. It’s not.
Here’s the umbrella website for these auto layout libraries using the Cassowary algorithm http://overconstrained.io/
It seems this was Apple’s auto layout, but links to the developer documentation are now broken. My conclusion the last time I looked into this is that it seems Apple has switched to a different approach with their new SwiftUI layout engine.
Edit: this blog post from October discusses the switch from Auto Layout to SwiftUI in some detail https://kean.github.io/post/swiftui-layout-system
It seems this was Apple’s auto layout, but links to the developer documentation are now broken. My conclusion the last time I looked into this is that it seems Apple has switched to a different approach with their new SwiftUI layout engine.
Edit: this blog post from October discusses the switch from Auto Layout to SwiftUI in some detail https://kean.github.io/post/swiftui-layout-system
This is impressive but I think it's interesting that Apple is seemingly jettisoning Auto Layout with the introduction of SwiftUI with Stacks and Alignments.
Having worked with a lot of different layout and alignment systems, Auto Layout seemed to me to be considerable overkill. I found it generally not worth all the brain power needed to understand it and more importantly debug it when it isn't doing what you want.
Having worked with a lot of different layout and alignment systems, Auto Layout seemed to me to be considerable overkill. I found it generally not worth all the brain power needed to understand it and more importantly debug it when it isn't doing what you want.
Even before SwiftUI (which is a paradigm shift), Apple released the NSLayoutAnchor API, which superseded VFL.
This is an intriguing effort. When I was doing iOS development, I used both AutoLayout and the ASCII-art constraints.
The whole time I was doing it, I wondered why I couldn't just use CSS.
It seems that every UI toolkit has a different method. And every one that I've worked with makes me wonder why they don't just use CSS.
The whole time I was doing it, I wondered why I couldn't just use CSS.
It seems that every UI toolkit has a different method. And every one that I've worked with makes me wonder why they don't just use CSS.
Looks cool. Is there something like that available for non-Apple desktop apps?
This model can't express wrapping, so it can't gracefully scale layouts down from desktop to mobile sizes (when you have a 3-column layout you have lots of control over column widths, but no way of turning them into 3 rows instead).
CSS Grid and Flexbox are pretty good. Conceptually they're messier than mathematically-beautiful constraints, but in practice they're more powerful and more robust.