I think there are a lot of specious comparisons. In Cocoa, all parts of the UI can theoretically participate in the app and be wired in the same way. In the web, you don't get your own text field, etc, so you will have to make do with what's there. Thus there will be parts that have to be handled differently.
I think Marcel brings up a valid point about composition, if I understood it correctly. The composition of interfaces in Dolphin Smalltalk, for example, is super easy with the MVP paradigm. You can build and test a particular feature and immediately drop it into another, larger composite presenter. You just make its model a field on its owner. Other properties can be connected to where they need to be during the initialization of the component.
I'm not sure if wiring up react components is as easy, because you have to think about stuff that is not directly in your data flow. But I honestly don't have enough experience to say. I have more experience with Elm and found it a little less easy.
At that point, the big difference between MVx and reactive is the bidirectional data flow in MVx. Parts need to be bound so that they update the real world, and updates need to be observable so the UI can change. Reactive UI coordinates a filtration of that state through the view painting.
In Elm (old Elm, not sure what it's like now) when you embed a component your top level needs to understand its messages to pass them down/up appropriately. The type system helps you not forget things, but there was a good bit of retyping.
That, and the way that html bits fit into other bits breaks the abstraction. Perhaps using a reactive approach to run Web Components is the best way to get the same sort of composability currently, I haven't tried it.
I think Marcel brings up a valid point about composition, if I understood it correctly. The composition of interfaces in Dolphin Smalltalk, for example, is super easy with the MVP paradigm. You can build and test a particular feature and immediately drop it into another, larger composite presenter. You just make its model a field on its owner. Other properties can be connected to where they need to be during the initialization of the component.
I'm not sure if wiring up react components is as easy, because you have to think about stuff that is not directly in your data flow. But I honestly don't have enough experience to say. I have more experience with Elm and found it a little less easy.
At that point, the big difference between MVx and reactive is the bidirectional data flow in MVx. Parts need to be bound so that they update the real world, and updates need to be observable so the UI can change. Reactive UI coordinates a filtration of that state through the view painting.
In Elm (old Elm, not sure what it's like now) when you embed a component your top level needs to understand its messages to pass them down/up appropriately. The type system helps you not forget things, but there was a good bit of retyping.
That, and the way that html bits fit into other bits breaks the abstraction. Perhaps using a reactive approach to run Web Components is the best way to get the same sort of composability currently, I haven't tried it.