Is Flux/Redux "better than" MVVM?

[Petikoch]

I came to the insight, that the Flux/Redux Pattern is "better than" MVVM.

The main point is a better understanding/debugging of the flow of events.

In MVVM we have typically databinding, sometimes bidirectional, sometimes on different threads. At runtime the events in the application are like a gunfight with bullets flying from/to all kinds of directions.

In Flux/Redux, we have in contrast the unidirectional dataflow, which makes it easy to understand/debug the system. This is more like a shooting range. The bullets fly from A to B.

In my day job I switched over from MVVM to Redux and think it "is better". Unfortunately I didn't have time to share some code.

[Petikoch]

Java_MVVM_with_Swing_and_RxJava_Examples is therefore likely "deprecated"

[akardapolov]

In my day job I switched over from MVVM to Redux and think it "is better". Unfortunately I didn't have time to share some code.

It will be interesting! I try to choose the right way to write swing gui.
Now I found that MVVM is deprecated. Time changes all things :)

[manuel-mauky]

Hi Peti,
in general I think redux is the better approach compared to mvvm. However, it depends on the plattform and programming language. For Java as programming language and JavaFX as UI-Toolkit I would still use MVVM because in my oppinion Java as a language isn't really suited for functional programming like you do with redux. There are interesting approaches to Redux with Java but I'm not convinced yet.

Do you use Redux with Swing in your day job or with JavaScript/React?

[Petikoch]

Hi Manuel,

nice hearing from you! :-)

You are absolutely right IMHO that vanilla Java is not ideal to implement Redux for the JVM. The main reason for this is the lack of immutable/persistent datastructures to implemented the "immutable state".

However, with a little bit of "salt" like https://immutables.github.io/ or the usage of "alternative" JVM languages like Groovy with it's @immutable annotation or even "better" Kotlin, Scala, ... this is easy to overcome.

Combined with a nice reactive programming library like RxJava (targeting Java 6 and Android), Reactor (targeting Java 8), akka-stream, or ... the implementation of Redux for the JVM becomes quite a good fit.

At the moment we use our closed source inhouse Redux port for our Vaadin and Swing based applications.

Best regards,
Peti

PS: Meanwhile there are a few opensource redux ports for the JVM out there, but they are all IMHO in a early stage and/or bound to a specific view-technology (e.g. "only for JavaFX")

[manuel-mauky]

You are right. I also like Kotlin for this.

I know reduxfx which I find really interesting but lacking some features like FXML support yet.
And I've also written a Flux library for JavaFX by myself but this is also only a prove-of-concept.

A production-ready java redux library that is independend of UI toolkits would be nice.