Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

221–230 of 343 posts

Re: SwiftUI After 7 Years

#221

Post by jonhohle »

dminik wrote: post #217
il-b wrote: post #164

Earlier quoted context omitted.

Somehow, we’re still failing to realize that the most complex UIs - think CAD software, 3D editors, etc - are imperative, object-oriented, and written in C++. Their core development teams are usually very small. Yet you need a 20-person frontend team to deliver a primitive e-commerce app. It’s as clear as day that the promise of declarative and reactive programming is failing its users.

How much of this is that most of these tools have been around for 20+ years and come from a time where OOP was the holy grail coming to save humanity?

I think the key is these things were possible 20 years ago with small teams and now large teams and even teams at Apple can’t make competent apps with the flagship product.

I worked at a FAANG and a team was tasked with implementing a new REST framework to replace/augment the supported RPC framework. Metrics were very important and this team might have know HTTP/REST well, but they didn’t understand what operators needed. It wasn’t even on their radar. As a senior engineer, without much traction I complained and fortunately someone one level higher from across the company saw my message and had the necessary influence to get them to pause and think. I don’t know if anyone has done that at Apple.

Things that used to work universally - key bindings, drag and drop, context menus - just don’t work by default anymore. Why? Because now everything is some low level UI element and whose behavior is completely up to the programmer. Sounds like web programming, not like Mac programming.

From a programming perspective, I don’t even like the paradigm. Once understood, IOC in AppKit and Interface Builder was incredibly efficient.

Re: SwiftUI After 7 Years

#222

Post by troupo »

VerifiedReports wrote: post #135
sandoze wrote: post #62

This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…

"@environment is super cool" Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design. I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more. SwiftUI turned development, which I used to enjoy and feel good about, into…

> Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is),

And it's pretty much incapable of making anything that is not a master/detail with endless lists within lists within lists.

Just look at the shit that Apple regularly ships now: it's just endless lists of lists.

Re: SwiftUI After 7 Years

#223

Post by troupo »

frizlab wrote: post #86
spacedcowboy wrote: post #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

