I both agree and disagree. If you code yourself into a corner with React it can be harder to understand and untangle: it's much easier to understand jQuery under the covers than React, especially if you're using other parts of the React ecosystem.

None of this is related to what I said originally, which is that jQuery doesn't encourage shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it.

> [Good code in jQ] requires planning and architecture engineering.

Precisely what I said.

(That said, if you don't do that with React, you'll still end up with a mess.)

I agree and disagree as well.

My point about planning and architecture was to contrast it against what I believe React is better at.

Personally I think React is easier to understand. Honestly the vDom is an implementation detail people get stuck on. Pure functions, well defined state owneeship and transition, and so on are the real benefits.

The other main criticism is JSX which is totally optional and mixing implementing with presentation; the "correct" which I believe to be a outdated but still accepted belief that went out of style around Web 2.0. This separation is not required either, you can rewrite render() to pull from any templating engine or whatever. Or use HOF/HOC via the presentation/containener design pattern.

I realize I went off topic but I've been wanting to compiler my thoughts on this.

React is better at enabling planning and architecture; that's part of its job. That was explicitly not part of jQuery's job. jQuery was a tool to be used as part of a larger strategy. Lots of people chose to ignore that part of their code, and paid the price.

I like JSX quite a bit as well; IMO creating an artificial separation between presentation and behavior is not a useful way to think about web apps.

Separating data from presentation and behavior is fine, and is a long-standing GUI tradition.

I think we're really in agreement about everything. The tools have intended jobs; some people use them incorrectly or without regard to best-practices. Both have different strengths and failure modes.

I would say JSX and the separation of presentation / behavior is orthogonal.

JSX is just a Javascript powered embedded SGML-like document.

The combining of presentation and behavior is caused by render() being defined inline with implementation.

You can not use JSX by using ReactDOM directly or a templating library while still keeping render() inlined.

Or you can move render() to another class (or subclassed, or HOC, whatever) and separate the presentation and behavior with or without JSX.