30k lines of SwiftUI in production later • Hacker News Board

Re: 30k lines of SwiftUI in production later

#101

Post by breatheoften » Sat, Jan 28, 2023, 8:26 PM UTC

Aside from any quirks in the rendering model -- at a more fundamental level I can't imagine what apple is thinking with the observable object data modeling approach -- and what [seems to be plans](https://forums.swift.org/t/pitch-observation/62051) to expand it ... it feels like the ObservableObject style modeling approach has been tried a million times in various frameworks and always results in complex and difficult to debug systems -- codebases which make it inherently incredibly difficult to reason about "what happens when this data changes"

A Unidirectional flow + data flow-like solution makes so much more sense to me as the basis for sane data modeling for ui's ...

Re: 30k lines of SwiftUI in production later

#102

Post by jb1991 » Sat, Jan 28, 2023, 8:30 PM UTC

sicp-enjoyer wrote: post #100

jb1991 wrote: post #38

Earlier quoted context omitted.

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem? It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.

iOS UITableViews are what I was referring to:

> using UIKit...you use an api that recycles UI components to support lazy loading

Re: 30k lines of SwiftUI in production later

#103

Post by cutler » Sat, Jan 28, 2023, 8:30 PM UTC

Another to reason, if one was needed, to leave iOS development well alone if you value your time.

Re: 30k lines of SwiftUI in production later

#104

Post by sicp-enjoyer » Sat, Jan 28, 2023, 8:31 PM UTC

jb1991 wrote: post #102

sicp-enjoyer wrote: post #100

Earlier quoted context omitted.

Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem? It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.

iOS UITableViews are what I was referring to: > using UIKit...you use an api that recycles UI components to support lazy loading

Maybe I misunderstood. Weren't you expressing that this was a poor or convoluted solution to scrolling?

Re: 30k lines of SwiftUI in production later

#105

Post by Swalden123 » Sat, Jan 28, 2023, 9:15 PM UTC

newZWhoDis wrote: post #62

layer8 wrote: post #10

> we wanted to move our entry UI to open in a sheet and with immediate focus on the title TextField, but there’s a noticeable delay before the keyboard pops up. So we didn’t. > when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible. That such basic functionality is not possible is astonishing. Especially the first one should be a common use case.

Something else is going on, I have no such delay with @Focus set onAppear { }

I agree, in latest swiftui versions what they want is possible. The same with the keyboard opening and closing when pressing next. There’s an issue elsewhere

Re: 30k lines of SwiftUI in production later

#106

Post by latchkey » Sat, Jan 28, 2023, 9:20 PM UTC

newZWhoDis wrote: post #60

SpaghettiX wrote: post #21

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

Flutter has massive performance issues, is based on a dead end language nothing else uses that lacks basic features, and worst of all is essentially Google developed. Native devs are going to make a lot of money rebuilding apps for companies foolish enough to base their entire company on a Google “product”

Have you written anything in Dart? I found it super easy to pick up and fantastic to write code in. There weren't really any specific features I found missing in the language.

Not all apps require 120fps performance either, mine was just buttons and feedback from the backend.

Flutter was actually perfect for this application.

Re: 30k lines of SwiftUI in production later

#107

Post by plorkyeran » Sat, Jan 28, 2023, 10:33 PM UTC

StewardMcOy wrote: post #76

lapcat wrote: post #51

Earlier quoted context omitted.

AppKit has been going downhill for years.

I don't know why this is being downvoted. The situation is more complex than this simple comment, but the sentiment is correct. The reality is that AppKit has had its ups and downs recently. There are obviously people in Apple trying to do their best to patch things up, and there have been some nice improvements because of their efforts, but some really bad bugs have been introduced, only to sit unfixed for years. It…

The worst part is that new things are often completely broken or outright missing in beta 1, and then by the time you can actually test them in beta 3 it's too late to report bugs and have any real hope of them getting fixed.

Re: 30k lines of SwiftUI in production later

#108

Post by solarkraft » Sat, Jan 28, 2023, 11:52 PM UTC

jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

> if only I could easily bring in my toolset of choice, whether it is Elm, Redux, etc, with all the power that native controls on iOS have, that would be awesome. SwiftUI is the only valid answer

Time for the obvious question: Why not React Native?

Re: 30k lines of SwiftUI in production later

#109

Post by solarkraft » Sat, Jan 28, 2023, 11:57 PM UTC

lapcat wrote: post #94

Klonoar wrote: post #82

Earlier quoted context omitted.

Uhhh, not sure I agree. You could argue it’s stagnant, maybe - but it’s just as good as it’s always been.

> You could argue it’s stagnant, maybe Quite the opposite. I would argue that macOS (the artist formerly known as Mac OS X) is quickly being transformed into iOS. Big Sur was a massive change in this respect, and the transformation continues in Ventura.

iOS has a super solid UI, so that would be great. Instead Control Center takes 2 seconds to show up and without any animation.

UI wise at best it's some paint. The port of Stage Manager is horrendous as well.

Freedom wise I find it just about still tolerable. You can still run non-blessed binaries after some hoops and access a good amount of APIs.

Re: 30k lines of SwiftUI in production later

#110

Post by solarkraft » Sun, Jan 29, 2023, 12:04 AM UTC

bsaul wrote: post #20

the worst isn't mentioned : not only is swiftui causing all kinds of glitches of it own, but despite being a brand new framework, it still locks you 100% to apple devices. I mean, i had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering, making at least part of the code reusable somewhere. But no, still 100% lockin. Which to me is a HUGE missed opportunity.

> I had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering

LOL!

Any other vendor: Big maybe (Microsoft figured out a few iterations late that it might help against being left behind). Apple: Of course not.

Even for their cross-platform services they'd rather make the same app twice than accepting even a 20% higher likelihood that iOS apps also get released on Android.