I think Redux community entered the "cargo cult" stage (need for Redux itself, but also code artifacts like action constants, action creators or switch/case statements i.e. things that Redux does NOT require, but people put them in the code just because everyone else does that. It's tradition, not a pragmatism). So the biggest problem with Redux is not technical but psychological (i.e. most of programmers are believers rather than thinkers).
And there is a lot of Stockholm syndrome in Redux community - which stops innovation because people get used to Redux and don't want to try other approaches (even abstractions don't really abstract much. Most of Redux abstractions I see operate on the similar abstraction level (I.e. actions, reducers etc. They just move things around in other places they were originally. I think good Redux abstraction should abstract Redux concepts itself (even reducers, or immutability)
But honestly I don't see any future of Redux (BTW it's very good proof of concept! I'm glad Dan Abramov made this. It has good fundamentals and it allowed for inspiration for other libraries). Nevertheless I think using Redux in more complex apps than ToDo List is just cumbersome and I think this library will fade out of fashion in 2018 (and there will be huge amount of legacy code to maintain).
@antanas-arvasevicius if history can help, so far, not a single UI framework stood the test of time, not even close. I am sure it's easy to think, "but this time is different" or "we tried so many times, that one day we'll just get tired and we'll pick the last one standing"
For me that's why I prefer "raw" ES6/HTML5/CSS3. A language doesn't "break" easily. All the code that you have written generally continues to run, years after it was written, and if not, the adjustments are minor, when did someone rewrote an app after a language/SDK update?
@hex13 the biggest issue I have with React or React + Redux or Redux alone is the lack of consideration for API calls. I'd say the programming model goes in the right direction but they missed that turn and seem to not care about it. As I wrote in my "no MVC" paper, front-end developers call the shots when it comes to defining the shapes of APIs, but that's truly a curse. This is how products fall apart, one API at a time until the weight of the front-end can no longer be supported.
I mentioned it in a discussion a few days earlier:
so when you need to make an API call you need to do is outside the redux/render loop
That was true too in the early days of React where it was virtually impossible to weave API calls in React components. Then Flux came and tried to address that, then React came and drove the entire community back towards front-end with cool dev tools like "time travel"
It takes about 2-3 years to develop the symptoms of a poor API architecture, after that it is too late, in general you need to abandon your project/product because the cost of maintaining it is too high.
Facebook saw that problem coming, so they created GraphQL, but GraphQL can't work with for create/update/delete. The very problem of "Front-End" driven API design is that Front-End concerns are orthogonal to Systems of Record and Consistency.
Other than that, I truly think it's a shame because React had made a big leap forward and they took it all away.
On a completely different topic, I found this article really interesting in the context of STAR: "JOIN Elimination: An Essential Optimiser Feature for Advanced SQL Usage"
Ultimately, it's really key to clearly layout your programming model, regardless of the framework or language, otherwise, you are pretty much using snake oil, even if the people who are making/selling it don't even understand that's just snake oil.
I've seen many project which uses raw js/html/css and they were unmaintainable, because every UI component was written from scrach and used inconsistently e.g. List grids copy pasted to different pages and changed, drop downs was also patched, e. g. Drop down with multi columns
and what do you think about dependency injection for injecting API? i.e. creating services like in AngularJS and inject them to the functions. This approach could allow for mocking or virtualize APIs (to remove side effects).