Having written actual apps with AppKit, it is horrendously complicated for simple things. Swift is incredibly better than ObjC on so many ways it’s just not comparable. I used it since day one and never looked back. (And I was deep into the ObjC ecosystem, having written very low-level frameworks, and having loved it.) Yeah, first versions of Swift were raw, but now it’s just THE language; I used for everything (obvi…

> But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed.

New things (especially 12 years on) shouldn't be "do simple things simpler, and drop down to old ways for complex stuff". It should be "do complex things simpler".

Re: SwiftUI After 7 Years

#224

Post by refulgentis »

pjmlp wrote: post #139
refulgentis wrote: post #53

Earlier quoted context omitted.

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

It sure does, hence why there was this whole drama with a new render engine for Flutter.

Shaders compiled at startup vs. not, not “who knows why a repaint is happening”

Re: SwiftUI After 7 Years

#225

Post by troupo »

archagon wrote: post #83
emehex wrote: 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.

It’s also not possible to make super bespoke interfaces without going against the grain of the framework: anathema to old school AppKit and UIKit devs.

Where "bespoke" is anything beyond master/detail and endless lists upon lists apparently.

Re: SwiftUI After 7 Years

#226

Post by mort96 »

mpweiher wrote: post #168
steve1977 wrote: post #85

Earlier quoted context omitted.

Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.

Yes, they don't ever openly admit mistakes. But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)". Remember "garbage collection"? Or "modern syntax"? Or CocoaJava? And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballp…

SwiftUI is too big to silently drop. It is too difficult to silently fix.

Re: SwiftUI After 7 Years

#227

Post by jonhohle »

spacedcowboy wrote: post #166
blltprfmnk wrote: post #77

Earlier quoted context omitted.

There were a lot of people actively complaining about ObjC in the lead-up to the unveiling of Swift. In fact I recall one prominent blogger in the iOS community begging Apple just a few months earlier to consider replacing it. Unfortunately although Swift seemed promising at first, by the time Swift 3 rolled around a lot of people were actively frustrated and moved on from iOS development. Having actual experienced h…

Most of the complaints about ObjC seemed to be from the “weird bracket syntax” folks, at least the loud ones. Memory management, Generics, Fast enumeration, Properties were seamlessly added to ObjC over the years without adding to the cognitive load of the language, which is minimally more than that of C. It’s a small superset of C and (for me) hits that complexity/expressiveness sweet spot. YMMV, of course.

It would be interesting if instead of a new language the Objective-C compiler enforced a a memory safe version of C. That’s the biggest advantage of Swift, imho.

I hated the properties addition in Objective-C. Why add that and not a dot syntax for all messages? Having a dot operator in a pointer blurred too much of the line between C and Obj-C syntax for my taste.

Re: SwiftUI After 7 Years

#228

Post by mpweiher »

layer8 wrote: post #172
mpweiher wrote: post #157

Earlier quoted context omitted.

I never claimed MVC is a silver bullet. Just that it solves "... incredibly easy to forget an edge case in your update logic." > UI does not re-render itself too much? Glad you asked! In my Blackbird reference architecture (which is an instance of MVC), I use a coalescing queue to capture the updates. The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it…

How do you handle UI state vs. underlying data (model) state, and dependencies between them? By UI state, I mean things like scrollbar position and selection state. When displaying a scrollable and selectable list of items, then for example when the number of items changes, the selection may need to adjust, and the scroll position may need to adjust. Depending on which items are added or removed (or reordered), the s…

>How do you handle UI state vs. underlying data (model) state, and dependencies between them?

I don't. And I don't have to, as I delegate that sort of stuff (mostly) to Cocoa/CocoaTouch etc.

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

When you have stateful view objects, these stateful view objects maintain the view state. When updating themselves with new data due to a ModelDidChange notification, they take care of reconciling their current display state with the underlying model state.

> When displaying a scrollable and selectable list of items

So for example an NSTableView or NSCollectionView. I personally use a subclass that interacts directly with a table representation, meaning a lot of the glue code that Cocoa(Touch) requires disappears.

> Who updates the UI state accordingly to make it valid again?

Always the view. Who else?

> In the general case, application code needs to be involved in choosing the desired valid UI state when the underlying model state changes.

How so? The view is always a reflection of the model data. Whether that is a "change" is actually mostly irrelevant, even though the notification is called ModelDidChange in my case. In Smalltalk MVC it is the #changed message. It means "you are out of date, please make yourself reflect the model".

This same mechanism also handles the model being changed by some other party without any further code. "The model has changed, please update yourself to reflect the current state of the model". That's it, modulo optimizations.

> How is the corresponding application code prevented from triggering further events?

Model code isn't involved. A ModelDidChange event is only triggered when...er...the model changes.

That said nothing prevents you from manually invoking the ModelDidChange notification, just like nothing prevents you from calling abort(), running an infinite loop, creating an unbounded recursion or reading from /dev/random until it is exhausted ...

Doing it by accident, though, is very hard, because it just isn't part of the programming model.

Re: SwiftUI After 7 Years

#229

Post by dminik »

jonhohle wrote: post #221
dminik wrote: post #217

Earlier quoted context omitted.

How much of this is that most of these tools have been around for 20+ years and come from a time where OOP was the holy grail coming to save humanity?

I think the key is these things were possible 20 years ago with small teams and now large teams and even teams at Apple can’t make competent apps with the flagship product. I worked at a FAANG and a team was tasked with implementing a new REST framework to replace/augment the supported RPC framework. Metrics were very important and this team might have know HTTP/REST well, but they didn’t understand what operators ne…

No offense, but this doesn't seem like a realistic way to look at things.

Autodesk (since you mentioned CAD) itself dates back to 1980s. And even then, they had at least 15 people working on AutoCAD. That's a small team size. Today, they have over 14000 employees. Some random website tells me they had ~5000 of them 20 years ago. You can make anything work when you throw an army of people at it. It's not exactly a good point towards small teams being able to build complex imperative/OOP apps.

That's not to say that Apple is not dropping the ball here. I don't really have any Apple devices to check for myself, but I know that Microsoft, for instance, has been doing much more than just dropping the ball when it comes to UI. But, I'm not sure that has anything to do with imperative vs declarative.

Re: SwiftUI After 7 Years

#230

Post by pjmlp »

refulgentis wrote: post #224
pjmlp wrote: post #139

Earlier quoted context omitted.

It sure does, hence why there was this whole drama with a new render engine for Flutter.

Shaders compiled at startup vs. not, not “who knows why a repaint is happening”

It was a bit more than that, including how out of place it looked in fruity platforms.
Post reply on HN