In my experience, object oriented view systems like Cocoa (UIKit or AppKit) work great for small teams with deep domain knowledge of their code base. However, they constantly require refactoring as teams grow and systems become more complex. This leads to overly complex UI code over time that become brittle.
UI through composition, building UI through assembling components from other components, has done away with those issues. The enforced encapsulation is frustrating that I agree is a trade off, but refactors become simple find and replace to point to new components instead of having to rewrite entire chunks of previously working code.
> UI through composition, building UI through assembling components from other components, has done away with those issues.
it should be noted, you can do this just fine in cocoa/uikit with delegation/message forwarding etc. but most people dont know about that ime
lots of subclassing and overriding is much harder to avoid with view controllers but view-level subclassing is usually an anti-pattern (if i got a dollar for every time i found a "RedButton" class id be a millionaire) but like most things people aren't either experienced or educated enough in these frameworks
> However, they constantly require refactoring as teams grow and systems become more complex. This leads to overly complex UI code over time that become brittle.
i think this becomes true with any system, but subclass-heavy code makes it definitely harder imo
> ...is frustrating that I agree is a trade off, but refactors become simple find and replace to point to new components instead of having to rewrite entire chunks of previously working code.
if done well it is easier in swiftui for sure, but the way i see people write "in the real world" swiftui is used in a much more monolithic fashion and hard to pull-apart... (personally i love swiftui) but i think real-world usage will still he mudballs in a large portion of codebases (there is no silver bullet)
> lots of subclassing and overriding is much harder to avoid with view controllers but view-level subclassing is usually an anti-pattern (if i got a dollar for every time i found a "RedButton" class id be a millionaire) but like most things people aren't either experienced or educated enough in these frameworks
At some point if the system guides everyone into doing it the wrong way, it's a problem with the wrong system. Subclassing is rarely the right solution, one of the things that's really refreshing about React is that most people tend to naturally avoid subclassing when using it.
The thing here is, you can have OOP toolkits that make writing custom components easy. And then you have encapsulation and composition, without needing the React machinery. It is the case though, that the most well known OOP UI toolkits see creating custom components as a somewhat advanced use case and don't optimize for it, whereas in ReactJS/JetPack Compose, it's fundamental and you do it all the time.
UI through composition, building UI through assembling components from other components, has done away with those issues. The enforced encapsulation is frustrating that I agree is a trade off, but refactors become simple find and replace to point to new components instead of having to rewrite entire chunks of previously working code.