Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stevia: Human-readable auto-layout in code

github.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Stevia: Human-readable auto-layout in code

#33

Post by nostrademons »

lstamour wrote: post #15
seanalltogether wrote: post #5

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.

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

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.

Re: Stevia: Human-readable auto-layout in code

#34

Post by mbenjaminsmith »

msoad wrote: post #7

There is also SnapKit which I really like: https://github.com/SnapKit/SnapKit box.snp_makeConstraints { (make) -> Void in make.width.height.equalTo(50) make.center.equalTo(self.view) }

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.

Re: Stevia: Human-readable auto-layout in code

#35

Post by bri3d »

tomyws wrote: post #3

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?

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.

Re: Stevia: Human-readable auto-layout in code

#36

Post by kitsunesoba »

austinl wrote: post #17

Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit ( 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).

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.

Re: Stevia: Human-readable auto-layout in code

#38

Post by thought_alarm »

msoad wrote: post #7

There is also SnapKit which I really like: https://github.com/SnapKit/SnapKit box.snp_makeConstraints { (make) -> Void in make.width.height.equalTo(50) make.center.equalTo(self.view) }

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;

Re: Stevia: Human-readable auto-layout in code

#39

Post by radicality »

heyalexchoi wrote: post #32

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

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.

Re: Stevia: Human-readable auto-layout in code

#40

Post by schwarrrtz »

Someone wrote: post #10
tomyws wrote: post #3

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?

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 cours…

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.

Post reply on HN