Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

311–320 of 343 posts

Re: SwiftUI After 7 Years

#311
There was a post on here awhile ago from Jeffrey Snovers blog about how Microsoft screwed this up as well. Given how many people have moved to electron, and how big companies don’t seem to be able to handle native GUI’s anymore, have we just made the desktops too complicated?

Re: SwiftUI After 7 Years

#312

Earlier quoted context omitted.

Why should I need to do any testing ? I'm just going to keep on not believing you until you back up your claims. And your iPad example doesn't make sense at all, you compared 2 Macbooks and now you're talking about another OS altogether. > idk what to say. You could just tell us one example of something that's faster on your 2019 Macbook Pro 15 versus a M5 Macbook pro and how to reproduce it.

If you dont ever intend to do any testing… then why would anyone care about what you believe or not? Why post random noise opining?

Since when did asking someone to give a single example to support their point become "noise"?

How can they do any testing, if you refuse to tell them what to even look for?

Re: SwiftUI After 7 Years

#313

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…

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

Well, that is what "retained mode" GUIs (i.e. those using control/widget trees and such) do too.

The immediate mode GUI to me always felt like an approach came up by people who do not really want to bother doing GUIs. In terms of games it is like mixing logic and presentation in a game like, e.g.

    int x, y;
    while (game_running) {
        draw_sprite(player, x, y);
        if (key_down(LEFT)) x -= 1;
        // etc
    }
basically like in a game that doesn't have a world model with entities etc, just draws sprites directly, handles input directly, etc. Which is very simple for simple stuff but doesn't scale as complexity increases.

Same with immediate mode GUIs and i don't think it is a coincidence that the more complex an imgui gets, the more it starts looking like a "retained mode" GUI and the gnarlier the code becomes.

Re: SwiftUI After 7 Years

#314

Earlier quoted context omitted.

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…

You’re shifting the burden of proof. You made a claim and refused to substantiate it in any way whatsoever.

Re: SwiftUI After 7 Years

#315
post #309

Earlier quoted context omitted.

> until they saw the Objective-C adoption numbers were high enough. Nope. Until they saw that (a) CocoaJava was a complete dud, not just technically, but also in terms of developers buy in and (b) Cocoa/ObjC was accepted well by a large part of the dev community. > > "Garbage collection is deprecated in OS X 10.8. Use ARC > ARC is garbage collection, In terms of the Apple ecosystem, "Garbage Collection" refers to the…

Ah, the famous reality distortion field where industry terms get the meaning that suits Apple's marketing team and developer advocates.

[deleted]

Re: SwiftUI After 7 Years

#316
post #122
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…

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…

My opinion is that good old UIKit based on MVC (Model-View-Controller) is simply excellent for building scalable, complex and performant UI's in traditional, compiled languages. The declarative, state-driven UI works wonderfully on the small keynote-demo scale but needs a specialized language to support it on the large scale. Otherwise you waste a LOT of time debugging.

And Swift is simply just not that language. Apple should have just invented a specialized UI DSL to support SwiftUI. And continued to support good old MVC first-class. Explicit Constraints, Lifecycle Clarity and Programmable Control make UIKit apps easier to debug and fix.

SwiftUI should cleanly extracted out its reactive framework as a standalone, public framework for non-UI or decoupled use-cases. That would have helped in fixing a lot of issues.

Re: SwiftUI After 7 Years

#317

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.

Apple Maps says otherwise.

Re: SwiftUI After 7 Years

#318
post #312

Earlier quoted context omitted.

If you dont ever intend to do any testing… then why would anyone care about what you believe or not? Why post random noise opining?

Since when did asking someone to give a single example to support their point become "noise"? How can they do any testing, if you refuse to tell them what to even look for?

Uh are you confused?

I’m not the one claiming they refuse to test it, they are the ones who said so.

Re: SwiftUI After 7 Years

#319

Earlier quoted context omitted.

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…

You’re shifting the burden of proof. You made a claim and refused to substantiate it in any way whatsoever.

I’m not trying to prove anything…?

I just don’t care that much either way about what others think if it’s adversarial, even if thousands of HN users come to this comment chain to opine about this or that macbook model.

If you mean my claim that some team in Apple already knows about it, there’s literally no way to prove that to passing readers.

Re: SwiftUI After 7 Years

#320
post #302

Earlier quoted context omitted.

To each his own, but I actually like it

Genuinely curious: do you have experience with other environments, or mostly Apple?

Excellent question. I have mostly used Apple tools, but have also tried (most notably) VSCode, android studio, zed, Eclipse, vim and Sublime Text. None of these convinced me, except Sublime which I still use for “non-Apple” projects (also non-android, obviously). I also like vim, but not for coding, just as a general text editor.

I particularly hate VSCode, for some reason (the reason is not that it comes from M$ if you’re wondering; I’m not really sure why tbh, probably because it’s electron and feels particularly not native).

I am aware of IntelliJ, but have never tried it. Given that android studio is based off this AFAIK, I’ll probably not really like it either, I guess? idk

Post reply on HN