why react is flawed

gistfile1.md

1. application state is passed down to subcomponents

   On the surface this seems quite natural, but in practice things get strange quickly. The issue is that components get their data from two places (sometimes three): from this.props and from this.state (and this.context). What often happens is that you want to store some information, such as some form input data or an AJAX call in this.state, but meanwhile, the parent has passed in some new props in this.props that invalidate that state, or at least make it inconsistent. So you have to merge the new this.props with the this.state in componentWillReceiveProps().

   Secondly, and this is related to the first, it's impossible for a parent component to get at the state of a child component. Also, a plausibly good idea - keep things isolated from each other. But again in practice, this forces weird design decitions: the parent passes an object to the child (in props) that is then modified by the child (form input, etc). This isn't a major issue, but then you start asking yourself why even bother with this.state. But this.state is kind of integral to the React experience. At least one component needs to store this.state! One of the most laughable ideas that has come out of the React world is Flux, which is essentially trying to solve the problem of having several otherwise isolated components share some common data - which Flux calls the store. Throw in some gaudy messaging/event/queuing system and you have a monster on your hands.

   Better, I think, to have one model for all application state. Allow subcomponents to share parts of that model and update it. Then re-render everything when that model changes. VDom will do it's magic and only update the parts of the DOM that actually changed.

2. Routing

   This isn't really React's fault, but react-router. This is essentially the same problem above, but just emphasises it. Now we have this.state, this.props, this.context and for routing, this.context.router.getCurrentParams(). Now the state that drives your app, and all you components, is spread across several different (and not necessarily consistent) data sources. I do not like working in an environment like this!

3. APIs

   • React 0.11: r.div({}) and var MyElement = React.createClass({...}); MyElement({}, 'Some Content...')
   • React 0.12: r('div', {}) and var MyElement = React.createFactory(React.createClass({...})); MyElement({}, 'Some Content...')
   • React 0.13: r('div', {}) and var MyElement = React.createClass({...})); r(MyElement, {}, 'Some Content...')

   Not a biggie, but I have deadlines!

4. Just to get this stuff of my chest I've been building and using plastiq, which embodies the vdom concept, but makes it much simpler to get stuff done. Don't get me wrong, I'm not bitching about React so I can some attention on plastiq, I wrote plastiq because I don't like working with React (or Angular). I can't compete with facebook, but I can make my worklife better.

5. Fortunately for most people Angular is their only choice. Stick with it. Angular is fairly productive, even if you can spend hours staring at errors with the word $digest in them. It's pretty complicated and it will definitely own you, which is why React seems like a refreshing change.

6. You should become a landscape gardner instead. It'll work out better for you.

I already had a complaint about there being both props and state, context just adds more confusion on top of this.

A plain old top down rendering engine on top of a vdom is all we should be using - React is about to jump the shark big time.

But it was a good start.

"Better, I think, to have one model for all application state. Allow subcomponents to share parts of that model and update it. Then re-render everything when that model changes. VDom will do it's magic and only update the parts of the DOM that actually changed."

Yep.

@robashton You've said this before (somewhere?) but JavaScript is definitely going Java. Angular 2.0 is going a nuts with features, and by all accounts seems to be being driven as a large scale enterprise engineering project. I have no idea how they'll ship that thing under 100k of JS. They'll probably require HTTP 2.0 or someshit.

React jumped the shark with Flux already. React.createFactory lol.
Interesting that their new "Components" thing for iOS seems to follow the one-model concept instead of React's model-per-component approach.

@refractalize Yup - I said that about Angular and such; goddamn annoying.

I suspect I'll be changing to another vdom thing sooner or later, I like JSX though (I'm alone there I know)

It's looking like a regular dispute Angular vs React, but I will try to answer...
@refractalize Currently we have no choice to build server-rendered SPA's 😄

I will answer for each item in your list.

1. Components are getting data via 4 sources: props, state, context and ... flux (aka global state)! If you are messing with which one to choose for your data, you probably don't understand about that. There are many articles [in internets] about difference between state and props. I should note here that I didn't use context's, because I didn't faced any case for it. BTW this feature will be deprecated, right?
2. Personally, I not like react-router so much, but .... how to display route handler using director? What if parent route handler has child route handler? Handling multiple React roots it's kinda pain...
3. I too 😃. But why you should rewrite entire project for fresh version? I've started on 0.11 version and now 0.12.
4. Yeah. 120kb for VDOM lib is too much. But we've got nice framework for handling independent modules.
5. Did you faced 2000 scope watcher limit already?
6. ???