
Apple's auto layout and visual format language for JavaScript (2016) - pcr910303
http://ijzerenhein.github.io/autolayout.js/
======
pornel
I find this layout model annoying to work with. Everything is like a loaded
spring, and if you forget one constraint, it may rip the whole layout into
0-sized pieces.

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.

~~~
jchb
> 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.

------
melling
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)
                ])

~~~
lilyball
They're even better when you define some operators for them:

    
    
      NSLayoutConstraint.activate([
          button.centerXAnchor ≈ view.centerXAnchor,
          button.centerYAnchor ≈ view.centerYAnchor + 10
          ])

~~~
saagarjha
Anecdotally, that way lies ballooning Swift compile times.

~~~
vlozko
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.

~~~
lilyball
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.

------
matchbok
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.

~~~
crazygringo
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.

~~~
Someone1234
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/](https://css-
tricks.com/snippets/css/complete-guide-grid/)

------
vikingcaffiene
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.

~~~
robgibbons
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)

~~~
Nicksil
Non-mobile:
[https://en.wikipedia.org/wiki/Not_invented_here](https://en.wikipedia.org/wiki/Not_invented_here)

------
sansnomme
Reminds me of
[https://gss.github.io/guides/ccss](https://gss.github.io/guides/ccss)

------
johnwheeler
Headline reads like this is open source Apple code. It’s not.

~~~
mch82
Here’s the umbrella website for these auto layout libraries using the
Cassowary algorithm [http://overconstrained.io/](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](https://kean.github.io/post/swiftui-layout-system)

------
davidkhess
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.

~~~
oflannabhra
Even before SwiftUI (which is a paradigm shift), Apple released the
NSLayoutAnchor API, which superseded VFL.

------
aazaa
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.

------
qwerty456127
Looks cool. Is there something like that available for non-Apple desktop apps?

