Show HN: Lima, a Swift-based DSL for responsive iOS development
1–10 of 21 posts
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#2IB/storyboard are trash (WYSIWYG is so 90s and dragging and poking around a huge visual editor is a huge time sink)
AutoLayout is verbose and complex, even with helper libraries.
It'd be super cool if we could use something like XML with Lima.
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#3Pretty cool. All of the layout options for iOS are pretty subpar (coming from a web/android background): IB/storyboard are trash (WYSIWYG is so 90s and dragging and poking around a huge visual editor is a huge time sink) AutoLayout is verbose and complex, even with helper libraries. It'd be super cool if we could use something like XML with Lima.
I don't think they can get much shorter than this:
private func addConstraints() {
introduction.attach(sides: [.top, .leading, .trailing], 8.layoutGuideRespecting)
contact
.attach(sides: [.leading, .trailing], 8)
.space(8, .below, introduction)
spinner.center()
error
.attach(sides: [.leading, .trailing], 8)
.space(8, .below, contact)
create.attach(sides: [.top, .bottom, .trailing], 3)
}
And honestly the stuff I needed to do to get CSS working let alone cross-browser until very recently was really not as consistent, clean or predictable as auto layouts. I think you just got used to the suffering.The only thing I really like about CSS is the arbitrary lines you can draw in the sand like "if it gets over 1000px wide then move the menu to the right".
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#4Pretty cool. All of the layout options for iOS are pretty subpar (coming from a web/android background): IB/storyboard are trash (WYSIWYG is so 90s and dragging and poking around a huge visual editor is a huge time sink) AutoLayout is verbose and complex, even with helper libraries. It'd be super cool if we could use something like XML with Lima.
> AutoLayout is verbose and complex, even with helper libraries. I don't think they can get much shorter than this: private func addConstraints() { introduction.attach(sides: [.top, .leading, .trailing], 8.layoutGuideRespecting) contact .attach(sides: [.leading, .trailing], 8) .space(8, .below, introduction) spinner.center() error .attach(sides: [.leading, .trailing], 8) .space(8, .below, contact) create.attach(sides…
Even stackviews, which was Apple admitting that simple layouts are too verbose to do with AL, are a mess.
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#5Earlier quoted context omitted.
> AutoLayout is verbose and complex, even with helper libraries. I don't think they can get much shorter than this: private func addConstraints() { introduction.attach(sides: [.top, .leading, .trailing], 8.layoutGuideRespecting) contact .attach(sides: [.leading, .trailing], 8) .space(8, .below, introduction) spinner.center() error .attach(sides: [.leading, .trailing], 8) .space(8, .below, contact) create.attach(sides…
Agreed... I'd much prefer a declarative layout language though. With complex layouts, it's hard to debug AL if you aren't the one who built it. Even stackviews, which was Apple admitting that simple layouts are too verbose to do with AL, are a mess.
Last problem is that everything in Interface Builder still lives apart from the code. I think in Android everything gets compiled and is safe to use from there, with IBOutlets you're always either taking the risk (!) or dealing with optionals everywhere (?)
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#6Earlier quoted context omitted.
> AutoLayout is verbose and complex, even with helper libraries. I don't think they can get much shorter than this: private func addConstraints() { introduction.attach(sides: [.top, .leading, .trailing], 8.layoutGuideRespecting) contact .attach(sides: [.leading, .trailing], 8) .space(8, .below, introduction) spinner.center() error .attach(sides: [.leading, .trailing], 8) .space(8, .below, contact) create.attach(sides…
Agreed... I'd much prefer a declarative layout language though. With complex layouts, it's hard to debug AL if you aren't the one who built it. Even stackviews, which was Apple admitting that simple layouts are too verbose to do with AL, are a mess.
[0] - https://daringfireball.net/2018/04/scuttlebutt_regarding_ui_...
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#7Earlier quoted context omitted.
Agreed... I'd much prefer a declarative layout language though. With complex layouts, it's hard to debug AL if you aren't the one who built it. Even stackviews, which was Apple admitting that simple layouts are too verbose to do with AL, are a mess.
Rumor is that official, cross-platform declarative layouts are coming to iOS from Apple [0]. [0] - https://daringfireball.net/2018/04/scuttlebutt_regarding_ui_...
https://thehackernews.com/2018/06/porting-ios-apps-macos.htm...
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#8Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#9Furthermore, anytime I see someone complaining about it and I check out their solution with AL... they've overcomplicated how they're setting constraints and doing the layout, and it ends up usually being the issue more than AL itself.
Re: Show HN: Lima, a Swift-based DSL for responsive iOS development
#10Earlier quoted context omitted.
Rumor is that official, cross-platform declarative layouts are coming to iOS from Apple [0]. [0] - https://daringfireball.net/2018/04/scuttlebutt_regarding_ui_...
Did that not turn out to be uikit port to macos? https://thehackernews.com/2018/06/porting-ios-apps-macos.htm...
[0] - https://mobile.twitter.com/gruber/status/1014490721909444608
[1] - https://mjtsai.com/blog/2018/05/01/scuttlebutt-regarding-app...