[mistahenry]

It’s exactly what I find so great about Ember (beyond just preferring a true templating language for front ends)

React bringing the “same way of thinking” in the front end industry may be true now, but it definitely was not the case for many years. I saw three or four react projects and they were architected very differently, with different routing, different state patterns, different approaches to updating backend state, different build systems, etc.

[chrisweekly]

That's because React is a UI library, not a monolithic batteries-included framework. Amazing to me how often this is misunderstood. React's relatively narrow focus is one of its strengths.

[KurtMueller]

I think this is also a weakness as mentioned in the previous comment. React is dead simple and has a limited scope... but now what happens when I went to pull in external data, use react as a router, or manage complex data? Well, now authors have to decide which libraries to use in conjunction React, which can vary wildly from project to project. This is something that Rails and Ember has tried to avoid.

[chrisweekly]

Agreed; of course there are tradeoffs! "What happens.." is that you can use Mobx instead of redux bc it's easier to reason about. You can have some preferred way of doing things, and let React be a component-level implementation detail. Pros and cons abound in choosing a bells-and-whistles, batteries-included framework vs taking on the overhead -- and upside -- of composing a set of preferred libraries or tools. I never said "React is always a better choice than X." I said "it's not apples:apples to compare them directly". For which I got downvoted? sigh

[KurtMueller]

I didn't downvote you! I still don't have that ability yet ;).

[chrisweekly]

No worries! I didn't mean to imply you'd downvoted me. :)

meta: I won't mind _this_ comment being downvoted since we're so far afield from the OP, but it's worth it to me to clarify intent in responding to a friendly peer.