| ▲ | rayiner an hour ago |
| The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is the company that shifted from Toolbox to Carbon to Cocoa and each step was better than the last. Could Apple build MacOS X and Cocoa today if they didn't already exist? Microsoft's two decades of failure to ship a true successor to Win32 suggests that Microsoft (at least, the operating system side of the company) died a long time ago. I wonder if we'll say the same thing about Apple 10 years hence. |
|
| ▲ | steve1977 an hour ago | parent | next [-] |
| I think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving. But I feel like Apple wanted to appeal to young web devs and tried to offer something more similar to what these are used to. |
| |
| ▲ | monster_truck 36 minutes ago | parent | next [-] | | Totally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left. I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it. | | |
| ▲ | rudedogg 23 minutes ago | parent [-] | | > Whatever it is, SwiftUI isn't it. I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem. It feels like someone with a lot of organizational power is disconnected from the pulse of the community. SwiftUI is undeniably clean in a lot of ways, it presents beautifully and fits on slides well, but that matters less and less, and this all wasn't really working out even before LLMs disrupted things. |
| |
| ▲ | refulgentis 29 minutes ago | parent | prev [-] | | It’s a seductive idea, but it displaces who is responsible for the poor framework development onto users of the framework. It’s easy to say they were just trying to be trendy and thus the real flaw was the trend is bad and the fault of worse devs than us (the young web devs mentioned) The thing that obviates that is the trendy stuff works, yet, SwiftUI doesn’t. (source: I wrote ObjC/Cocoa as early as 2006, and switched to Flutter as my primary dev kit some years ago: it simply doesn’t have the performance issues mentioned.) |
|
|
| ▲ | skydhash an hour ago | parent | prev | next [-] |
| I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS. |
| |
| ▲ | torginus 7 minutes ago | parent | next [-] | | Imo the biggest issue with this functional model (at least in React), is that it handles things like virtualization, async, etc. poorly. Which is kinda ironic, because in a true functional language, it'd be feasible to provide 'a world model' - that is act as if the entire state is always available, and let the engine decide when to evaluate pieces of code - without any effort from the part of the programmer. | |
| ▲ | mpweiher 23 minutes ago | parent | prev | next [-] | | Not just does the computer not do functional. UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch. Further reading: Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty. https://link.springer.com/chapter/10.1007/978-3-540-92698-6_... Can Programmers Escape the Gentle Tyranny of call/return? https://2020.programming-conference.org/details/salon-2020-p... UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status https://2024.splashcon.org/details/splash-2024-Onward-papers... | | |
| ▲ | cloogshicer 4 minutes ago | parent [-] | | Thanks for those links! Some of it was great reading. What is your thesis then? What is UI? |
| |
| ▲ | dgellow 41 minutes ago | parent | prev | next [-] | | Hmm, but React doesn’t own or manage the app state. And react native has been used for pretty complex applications | |
| ▲ | poly2it an hour ago | parent | prev [-] | | Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai: https://github.com/janestreet/bonsai | | |
| ▲ | rudedogg 37 minutes ago | parent | next [-] | | > functional programming is superior for representing state in user interfaces It's always going to be slower than using something imperative. Trying to process the entire world's state for the sake of purity can feel elegant but it isn't free. And the complexity that gets added to make things performant is worse than just accepting that UIs are going to require you to jump around the tree and modify state. Every time I go through the trouble of understanding the latest web technique (React, Elm, Signals (the newest solution), etc.) to deal with state management and the DOM, I end up walking away disappointed. There's nothing new in them that you can use to improve what we've been doing for ages in native GUI toolkits. And to jump back to the original topic, yes, Cocoa was pretty decent, and SwiftUI while nice in many ways tries to Reactify native macOS development and made it worse. And it made Swift incredibly more complex and worse in hindsight. | | |
| ▲ | kodebach 20 minutes ago | parent [-] | | The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly. With imperative UI code it is incredibly easy to forget an edge case in your update logic. |
| |
| ▲ | mpweiher an hour ago | parent | prev | next [-] | | Not sure how you define "success" here. Is Bonsai used much outside of Jane Street? | |
| ▲ | skydhash 43 minutes ago | parent | prev [-] | | > Functional doesn't mean stateless. I didn't say that. User interfaces representation are mostly trees. And with functional programming you basically have Tree2 = f(Tree1). Until f is done you can't do anything really. React has a lot of escape hatches to improve performance, but they are escape hatches, not an endorsement of the architecture. With imperative programming (and OOP), you only have that single `Tree`, which you update at will. Less elegant yes, but we have modularization to help us there. What Emacs does is to keep that `Tree` as a single mutable object, but have the code be functional, while the results are imperative. |
|
|
|
| ▲ | brnt 41 minutes ago | parent | prev [-] |
| I only have to look at the iPhone fucking 17 to know Apple is long gone. |
| |
| ▲ | graypegg 38 minutes ago | parent [-] | | Genuinely curious, what’s wrong with it? I’m no huge apple fan, but I didn’t really think the 17 was more than a regular boring spec upgrade, which seems fine all things considered. (Currently on an iPhone fucking 17) |
|
