Stevia: Human-readable auto-layout in code

And Masonry, if you're still on Obj-C (like me):

https://github.com/SnapKit/Masonry

    [box mas_makeConstraints:^(MASConstraintMaker* make) {
        make.width.height.equalTo(50);
        make.center.equalTo(self.view);    
    }];

And cartography, which is my preference:

https://github.com/robb/Cartography

    constrain(button1, button2) { button1, button2 in
        button1.right == button2.left - 12
    }

Or while we're sharing, here's mine in Obj-C++ (although I never managed to extract it into a separate package):

https://github.com/viewfinderco/viewfinder/blob/master/clien...

    [self addConstraints:box.anchorWidth == 50];
    [self addConstraints:box.anchorHeight == 50];
    [self addConstraints:box.anchorCenterX == self.view.anchorCenterX];
    [self addConstraints:box.anchorCenterY == self.view.anchorCenterY];

Came here to say the same thing. I've abandoned storyboards and nibs in favor of SnapKit and it hasn't let me down so far. It's one of the better libraries I've used on OS X and iOS.

Or use NSLayoutAnchor, which was added in iOS 9 and OS X 10.10;

    [box.widthAnchor constraintEqualToConstant:50].active = YES;
    [box.centerAnchor constrantEqualToAnchor:self.view.centerAnchor].active = YES;

All projects start that way, mostly because it very hard to invent a new noun for something. Some projects just get really popular and then get high on search rankings for that noun organically.

I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"

I guess they don't understand how search engines work, like that dumb company that created the unsearchable programming language Go.

Even worse is the tendency to give every subproject a non-descriptive name. E.g. Safari on iOS/OS X

This just raises the mental burden and lowers discoverability.

Thanks a ton for the kind words :)

AsyncDisplayKit is cool stuff, but I really wish it were possible to yank its layout and “doesn’t do layout on the main thread” parts and apply them to vanilla UIKit. It’s frustrating to run into the inevitable unsupported use cases, bugs, etc with alternative UI systems. UIKit has its quirks but it’s mature enough that coming up with a use case that it can’t serve in on way or another is difficult. It’ll be years before alternatives can achieve that.

Have you tried using it? It's all string-typed, and the worst when you don't get any error until you compile the app and then it complains you have an error in your layout "code" (which is just a string). Layout in code should be checked at compile time, which this project seems to attempt.

This is indeed vastly inspired by Visual Format Language purposefully so, so that there's nothing more to learn. This actually does pretty much the same thing behind the hood. We can say this is just Apple's visual format on steroids.

Three reasons mostly motivated us : 1. having the compiler on our side and not just hope the string would parse fin at runtime. 2. Laying out Horizontal and Vertical layout at the same time 3. Having something readable cause readable == maintainable :)

What we found after trying lots of different layout strategies on our iOS App was that Autolayout in code was the simplest to maintain, and still using Apple technology, contrary to ReactNative for example. Furthermore we were absolutely against reinventing a heavy layout engine knowing we had Autolayout at hand. The syntax was very harsh on the eyes though so we looked into ways to make it better, and Stevia (healthy syntactic sugar) was born! Thanks a lot for the kind words :)

Can you elaborate on the consequences of doing that for the non-Mac users among us?

I think that's often true, up until the point in time where it isn't. :-)

I remember that when DHTML/Javascript was young, from 1998-2004, you used the features built into every browser or you'd find yourself painted into a corner with the next release. Java applets, VBScript, ActiveX, Flash, and numerous third-party plugins: all dead. And then suddenly, around 2005, Prototype/JQuery/YUI/Dojo all came out, and you were an idiot if you didn't use a third-party library. The pendulum is starting to swing the other way now that browsers are pretty reliably standards-based, but there are still a number of people who look at you funny when you suggest using vanilla JS.

I was a little young to remember, but IIRC the same thing happened with the PC: through most of the early 80s, if you didn't write in assembly and use the specific features provided by each vendor, your app didn't have a chance. Then 1990 rolled around, decent C/Pascal compilers came out, third-party class libraries took off, and you got left behind if you still coded in assembly. Then by the early 2000s things had centralized under Microsoft .NET again, but by then the web was taking off and nobody cared.

It seems like this is the pattern of most software platforms: for the first 10 years, you better code to proprietary APIs because you won't be able to accomplish anything otherwise, and if you do it'll be obsolete with the next OS release. For the next 10 years, an explosion of third-party frameworks takes off, and you pick the one that makes you the most productive. In the last 10 years, things centralize again under a monopoly vendor, but by then the platform is already getting obsolete. Not sure where we are in the cycle for iOS - we've probably got a couple years to go - but it looks like it may be happening in Android land already, with Dagger 2 and RxJava.

Um, auto-layout, which this says it uses, is an Apple supported constraints system? https://developer.apple.com/library/ios/documentation/UserEx...

I find XCode's UI editor pretty good!

They do in the interface builder however if you just wanted to use programmatically created views then not really no.

They do, but search and replace, diffing, and copy-paste of multiple elements and their constraints likely (I haven't used Xcode's editor much, certainly not recently) do not work as well as their equivalent in text.

And of course, some people find markdown more user-friendly than a visual GUI for more or less the same reasons, so it should not be that surprising to find some people experiment with this.

And of course, autolayout has a text-based language of its own (https://developer.apple.com/library/ios/documentation/UserEx...)

Do you also find it strange that WYISWYG website editors are not more widely used?

I think it's really a question of audience. A textual DSL for visual layout is popular to the HN audience, because most of us are more comfortable writing code and interacting with computers on the command line. While we love having a DSL that we can use our favorite tools on (like diff, grep, ack, etc.), the majority of other folks (read: non-HN users) probably find a WYSIWYG editor much nicer.

The tools do include that functionality, called Interface Builder or the Storyboard Designer.

The editor on its own is fairly nice to use these days, but it outputs obtuse XML and has a propensity to edit parts of the layout XML file that weren't actually modified. This makes source-control level collaboration and especially code review very difficult. To make things worse, for a long time the tooling encouraged putting almost all UI into one giant "Storyboard XML" file, guaranteeing confusion and conflicts.

The editor was also quite slow and crashy for years which drove the proliferation of these libraries and the "don't use the storyboard editor" meme accompanying them. It's gotten a lot better in the last ~2 years and I haven't had a crash in heavy day-to-day usage for quite some time.

If Apple could improve the XML output format to be easier to review, eliminate the serialization/deserialization weirdnesses, introduce a visual diff-and-merge tool, and improve the performance just a bit more, the Interface Builder would be excellent, but as is, I see why a lot of people don't like using it, especially on big projects with many collaborators.

Using Interface builder is Great indeed it just has a ton of other issues down the road, this article sums it well : http://blog.teamtreehouse.com/why-i-dont-use-interface-build...

haha indeed

Amen!

Yeah let's use Java on iOS !