I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs).

React works well, because it's only an abstraction over the real DOM. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS.

▲

torginus 6 minutes ago | parent | next [-]

Imo the biggest issue with this functional model (at least in React), is that it handles things like virtualization, async, etc. poorly. Which is kinda ironic, because in a true functional language, it'd be feasible to provide 'a world model' - that is act as if the entire state is always available, and let the engine decide when to evaluate pieces of code - without any effort from the part of the programmer.

▲

mpweiher 22 minutes ago | parent | prev | next [-]

Not just does the computer not do functional.

UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch.

Further reading:

Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty.

https://link.springer.com/chapter/10.1007/978-3-540-92698-6_...

Can Programmers Escape the Gentle Tyranny of call/return?

https://2020.programming-conference.org/details/salon-2020-p...

UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status

https://2024.splashcon.org/details/splash-2024-Onward-papers...

	▲	cloogshicer 3 minutes ago \| parent [-]
		Thanks for those links! Some of it was great reading. What is your thesis then? What is UI?

▲

dgellow 40 minutes ago | parent | prev | next [-]

Hmm, but React doesn’t own or manage the app state. And react native has been used for pretty complex applications

▲

poly2it an hour ago | parent | prev [-]

Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai:

https://github.com/janestreet/bonsai

▲

rudedogg 36 minutes ago | parent | next [-]

> functional programming is superior for representing state in user interfaces

It's always going to be slower than using something imperative. Trying to process the entire world's state for the sake of purity can feel elegant but it isn't free. And the complexity that gets added to make things performant is worse than just accepting that UIs are going to require you to jump around the tree and modify state.

Every time I go through the trouble of understanding the latest web technique (React, Elm, Signals (the newest solution), etc.) to deal with state management and the DOM, I end up walking away disappointed. There's nothing new in them that you can use to improve what we've been doing for ages in native GUI toolkits.

And to jump back to the original topic, yes, Cocoa was pretty decent, and SwiftUI while nice in many ways tries to Reactify native macOS development and made it worse. And it made Swift incredibly more complex and worse in hindsight.

	▲	kodebach 18 minutes ago \| parent [-]
		The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly. With imperative UI code it is incredibly easy to forget an edge case in your update logic.

▲

mpweiher 44 minutes ago | parent | prev | next [-]

Not sure how you define "success" here. Is Bonsai used much outside of Jane Street?

▲

skydhash 42 minutes ago | parent | prev [-]

> Functional doesn't mean stateless.

I didn't say that.

User interfaces representation are mostly trees. And with functional programming you basically have Tree2 = f(Tree1). Until f is done you can't do anything really. React has a lot of escape hatches to improve performance, but they are escape hatches, not an endorsement of the architecture.

With imperative programming (and OOP), you only have that single `Tree`, which you update at will. Less elegant yes, but we have modularization to help us there. What Emacs does is to keep that `Tree` as a single mutable object, but have the code be functional, while the results are imperative.