4 ms·
Auto-layout really does introduce nightmarish levels of verbosity when you try to do layout in code. I hope that Apple one day takes inspiration from Sundell's
by Reason077 8y ago
Auto-layout really does introduce nightmarish levels of verbosity when you try to do layout in code.
I hope that Apple one day takes inspiration from Sundell's "Autolayout DSL" and comes up with a more lightweight syntax!
- ken 8y agoComparing: label.topAnchor.constraint(equalTo: button.bottomAnchor, constant: 20), and: $0.top == button.bottomAnchor + 20 (Sundell's first example), I'm not seeing a 'nightmare'. It's twice as long but it still fits on one line (the way I format it), and it's only a linear problem (2N vs N), and it only occurs for a few lines of one method of some classes. For people who care, it's possible to write extensions (as Sundell does) to solve it. There's definitely abstractions that are nightmarish to try to build in Swift and AppKit/UIKit, but I don't think this is one of them.
- mpweiher 8y ago> abstractions ... nightmarish ... Swift and AppKit/UIKit What would those be? Genuinely curious.
- stefano 8y agoCore Data comes to mind, especially when dealing with multi-threading scenarios. For new projects, I switched to a thin wrapper around SQLite (SQLite.swift) and never looked back.
- weiming 8y agoWe've been using a DSL called SnapKit (was called Masonry in ObjC days) for years to make things way more tenable: http://snapkit.io/ http://snapkit.io/ If the maintainers happen to be on HN, thank you making for this! Something like: make.left.equalTo(foo.right).offset(15) make.width.equalTo(400)