
Stevia: Human-readable auto-layout in code - sachadso
https://github.com/s4cha/Stevia
======
msoad
There is also SnapKit which I really like:

[https://github.com/SnapKit/SnapKit](https://github.com/SnapKit/SnapKit)

    
    
            box.snp_makeConstraints { (make) -> Void in
               make.width.height.equalTo(50)
               make.center.equalTo(self.view)
            }

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

[https://github.com/SnapKit/Masonry](https://github.com/SnapKit/Masonry)

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

------
mpd
It's not really on-topic, but why do people name their projects with names
that are very difficult to find via search engine? I really don't understand
this mindset.

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

~~~
chrisfosterelli
I think this has hugely influenced the number of people who refer to it as
'golang' instead of just 'go'.

If a query comes up with junk I usually replace 'go' with 'golang'.

------
bphogan
I am not an iOS developer with much experience. I have taken one class and
built two very simple apps. So I can't weigh in on how good of an idea this is
from an iOS developer standpoint.

But I can say from a beginner to iOS standpoint that this looks amazing and I
will put it to use in an app I am building immediately, as soon as I can
figure out how.

To the author of this library, thank you.

~~~
sachadso
Thanks a ton for the kind words :)

------
austinl
Since people are discussing Auto Layout alternatives, I'd recommend
AsyncDisplayKit ([http://asyncdisplaykit.org/](http://asyncdisplaykit.org/)) –
although it's a bit more advanced. Layout mimics CSS and Flexbox. It was
originally built by Facebook and very actively maintained.

You also get a number of other advantages, like moving UI operations off of
the main thread (which is often a pain point in iOS apps shooting for 60fps).

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

~~~
cellularmitosis
Doing asynch UI "by hand" might be easier than you think. Here's a table view
example:
[https://github.com/pepaslabs/GlitchyTable](https://github.com/pepaslabs/GlitchyTable)

------
heyalexchoi
OP: this is really neat, but i'm curious - what was your motivation for
creating something so similar to autolayout's first party visual format
language?

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html)

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

~~~
sachadso
Exactly the problem we're trying to solve ;)

------
mayoff
If you can target iOS 9 (or later), `UIStackView` eliminates a lot of the need
for handcrafted constraints. Also, the project's example “Native Autolayout”
code is written in a gratuitously verbose style.

------
harryf
How do you approach adaptive layout with this? How easy is it to define a
layout that can work on all devices and with different orientations? Are you
able to specify size ratios between elements for example (one annoying thing
missing from Apples visual format language)?

------
xHopen
Thanks for the effort. As a professional iOS developer since 6 years, I think
is really good to see people coming out with better ways to do things.
Autolayout works but the amount of code that you have to write is just out of
this world, is a nonsense. And implementations like yours should open the eyes
of apple to create something better. GREAT JOB OP

~~~
sachadso
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 :)

------
iLoch
For anyone looking for something a little closer to what they know from the
web: [https://github.com/facebook/css-layout](https://github.com/facebook/css-
layout)

------
chuinard
Actually laying things out in iOS, coming from an Android background, was
something I could just not grasp. It was a big driving factor in me going with
Ionic, which lets me use flexbox.

------
sshykes
Looks like they've included their .DS_Store files within the git repository:

[https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia](https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia)

Screenshot: [http://imgur.com/5EPUNeZ](http://imgur.com/5EPUNeZ)

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

------
seanalltogether
I feel like the app developers who don't simply bite the bullet and use the
technologies that Apple promotes inevitably dig themselves into a corner.

Programmatic layouts/constraints just crumble underneath you when Apple
decides to make changes in each new version of iOS or introduces a new
formfactor.

~~~
lstamour
Um, auto-layout, which this says it uses, _is_ an Apple supported constraints
system?
[https://developer.apple.com/library/ios/documentation/UserEx...](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/)

~~~
nostrademons
I think grandparent poster is saying app devs should program directly to the
built-in Apple syntax rather than using a third-party library which wraps it.
Because if Apple comes out with extensions or changes, then anyone who uses
Stevia will need to wait until the library incorporates them, losing their
advantage to competitors in the process.

I sympathize somewhat with the grandparent poster's point, but it all depends
on how likely Apple is to improve auto-layout vs. how many new developers need
an easier layout system _now_. JQuery managed to become massively popular on
the web, despite web browsers eventually adopting most of its innovations,
because the browsers took years to incorporate its innovations (and sometimes
never quite got the syntax right) while millions of people needed to make a
webapp _right now_.

~~~
lstamour
I can see that now. Certainly anyone who worked with the HTML-based iOS
components Facebook had back in the day was in for a shock later. I don't
recommend using any iOS libraries you aren't prepared to upgrade/replace later
-- and this includes Apple code too! Plenty of Apple APIs change every year,
so... I'd hope somebody takes up the cause of updating this for as long as the
API proves useful. :)

------
nashequilibrium
I hate storyboards and I decided that I will start using them after my current
project is done. I just had so much code dealing with autolayout and
constraints and weird little bugs. This looks really cool and will try it out.
Thanks for the lib.

------
tomyws
I find it strange that something akin to markdown-style syntax sugar is more
user-friendly than a visual designer. Do the tools for developing a UI for iOS
this way not include a WYSIWYG editor to set things such as contraints?

~~~
Someone
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...](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html))

~~~
schwarrrtz
you can copy elements in interface builder, iirc. you can't copy their
constraints, which makes sense because the copied instances necessarily have
different constraints. otherwise the copies would just stack on top of each
other.

in my personal opinion, IB is great for layout of one view or screen,
especially with the new IBDesignable and IBInspectable features.

doing app navigation in a storyboard is a terrible idea and will lead to a
monolithic storyboard file that is very annoying to work with.

~~~
cellularmitosis
Was going to say something similar, that IB is great if you are doing one-off
screens, but it isn't the best for creating reusable / composable UI elements.

------
gravypod
I wonder if something similar would work in Java using annotations.

I experimented with this a little in a game I was working on. You just need a
standard way of displaying everything, then automatically generate the UIs.

------
ufo
Is that operator-overloading abuse or something else?

~~~
sachadso
haha indeed

------
jheriko
Apple should pull their finger out and solve this historically very well
solved problem so that this work is not necessary ::

~~~
sachadso
Amen!

------
jkot
Why reinvent a wheel? Have a look at miglayout
[http://www.miglayout.com/](http://www.miglayout.com/)

~~~
sachadso
Yeah let's use Java on iOS !

~~~
jkot
No lets reimplement miglayout

