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

161–170 of 343 posts

Re: SwiftUI After 7 Years

#161

Post by mpweiher »

asa400 wrote: post #111
mpweiher wrote: post #80

Earlier quoted context omitted.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Funny, this almost reads like a description of how Elm works.

Yep, to anybody who actually knows MVC, the whole Elm/React/SwiftUI stuff is funny.

"We solved the problems of MVC by properly applying MVC".

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

Re: SwiftUI After 7 Years

#162

Post by mpweiher »

LoganDark wrote: post #109
mpweiher wrote: post #80

Earlier quoted context omitted.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Are you saying the UI always updates its entire self whenever anything changes in the model?

Yes and no.

Conceptually, the UI re-renders itself completely in order to always be an accurate reflection of the model.

That is the #1 job of the view: be an accurate reflection of the model.

And re-rendering itself completely is a safe way to implement that requirement.

However, the UI can also look at the model in more detail and figure out what parts need to change, as long as the effect is the same as re-rendering everything.

And the model can tell the view that specific subparts of the model have changed to make that job easier for the view.

But if it can't figure out the details, the fallback is to re-render the entire view from the model. But not to recreate the view. The view sticks around.

One way of doing this optimization is "damage rects" like Cocoa does. Another are the polymorphic identifiers used in the update queue of Blackbird.

Re: SwiftUI After 7 Years

#163

Post by mpweiher »

ardit33 wrote: post #143
mpweiher wrote: post #80

Earlier quoted context omitted.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Dude, you didn't describe MVC at all, but MMVC. MVC, the controller is the intermediary between the services/data models, and the views. That still one of the best / simplest way to build large apps. MMVC is just a variation of it, with the models being able to communicate state to views and bypass controller if needed. MVC, is still one of those 'fundemental as simple as it gets, and it gets the job done' patterns.

Dude, what I describe is exactly MVC.

Your interpretation is a common misconception, for example promulgated by Apple. It is not MVC.

https://blog.metaobject.com/2015/04/model-widget-controller-...

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

"A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. "

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

Re: SwiftUI After 7 Years

#164

Post by il-b »

mintflow wrote: post #115

As a solo app developper for two years mainly for apple platform(previously do networking infra software using C/Go) After two many trial and fail, now it's quite clear to me that for simple UI I will use swiftUI(such as help sheet or simple toggles), for complex and performance first, I will just use UIKit instead, it save a log of time and actually the imperative UIKit is also quite easy to read and review the feas…

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.

Re: SwiftUI After 7 Years

#165

Post by sirwhinesalot »

rayiner wrote: 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…

The problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime.

Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's performance in the process.

SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, rather than treating them as deprecated implementation details that devs nonetheless keep having to drop down into.

These decisions come down to ego, of wanting to do away with the old and carve out your own legacy separate from it. Nice if you want a promotion but not so nice if you're trying to make a long lasting ecosystem for developers to build upon.

At least Swift and SwiftUI have a reasonable interoperability story with the past. Can't say the same about Microsoft's graveyard of UI frameworks.

Re: SwiftUI After 7 Years

#166

Post by spacedcowboy »

blltprfmnk wrote: post #77
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

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.

Re: SwiftUI After 7 Years

#167

Post by layer8 »

fidotron wrote: post #153
rayiner wrote: 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…

The underlying problem is the programming industry completely resisting learning the lessons of Objective-C because it doesn't like them. It didn't like them when NeXT tried selling it, and it doesn't like it now. You can't have Cocoa without Obj-C, or at least a langauge and runtime with that philosophy. Apple software has been on a clear decline for a seriously long time, and it's propped up almost entirely by them…

As someone who hasn’t used the language, I’m curious about what the valuable lessons of Objective-C are that the programming industry is resisting learning.

Re: SwiftUI After 7 Years

#168

Post by mpweiher »

steve1977 wrote: post #85
rudedogg wrote: post #57

Earlier quoted context omitted.

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

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 ballpark with Apple Silicon.

The one for software is still upcoming.

Re: SwiftUI After 7 Years

#169

Post by mpweiher »

cloogshicer wrote: post #73
mpweiher wrote: post #56

Earlier quoted context omitted.

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

Thanks for those links! Some of it was great reading. What is your thesis then? What is UI?

"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter."

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

View and model are related, but neither is procedurally dominated by the other. The view is not a subroutine of the model, or vice versa.

They are related entities that communicate in order for the view to function as a representation of its model to the user, and for the model to be manipulated by the user.

To get the details I really recommend the Chatty paper. It is a bit hard to read, but delivers the goods.

Re: SwiftUI After 7 Years

#170

Post by kikimora »

mpweiher wrote: post #157
kikimora wrote: post #130

Earlier quoted context omitted.

MVC is not bad, but it is not a silver bullet. Calling MVC an ultimate solution to UI is oversimplification. Just looking at the steps you listed I can ask: How do you collect all notifications on step 2 to fire them on step 3 such that UI does not re-render itself too much? E.g. updating a title of each item in a list of 100 items should not trigger 100 renders. Or 100 layout calculations (which I think is harder to…

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…

>The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it becomes coarser-grained, and weeds out duplicates based on that coarser grain

This is not about duplicates. For example, sync updates 100 items in a list changing their titles. Items are bound to a list in the UI. Thus, 100 unique title update events triggered.

>Events are only used in the M→V communication

I don’t understand. Button clicked -> model change -> view update -> new event triggered -> model or view updated again … This is not something one would code on purpose, but often an attempt to create relationships between view. Like a custom layout code. Might not include model at all, just views being updated in an event handler trigger more events and more updates to views.

Post reply on HN