[cuddlecake]

Not sure if OO really rules the GUI space. Afaik, at least Swift, Dart (Flutter) and Kotlin are trying to solve the mismatch between OO and Reactive Programming (where functional approaches very helpful)

Most of GUI development is pure data handling (render state and react to interactions) where a strong functional toolset is much appreciated (lambda, pattern matching) and some parts are well done with closures (where OO comes in)

Ultimately I would love to have a GUI development language that allows me to use one set of language features and constraints when I really just want to use functions on data immutable data, strong pattern matching and ADT for modelling) and another when I need strong closures, with message based dispatches and reactivity.

Basically, whatever React does, minus the constraints of requiring JS compatibility.

[blacktriangle]

I'd say OO still does rule the GUI space. The various reactive programming GUI tools are still struggling to reach the levels of complexity of UIs that were already common place in the 90s. Functional GUIs have their own problems with giant balls of state that makes composition difficult. So we break it down into smaller bits and it starts to look like objects again.

IMO the functional GUI push has less to do with functional GUIs being superior and more about dealing with the piece of shit that is the DOM. Native environments that don't have to deal with the DOM don't get the same benefit and have new problems that are solved by more OO approaches.

[gokr]

It all depends if you consider basically all non web GUIs developed the last 40 years or if you limit yourself to reactive web UIs developed the last few years. Tongue in cheek :)

Sure, reactive frameworks in js that mainly operate on the DOM/HTML/CSS stack may be very little OO, but Swift/Dart/Kotlin are OOP languages and Flutter for example, while using a reactive model, is still 100% OOP with Widget classes in a composition and so on.

[geokon]

Well non-web GUIs have been basically stagnant for a good chunk of that 40 years :)

You're right that it's OO under the hood. The latest thing I've used is CLJFX which is a React-like wrapper around JavaFX. I don't feel the OO side has much effect on my experience using the library. It's still events, callbacks, state-updates. The class hierarchies are irrelevant to the library user the vast majority of the time.

I wouldn't be surprised if for the library writers it provides benefits with code reuse and type gymnastics. But for mere mortals that need to refactor and reorganize our messy ideas OO hierarchies seem scary after React-like development.

[francisl]

Not sure if you are sarcastic or not. But if you look at how you develop windows app (vb, winforms, wpf, uwp and now maui) or Mac/iOS (from mvc, mvvm, and now mvu) and not forgetting Delphi. I find it far from stagnant.

With React you just switch your complexity. I don't feel more productive with my functional components than with my class component. I even more scared to introduce a memory leak with my useEffect than I was before.

But I do feel more productive with svelte or Blazor. That make me realize that OO vs FP is the the real vector. Reactive programming with good design is.

[francisl]

Like you said reactive programming and OO are not exclusive.

And if you look how you do React now with useState, useEffect and all. It's exactly a reproduction of OO, but inside a function that don't behave like a function anymore. And goes HOC for the inheritance/mixins/composition you flush down the drain.

[infinite8s]

Well the DOM is basically an OO model. If you are going to have a retained mode UI it's basically going to look like an OO model.

[bionhoward]

try yew https://yew.rs/docs/en/

[cies]

and Elm https://elm-lang.org/