3 ms·

I feel like it is a mistake to bring what is effectively React to native development. Browser-based web apps are basically punching above their weight class. C

I feel like it is a mistake to bring what is effectively React to native development. Browser-based web apps are basically punching above their weight class. Compared to the power of native UI's, the browser is broken. React understood this and created two innovations: 1. The Virtual DOM 2. The reactive UI Now, I'm no expert, but Number 1 seems like a terrific idea; and Number 2 seems like it's needed in order to implement Number 1. But, to my thinking, a reactive UI is a big problem of leaky abstractions, which is what I think you're saying. To me, iOS/macOS UI development needed neither the baby nor the dirty bathwater. I feel like the whole thing is a mistake. As a programmer, I want control over updating the UI.

com2kid 4y ago
React is terrible at reactive[1] UIs. You have to do a lot of work to tell react what to not rerender. Of course things generally work if programmers aren't careful, but the UI gets slower and slower over time as more features are added and more repaints are done. VDom is one of those arguable things, plenty of frameworks are faster than React w/o a vdom, and some frameworks are faster than React and also use a VDom. [1] Arguably react is not even that reactive, you have to manually wire up everything yourself.
MH15 4y ago
You have this backwards no? The virtual DOM is needed in order to support Reactive UI, in most cases (svelte comes to mind as an exception).
- mariodiana 4y ago
  I think you're right, now that I think about it again.
georgelyon 4y ago
For the record, you do have fairly fine grained control over what updates when with SwiftUI. The issue is that this isn’t obvious to new developers, nor is it easy to understand what tools to use to fix issues once you understand what is happening.
- rudedogg 4y ago
  There are a lot of foot guns, like ObservableObject and @Published causing views that reference the object (even if they don't use it in any way) to be re-rendered that cause issues. And even Apple can't figure it out, which can be seen from the Ventura System Settings performance. SwiftUI is nice for small apps and demos. But as soon as you add persistence, or try and do anything advanced the complexity balloons and you need to understand it completely. I think SwiftUI is just a bad abstraction with a lot of accidental complexity. It makes drawing much easier/faster for developers but all the state management stuff has become very difficult.
  - fingerlocks 4y ago
    Apple can figure it out- they implemented @Published such that it contains a reference to it's enclosing ObservableObject which invokes objectWillChange() very liberally. The fact that they wrote their settings UI poorly is a statement about the developer's assigned to build those components and/or the lack of QA involved. I do agree that ObservableObject/@Published should have been designed to prevent unnecessary re-renders. It's actually quite easy, and I expect Apple will include this in the future: Add an extension to @Published when the value type is Equatable and only send objectWillChange() when newValue != oldValue. I do something like this in my apps to eliminate superfluous re-renders, but the implementation is non-trivial due to an undocumented feature in Swift [0]. [0] https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type https://github.com/apple/swift-evolution/blob/main/proposals...
- pixelrevision 4y ago
  I really wish apple would spend more time on their tooling. A lot of the new features like async/await and SwiftUI have way less visibility than what came before. A lot of this stuff makes the code compact and much easier to read but when things go south trying to use the inspectors they have often doesn’t get you very far.

com2kid 4y ago

React is terrible at reactive[1] UIs. You have to do a lot of work to tell react what to not rerender. Of course things generally work if programmers aren't careful, but the UI gets slower and slower over time as more features are added and more repaints are done. VDom is one of those arguable things, plenty of frameworks are faster than React w/o a vdom, and some frameworks are faster than React and also use a VDom. [1] Arguably react is not even that reactive, you have to manually wire up everything yourself.

MH15 4y ago

You have this backwards no? The virtual DOM is needed in order to support Reactive UI, in most cases (svelte comes to mind as an exception).

mariodiana 4y ago
I think you're right, now that I think about it again.

georgelyon 4y ago

For the record, you do have fairly fine grained control over what updates when with SwiftUI. The issue is that this isn’t obvious to new developers, nor is it easy to understand what tools to use to fix issues once you understand what is happening.

rudedogg 4y ago
There are a lot of foot guns, like ObservableObject and @Published causing views that reference the object (even if they don't use it in any way) to be re-rendered that cause issues. And even Apple can't figure it out, which can be seen from the Ventura System Settings performance. SwiftUI is nice for small apps and demos. But as soon as you add persistence, or try and do anything advanced the complexity balloons and you need to understand it completely. I think SwiftUI is just a bad abstraction with a lot of accidental complexity. It makes drawing much easier/faster for developers but all the state management stuff has become very difficult.
- fingerlocks 4y ago
  Apple can figure it out- they implemented @Published such that it contains a reference to it's enclosing ObservableObject which invokes objectWillChange() very liberally. The fact that they wrote their settings UI poorly is a statement about the developer's assigned to build those components and/or the lack of QA involved. I do agree that ObservableObject/@Published should have been designed to prevent unnecessary re-renders. It's actually quite easy, and I expect Apple will include this in the future: Add an extension to @Published when the value type is Equatable and only send objectWillChange() when newValue != oldValue. I do something like this in my apps to eliminate superfluous re-renders, but the implementation is non-trivial due to an undocumented feature in Swift [0]. [0] https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type https://github.com/apple/swift-evolution/blob/main/proposals...
pixelrevision 4y ago
I really wish apple would spend more time on their tooling. A lot of the new features like async/await and SwiftUI have way less visibility than what came before. A lot of this stuff makes the code compact and much easier to read but when things go south trying to use the inspectors they have often doesn’t get you very far.