You are applying a one way arrow to events where in real life events do change state and can completely change UI (and functions) itself. Which makes imperative always the superior mode.
What you described works only in super simple scenarios. Whink Web 1.0, when Javascript was used for basic form validation at best, and didn't change DOM that much.
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 required to use it, nobody would, which makes it a failure.
SwiftUI, should have been a rendering template/library integrated with UIKit. Also, cleaning up some of the UIKit syntanx and framework (simplifying it), and use SwiftUI as a template for UI, would have been ideal.
SwiftUI instead was pitched as replacement, yet it is not near as capable as UIKit, and it is not feature parity even 7 years later.
Just bad leadership by Apple in this case. (probably many of these decissions were 'promo / resume padding driven' as it happens in many large companies).
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 without Steve Jobs the first time round. On paper there are a lot of cool tech being worked on. But in the end it was tech from NeXT that really shines.
And a lot of these tech don't actually benefits the customers. If the choice was a language and framework that is slightly harder to developers but brings overall higher quality Apps because the barrier is higher. Compared to a language that wants to replace Assembly to Javascript while being easy to learn like Visual Basic and for everyone to code. I would much rather pick the former.
Edit: I suddenly remember I also submitted a Core Animation introduction video from Steve a while ago on HN [1]. 20 years later we have gone backwards on a lot of things.
I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.
My iPhone 16 Pro is the jankiest user experience I’ve had on a new iPhone ever. On my Mac the settings app pauses and stutters. Jobs would have thrown things if he ever saw this.
I knew Apple was lost when they dropped the “Home” button, just after spending a $1B to build a Palo Alto headquarters in the shape of the “Home” button.
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.
On the contrary, they care enough about facts not to take a random, implausible and unsubstantiated claim at face value. Please don’t resort to Bulverism.
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.
That’s exactly the point. Why would you expect others to even entertain a vague claim like that if you give them no reason to find it plausible? “Just test it yourself” (test what?) i.e. “prove me right yourself” is not going to be very successful.
… Or perhaps I too would be interested to know what you allege is faster on your 2019 MacBook? Or was it only ever meant as “random noise opining” and nothing more?
> 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.
That's what Objective-Smalltalk is, or rather, what it started out as.
It has now gone further to actually implement Brad Cox's idea of a "Software IC", by taking on ideas from software architecture and metaobject protocols.
> SwiftUI, should have been a rendering template/library integrated with UIKit.
Do you mean it should have used some sort of XML-ish/HTML-ish templating mechanism? For Interscript, I keep looking at that approach, but so far haven't gone down that road (except for HTMXNative, but there it actually is HTML, so...).
> 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 required to use it, nobody would, which makes it a failure.
The Objective C at StepStone was completely different than the one at NeXT. It was very primitive. Steve Naroff did pretty much all of the heavy lifting, and turned Objective C into a language that could be used to create NeXTStep, and then OS X, and eventually iPhone.
SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder.
It is a newbie trap. It is great at producing simple apps, or things that don't require intense scrolling, or anything with heavy animations and precise layouts, but when you do something smooth, it is not it. It feels more of a React Native competitor, than a true UIKit replacement.
Also, almost everything that Apple has re-wrote with SwiftUI, came out worse as before (Settings, Spotlight, etc), and that doesn't help.
With AI coding... SwiftUI lost its edge/advantage (easy to layout screens), as now you code less of that directly, and might as well just go fo the framework that allows the most flexibility and gives you the best results for your users.
Apple really needs to either double down on it, and make it such that it has everything that UIKit has (match both features and performance), or just turn it into another optional framework, just as Interface Builder (.xib files) back in the day of Objective-C.
Right now it heavily promotes it as a first class citizen, meanwhile the features are not even parity with UIKit. It is so misleading to newcomers to the platform.
Ps. The other upsetting thing about SwiftUI, is that it has hurt the Swift language as well, as the team has had to introduce all kinds of hacks, or obscure features to the language in order to make it work, which made even the Swift language experience worse and more complicated than it should have been.
> With AI coding... SwiftUI lost its edge/advantage
On the contrary, I think AI has made it EASIER to approach SwiftUI now, because AI makes up for SwiftUI's biggest weaknesses: the many ways of doing everything, Apple's wonky documentation and the need to know when to fall back to AppKit/UIKit.
Maybe for you. But SwiftUI promise was to make coding UI easier for the programmer similar to ReactN, but with AI coding that is not necessary anymore, you can go straight to UIKit which is most stable and feature complete.
In car terms:
UIKit - Manual Transmission - you control everything, but a bit of a chore
SwiftUI - Slushbox Auto Transmission - easier to drive, sucks for performance
UIKIT+AI Coding - Dual Clutch Transmission - both great performance, and easy to control/drive
Imagine being more money hungry than EA - a company which makes billions from gaslighting children into gambling money on getting their favourite players.
What you described works only in super simple scenarios. Whink Web 1.0, when Javascript was used for basic form validation at best, and didn't change DOM that much.