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

251–260 of 343 posts

Re: SwiftUI After 7 Years

#251

Post by ben_w »

steve1977 wrote: post #220
iainmerrick wrote: post #175

Earlier quoted context omitted.

Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it. As Apple gradu…

Maybe responsive layouts are part of the problem? I get their appeal (in the sense of only having to develop one layout), but IMHO, in many cases more strict layouts would be the better choice. You mention classic apps having a fixed layout, I think that's a good thing. Not every user interfaces makes sense in portrait AND landscape mode for example. And the slightly different sizes of iPhones are not really that pro…

> And the slightly different sizes of iPhones are not really that problematic with something like autolayout

It can be problematic regardless of the technical solution, though generally I have to agree with the loudest voices on this thread: SwiftUI is a load of rubbish, UIKit and autolayout (and Interface Builder) was better.

Regarding problems with all layouts: I've got a 2022 model iPhone SE, so smallest screen, and every so often run into an app which just doesn't handle the screensize right. I've seen this happen as a developer with both UIKit and SwiftUI, it's just the type of bug you end up seeing is different.

Re: SwiftUI After 7 Years

#252

Post by dwaite »

ardit33 wrote: post #138
ksec wrote: post #122

Earlier quoted context omitted.

7 Years of release on Swift UI, 12 years for Swift. This isn't 7 years of development, but 7 - 12 years after release . And to most these past 7 - 12 years are an ongoing beta development. It is unfinished, unpolished with no end in sight. And I have been extremely critical since the beginning. But the problem runs much much deeper. It isn't the technology that is the problem, not the devs who are making it. It is th…

I agree with you. Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind. it would have been a great language, meanwhile they decided to throw everything out and created a language that it is overcomplex, and it is failing to gain any traction outside iOS / Apple's ecosystem. Basically, if you weren't req…

> and leave the archaic and the weird things behind.

The number one archiac/weird thing was message passing instead of methods. Number two was square brackets for message passing.

What would be left of Objective-C once these were left behind?

> and it is failing to gain any traction outside iOS / Apple's ecosystem.

Objective-C was on a path to gain serious traction outside of the Apple ecosystem?

Re: SwiftUI After 7 Years

#253

Post by dwaite »

layer8 wrote: post #167
fidotron wrote: post #153

Earlier quoted context omitted.

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.

[dead]

Re: SwiftUI After 7 Years

#254

Post by meerita »

ksec wrote: post #145
ardit33 wrote: post #138

Earlier quoted context omitted.

I agree with you. Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind. it would have been a great language, meanwhile they decided to throw everything out and created a language that it is overcomplex, and it is failing to gain any traction outside iOS / Apple's ecosystem. Basically, if you weren't req…

While reading this comment, two of Steve Job's line pops up in my head. I think it was the Apple Park opening, and Steve response to insult in WWDC 199x. > "We need to be true to ourselves, and remember what is important, that is what going to keep Apple Apple, is if we keep us, us." > "You have got to start with the customers experience and work backwards to the technology. Right now it feels a lot like Apple withou…

I completely agree. Apple went from making “wow” products to “meh” products. Everything started to decline after Steve passed away.

Re: SwiftUI After 7 Years

#255

Post by dwaite »

dosisking wrote: post #208
saagarjha wrote: post #191

Earlier quoted context omitted.

This is completely false, many NeXT people still work there.

So you think that they would be able to build MacOS X and Cocoa today if they didn't already exist?

Would they want to?

If you were to build a system with no requirement for backward compatibility with cocoa or macOS, or even knowledge from such a thing existing, we have still moved forward three decades from not just NeXT, but the computing industry that NeXT was built to serve.

I'd assume their requirements would be drastically different, and the system they created would be drastically different as a result. The requirements aren't even easy to hypothesize, since iOS would never have existed.

Re: SwiftUI After 7 Years

#256

Post by dminik »

torginus wrote: post #250
dminik wrote: post #216

Earlier quoted context omitted.

I mean, it's not quite that easy. The web is a lot more dynamic than WPF. If you just want virtualized homogeneous lists, there are libraries for that (and grids). But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.

I know, that's why I said, that when you hit things like that (state that is too big to pull onto the client at once, and/or displayed at once), React's (and I guess a lot of other immutablity-based frameworks') dataflow management stops being magic, and you have to start tending to it. Which usually means this model loses all advantages compared to simple MVC, or imperative systems, and at worst, becomes another hea…

I guess my point was that it doesn't matter whether your framework/library is immutable/mutable/retained/functional/MVC/MVVM or whatever. You're hitting platform limitations one way or another.

But the rest of your app still gets the simplicity of a declarative programming model.

Re: SwiftUI After 7 Years

#257

Post by leecommamichael »

peheje wrote: post #75

Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic. The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed. My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere,…

> I have to think about everything, everywhere, all the time.

I think this is familiarity speaking, which is what you're expressing earlier in the comment anyway. The reality is that we have to think of everything when telling a machine what to do. Exactly how we get that done is preference.

Re: SwiftUI After 7 Years

#258

Post by mpweiher »

cloogshicer wrote: post #244
mpweiher wrote: post #169

Earlier quoted context omitted.

"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 communi…

Interesting, will check that out! My working thesis is that UIs are basically video games . Just a gut feeling I can't really 100% put in words. But essentially they're the same thing: Read input, update model, render view.

That's pretty much where immediate mode GUIs and to a less extent React came from. (Though for React the provenance is probably closer to the HTML web-app: send request - update model - return HTML with complete and completely new UI.)

The difference is that for most games, throwing away the complete rendered graphics and re-rendering from the world model is often the right approach.

For most UIs, it isn't, unless they really are very close to video games, for example mostly passive feed readers, video players etc.

Re: SwiftUI After 7 Years

#259

Post by MichaelZuo »

simlevesque wrote: post #246
MichaelZuo wrote: post #234

Earlier quoted context omitted.

My base 2019 macbook pro 15 on Mojave is actually faster than new macbook pros today on some tasks. There’s no way Apple doesn’t know about that internally. So I don’t see any other explanation… other than a lack of care, or a bozo explosion.

Which tasks ? I don't believe your claims.

If you dont believe me… nobody is stopping you from testing various things on the same model?

And if you dont have it already… then what could I possibly say that would motivate you to buy a used one to do the testing to confirm?

Edit: And even on my ipad pro m2 doing literally nothing other than swiping to the app library often causes a visible stutter and lag for hundreds of miliseconds… so if you really think it’s flat out impossible to find consistently slower things on the much more complex macos… idk what to say.

Re: SwiftUI After 7 Years

#260

Post by cloogshicer »

mpweiher wrote: post #258
cloogshicer wrote: post #244

Earlier quoted context omitted.

Interesting, will check that out! My working thesis is that UIs are basically video games . Just a gut feeling I can't really 100% put in words. But essentially they're the same thing: Read input, update model, render view.

That's pretty much where immediate mode GUIs and to a less extent React came from. (Though for React the provenance is probably closer to the HTML web-app: send request - update model - return HTML with complete and completely new UI.) The difference is that for most games, throwing away the complete rendered graphics and re-rendering from the world model is often the right approach. For most UIs, it isn't, unless th…

> For most UIs, it isn't

Why? Genuinely asking, this topic is very interesting to me.

Post reply on HN