Hacker News Reader

Comment by mariodiana | Hacker News Reader

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.

View on HN

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.

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

I think you're right, now that I think about it again.

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.

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.

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

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.

Reply on news.ycombinator.com