This is why React won: No template language to learn. No prescriptions for managing your app. No piles of abstractions to do basic things. It's just a UI lib. Import it, declare what to paint on-screen, done.

Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these commonplace features together? Use Create React App, or Next.js, or whatever fits your use case.

That's why I love React. The complexity of the solution matches the complexity of the problem.

Hello world:

    const App = () => <div>Hello world!</div>
    root.render(<App />);

Basic reactivity (output click event to console):

    const App = () => <button onClick={console.log}></button>

Composition & enumeration (dynamic bullet list!):

    const OneTwoThree = () => [1, 2, 3].map(i => <li>{i}</li>)

    const App = () => (
      <ul>
        <OneTwoThree />
      </ul>
    )

Set UI output data and CSS style based on asynchronous query results:

    const App = () => {
      const [isGoogleUp, setIsGoogleUp] = useState(true);

      const checkGoogleStatus = () =>
        fetch('http://google.com')
          .then((response) => setIsGoogleUp(response.ok))
          .catch((err) => setIsgoogleUp(false));

      useEffect(() => {
        checkGoogleStatus();
      }, []);

      return isGoogleUp 
        ? (<span style={{ color: 'green' }}>Google is up!</span>)
        : (<span style={{ color: 'red' }}>Can't reach Google.</span>);
    };

I can't imagine things being much simpler than this. No extra CSS files. No `Controller` classes. No janky, bespoke HTML "attributes" to make array loops or conditionals work. Just pure JavaScript (JSX optional) painting what you declare. That's my jam. I can't endure the agony of learning another damn template language or SomeCompany's (leaky) abstractions.

It's also part of its hate - it's been wrangled into a hot mess with routing, data fetching, state management and inability to play nice with html elements (specifically forms; controlled vs uncontrolled components). Not to mention "pure" functions vs classes, hooks, context, render lifecycles leading to the development & usage of useMemo() etc etc.

Don't get me wrong, in its purest & simplest form it is great. Unfortunately it's very rare you get to leave it like that because we now make web _applications_ instead of static websites.

Most of the time you're actually better off just using html5 with css3 - it's very rare that you truly need something that is "reactive".

> Oh, you want routing? "Not my business", says React. Go add a routing library

Great, now I have to sort through hundreds of different routing libraries and dozens of different build systems, and then do it all again when I need a state library. This is why people hate React.

Most often you don't have to go through so many. The community usually has some preferred selection of tools and you have to choose from 2-5 different options. You still need to do some research but it is not as bad as you present it. The advantage of this is that better tools may replace worse tools and totally different approaches can be tested whereas you have to hope in a framework that the initially chosen strategy can be improved enough.

Yep, Ideally it would have one, but be optional.

Counterpoint: While $MYFIRM is a React + Django shop and that's absolutely the right decision due to ecosystem factors, I do wish Ember had won the frontend ecosystem race.

Having worked in an Ember shop before, having everything just work and not be constantly updating dependencies and managing around cross dependency hell and endless package underwriting was very nice. Not to mention that to this day, I still haven't found a good React equivalent for Ember data, and I miss not only how productive my org was with Ember and how nicely our codebase scaled over time with sane conventions that we didn't have to invent the hard way by trial and error.

I would say very nearly the same thing about Django in that if it used SQLAlchemy and HTMX/etc for Django Admin, it would be nearly perfect. Even so, Django is a framework that has never let me down in production and it's always irked me when I've had to build something in Flask-land or FastAPI-land that just worked out of the box in Django, or was a well maintained package in the Django ecosystem.

> Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these commonplace features together? Use Create React App, or Next.js, or whatever fits your use case.

Double edge sword in my opinion.

Every single react Project I jump into is completely different and a pain in the ass half the time to figure out what is where and what is doing what.

On the other hand I can jump into just about any Rails project and hit the ground running.

I find implementing certain common things in react to be a pain, such as state management and route guards.

Vue is similarly unopinionated, but it is more intuitive to my particular brain.

> I can't imagine things being much simpler than this

Imagine simplifying the last example without useState and setState, nor useEffet and depList

That's why angular is hated so much. It makes easy things more complicate. In my opinion it's a bad framework. Use a good framework instead! Just because some (or a lot of) frameworks are bad, it doesn't meant that the concept of a framework is bad.

Same experience with Angular; idk what they were thinking. Just a button is like 10X harder than vanilla JS. React showed that you can accomplish the same thing with a lot less repetition, which is odd because there's supposedly less going on under the hood than with Angular.