A WWDC 26 Update on Building a Mac-assed App with SwiftUI
31 points by diktomat
31 points by diktomat
The tale of .environment(\.backgroundProminence, _) is just the kind of thing that makes SwiftUI so difficult when you're off the beaten path. Its API is super composable, but discoverability suffers compared to traditional OO view systems: Although Swift's language design is oriented toward IDE completion after a ., when there are hundreds of options in that popup, you have to hit the docs after all. View modifiers often just set environment values, and environment values' effects on particular views aren't documented and the source is closed, so in unfamiliar territory you can expect trial and error.
There is way too much magic involved in trying to make the false claim "UI is a pure function of the model" appear true.
UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side
The reality is just different. The UI is a "thing" that communicates with the model. This communication, this dataflow, is an important aspect of the system, you can't hide it away behind magic @ incantations. Well you can, but you can't expect it to turn out well.
Whereas these system pretend that the UI is or should be completely ephemeral, for the user the UI is / should be the most solid piece of the system.
The content of the UI is a function of the model, though it isn't pure.
I found that article a bit hard to understand, I don't disagree with that UI can get a lot messier than a pure function allows, but still having a way to ergonomically manage side-effects seems to be desirable no?
I like declarative stuff, but I don't think they are the endgame of UI stuff.
I also like declarative stuff.
The point of the article is not that there isn't a problem to be solved. It's that pretending it away doesn't actually work.
The best analysis I have seen is by Stéphane Chatty: Programs = Data + Algorithms + Architecture: consequences for interactive software engineering.
It's a bit of slug to get through, but the crux is that the problem with programming UIs is that the architecture you need for UI is fundamentally mismatched with the call/return (procedural/functional) architecture of our programming languages.
So trying to solve the problem by going all-in on a functional approach is exactly the wrong direction, despite the fact that it has some benefits.
I wrote a little bit about it here: Can Programmers Escape the Gentle Tyranny of call/return?.
My current solution is Objective-Smalltalk, an architecture-oriented programming language. The core idea, an architecture-oriented metaobject-protocol is described here: Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status.
With the basic language mostly implemented, I am currently working on a UI framework I call InterScript that puts these ideas into practice. So far it is looking very good.
SwiftUI is so annoying - it’s basically “let’s do a completely new UI API, it will be easy because we can make it looks different so people will know to not expect it to behave like Mac apps have done for the last 20 odd years”