Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

51–60 of 343 posts

Re: SwiftUI After 7 Years

#51
Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit.

Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux

Re: SwiftUI After 7 Years

#52
post #40

skills issue

Somehow you being the GNOME co-creator made me curious about what the GTK/GIMP creators (Kimball, Mattis) are up to. CockroachDB, it seems. It's weird how it's so easy to miss these connections.

yeah, I often check on them - love watching what they are up to.

Re: SwiftUI After 7 Years

#53
post #3

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…

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.

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.)

Re: SwiftUI After 7 Years

#54
post #8

Earlier quoted context omitted.

I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.

It's licensing is expensive though unless the app is opensource.

I heard this repeated many times. You can create closed-source Qt apps without paying any money. You cannot statically link, though; you must obey the LGPL license; that is all. And yes, you cannot use commercial modules, but that is kinda expected.

Re: SwiftUI After 7 Years

#55
I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

Re: SwiftUI After 7 Years

#56
post #3

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…

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. Reac…

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...

Re: SwiftUI After 7 Years

#57

Earlier quoted context omitted.

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.

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.

> 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.

Re: SwiftUI After 7 Years

#58
post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.

Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.

Re: SwiftUI After 7 Years

#59
post #20

Earlier quoted context omitted.

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

> 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 tim…

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.

Re: SwiftUI After 7 Years

#60

Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit. Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux

Apple will likely never drop Obj-C, but it's been a secondary language for years now. New frameworks are all written in Swift, Obj-C is only used for existing Obj-C codebases.
Post reply on HN