61–70 of 257 posts
For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.
Earlier quoted context omitted.
Tying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
Well, apps using it get a uniform look, that uniformly changes when the OS look is updated so that it matches it, and more importantly, they and also get to have the same widgets and widget functionality [1].
Unlike, say, Windows where you have 20 generations of MS GUI lib versions, with different looks and behavior, running at the same time, even from MS apps themselves...
[1] Yes, Apple has its share of inconsistencies (e.g. Swift UI vs regular Cocoa UI). But nothing like what would have resulted if they allowed apps with different historical macOS UI libs/versions to be installed at the same time independently from the OS UI libs.
Earlier quoted context omitted.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
My guess would be a monetary justification. After all you can't just have developers working on year old laptops and devices when you can make them buy new ones by making this one simple change.
The reason is platform coherence and control, and lock-step updates. To avoid cases like this:
https://segmentfault.com/a/1190000040213084/en
https://ntdotdev.wordpress.com/2021/02/06/state-of-the-windo...
...and not the insignificant money that could be made from devs updating a laptop a little earlier (especially since you can trivially use a still supported 5-6 year old laptop anyway with the newest Apple OS, and you wouldn't see any major performance issue, except in cases like the Intel to ARM switching. So what would they gain? Developers forced not to use an 8 or 10 year old laptop? As if they would?).
If I was to build a new mobile app using a shiny new declarative framework, I’d rather use Flutter, because at least that provides the benefit of targeting Android for free. Depending on the type and scale of the app, of course.
Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak that should clear up the remaining issues people seem to have with it when it comes to performance and the rest of the project is incredibly well supported and documented and most importantly as you hinted at genuinely cross platform.
It’s a much better bet for basically any project outside of one that you know for a fact is only ever going to target Apple operating systems.
Earlier quoted context omitted.
IMO, you shouldn't use React-like tools in performance critical UI code. Direct DOM manipulation in such cases is much better and more maintainable option. I.e., it's easier to maintain straightforward direct DOM manipulations than all the tuning around making a React-like system more performant.
Then why use it anywhere? I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner. I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'. The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.
On the web frameworks like Solid.js are exploring these fine-grained reactivity approaches to actually re-render only what's needed, and not huge chunks of UI
Earlier quoted context omitted.
Then why use it anywhere? I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner. I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'. The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.
>Then why use it anywhere? To write code quicker, and make it easier to maintain. If it's a moderately complicated UI, then I could code it up much faster in React (my guess is around 10x). IMO, React isn't about functional programming, it's just a good DSL for writing UI.
Yes, it's faster to write. Is it easier to maintain? Doubtful. Especially when you inevitably run into issues that your whole UI re-renders a couple of hundred of times a second, and you have to go in and butcher everything with useMemos, caching etc.
Earlier quoted context omitted.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
> I wonder what is the technical justification for it too, if any. Well, apps using it get a uniform look, that uniformly changes when the OS look is updated so that it matches it, and more importantly, they and also get to have the same widgets and widget functionality [1]. Unlike, say, Windows where you have 20 generations of MS GUI lib versions, with different looks and behavior, running at the same time, even fro…
Earlier quoted context omitted.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
It's probably the same as the technical justification for why Safari updates are bundled with iOS and not separate, why XCode only runs on macOS, why no other browsers are allowed on iOS, why macOS can't have separate scroll directions between mouse and touchpad and many many others. It's Apple's ecosystem, nobody is asking you, you're holding it wrong.
Earlier quoted context omitted.
Tying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
Also apps don't get the new "improved" styles etc if they don't have it in the system, which takes away the consistency Apple aims for.
And then: It's Apple ...
If I was to build a new mobile app using a shiny new declarative framework, I’d rather use Flutter, because at least that provides the benefit of targeting Android for free. Depending on the type and scale of the app, of course.
I know that the HN crowd has a weird relationship with both Apple and Google that go in two very different directions regardless of the evidence but honestly I think what you are proposing is actually a really good long term plan. Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak that should clear up the remaining issues people seem to have with it when it comes to performance…
1. SwiftUI seems mainly suited for building quick proof-of-concept simple intro apps, with the difficult 20% still out of reach. Which doesn’t sound all that different from the notorious downsides of cross-platform frameworks, some of which can allow for small simple apps to be quickly spun up, but the tough under-the-hood cases still intractable.
2. Flutter, and React Native are more mature than SwiftUI is right now. SwiftUI will get there, and maybe it’s only 1-2 years away, but it still hasn’t hit its Swift 5 moment yet. That opens up the possibility of breaking API or even conceptual changes until then.