3 ms·
I really don't think this is a good criticism of SwiftUI. The author is confused about the whole approach to SwiftUI and spends a lot of words complaining abou
by jmull 7y ago
I really don't think this is a good criticism of SwiftUI.
The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about commas and ifs. The things about the ifs and other potential control flow constructs makes it clear that the author doesn't get what a declarative approach really means.
Likewise, the section about "wraps" where the author feels the SwiftUI API is inconsistent because stacks "wrap" and padding "wraps" so they should use the same syntax. But I think that's just a misunderstanding of the author's. "wrapping" isn't a fundamental concept of SwiftUI so there's no particular reason for the API to be organized around it. (I would say stacks arrange a list of views and padding pads a view. Also, bold() operates on Text and returns Text because Text holds styled text and bolded Text is still Text. padding operates on any View and returns some View. The types flow naturally from the problem domain, so that's good.)
Also the conclusion: "The solution…is to be dumb and explicit!"
That's really asking for a completely different framework. It seems a little off to criticism SwiftUI for not being what it was never intended to be.
I think there is good criticism in here, though. SwiftUI introduces a LOT of patterns, concepts, many of which will not already be familiar to many developers. It's concise and reads pretty intuitively, but many developers won't get far before hitting a lot of new stuff... that means steep learning curves and confusion, like the author. I don't know if that makes it bad, but it's certainly anyone consider using it needs to be aware of.
- dmitriid 7y agoThe author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well. Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.
- jmull 7y agoHe's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.
- dmitriid 7y agoIt does make sense. Because SwiftUI creates special constructs for regular language features (if, foreach) despite those features, you know, being available in the language.
- jmull 7y agoIt doesn’t make sense because SwiftUI is a declarative language. I understand the confusion, since it uses Swift’s DSL feature and is tightly integrated with Swift, but it is distinct and has it’s own design that isn’t directly compatible with Swift’s imperative control flow constructs. Now, you can argue that Apple should have created a new imperative Swift-integrated UI framework, and if they had, it would be a good criticism if all the normal Swift control-flow mechanisms weren’t available natively. But the author and you aren’t objecting to SwiftUI’s declarative nature. BTW, If you manage to map all the kinds of loops, breaks, etc, into SwiftUI it isn’t declarative anymore. You’ve managed to go back from describing the UI in terms of “what” (declarative) to “how” (imperative). Since the author expresses approval of the declarative nature of SwiftUI and complains about it, I know he’s confused.
- dmitriid 7y agoNo. I, and the author, argue that nothing prevents Swift from having declarative foreach/if. SwiftUI already introduces severely underdesigned awkward structures to replicate existing behavior, and it shouldn't. SwiftUI's ForEach and If are ugly unnecessary hacks that replicate existing behavior and raise the question: why aren't other constructs there?