You should also check out Mithril: https://www.npmjs.com/package/mithril
The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)
I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook pushed singletons and then everyone followed their lead.
I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.
Not everyone is ready to go into FP-land right now.
React lets you take these decisions yourself.
Whether local state is practical for your team or not.
You must be living in a very different world than mine if you think that compared to its rivals (Angular, Ember, etc), React is somehow “encouraging” local state. Sure you could go more functional than that, but take a look at the mainstream frameworks and you'll see it's such a long way to go, that had React not allowed local state, it would not have gotten adoption at all.
All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".
React is receiving 100% of the attention in this space when imo it should be receiving about 75%.
I long for time when these concepts are boring enough no one thinks of React anymore. Sadly we're not there yet.
Its true innovation is its declarative component model.
You are missing the point of React.
https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.
React's innovation is using virtual DOM to make declarative components usable without delving into FRP.
Not just that. I may be stupid but personally I find it mentally simpler to `setState` than to `flatMapLatest`. To each their own I suppose.
>React's innovation is using virtual DOM to make declarative components usable without delving into FRP.
Precisely.
>The "declarative component model" is not an innovation, it's an obvious approach [..] can achieve the same [..] by [..] obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same
React is not an academic paper, it's a tool. It doesn't need to have new ideas, it needs to execute on them in a practical way. Which it does.
Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to reason about where any data comes from, and how UI will change over time.
Read this:
http://jlongster.com/Removing-User-Interface-Complexity,-or-...
So we agree, you're just separating the concept from the implementation and I'm talking about them as one.
In React, components are not just functions that return their own virtual DOM. AFAIK for many vdom-based libraries this statement wouldn't be true.
React components may have local state (as much as some people hate it, some find it useful), they have a lifecycle, can react to receiving new props with side effects, can implement diff bail-out hook. And you can nest such components declaratively.
And declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React. The advantage feature I would credit React for is the size of its community and influential advocates like you.
Declarative nesting of lifecycle-ful and stateful components without going full FRP.
I'm actually excited to learn about other frameworks that do this! Which do you have in mind?
If you are interested in academics, I published such a system at ECOOP in 2006:
http://research.microsoft.com/pubs/179366/mcdirmid06superglu...
It really has nothing to do with React's approach, at all.
[1]: https://github.com/muut/riotjs/blob/master/lib/view.js#L75