I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a <form> element to send the credentials, and maybe a little JS for the password show/hide button. But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more.

Other frameworks, like Vue and Alpine, let you use them "progressively" and you can even do so with a CDN to avoid having to set up npm/vite from the get go. Their intro docs have instructions for how to do so, along with the relevant caveats

React claims to be progressive, but since it's JSX it requires a compile step. Its intro docs do not have instructions for using it via CDN. You can make it work if you really want to, but it basically requires shipping the compiler to the client along with the JSX and doing the compilation client-side, which obviously scales so poorly that their docs don't cover it.

To recap, my whole point is that React scales very poorly down to simple sites. And since most site are not Facebook or the Spotify web player or Netflix (and even Netflix is moving away from React: https://x.com/NetflixUIE/status/923374215041912833), I think it's very hard to argue that React is effective or well designed.

>I think it's very hard to argue that React is effective or well designed.

This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history.

>(and even Netflix is moving away from React

They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeabl...

You don't need the compiler client side. What level of confusion leads you to believe that? That's not even a detail about React, that's simply a mistake in how software works.

React has ALWAYS, by default, done SSR first and then hydrates state on the client. It's trivial, and always has been, to simply do SSR only if you so wish.

>But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more.

I find it hard to take this characterization in good faith. If you have trouble learning about the component life cycle in React, I don't see how you have any hope of successfully building a production level application without any guard rails.

You will, without a singular doubt, simply get "it" wrong. Even with modern JS.

You certainly don't need JSX for React, nor a build chain. My ship investor Kelly trainer game[1] is a simple React application in a single HTML file. The initial page load is slow because I experimented with using built-in browser module support to pull in React, but if you change it to serve a pre-built library from a CDN instead then also the initial page load is fast.

You can view the source on that page to see how simple it can be, but here is the essence:

1. Import React. This is the step you can do from a CDN instead of you want a faster initial page load. (Okay apparently I'm using Preact here, but it's effectively the same thing.)

    import { h, render, createContext } from 'https://unpkg.com/preact@latest?module';
    import { useState, useMemo } from 'https://unpkg.com/preact@latest/hooks/dist/hooks.module.js?module';

    const appDiv = document.getElementById('app');
    render(h(App, null), appDiv);

    function App() {
        let [state, setState] = useState(initial_state);
        // --------------->8------
        return h('main', null, [
             h(Description, {
                 turn: state.turn,
                 strait: state.straits[state.shipment.strait]
             }),
             h(Bankroll, { wealth: state.wealth.first() }),
             h(Investment, { invest, state }),
             h(WealthHistory, { wealth: state.wealth }),
         ]);
    }

[1]: https://xkqr.org/ship-investor/ship-investor.html

(There is at least one bug in the game logic that prevents this game from being any fun at the moment. I have not taken the time to investigate why that happens, because I have not offered the training that used this tool to anyone in a few years.)

((If you enjoyed the game anyway and want more of a challenge, you might want to try the continuous version: https://xkqr.org/ship-investor/ship-investor-2.html. There is also a secret third version simulating futures which I have never shared with anyone before. It is playable, but not finished: https://xkqr.org/ship-investor/ship-investor-3.html))

You shouldn't use any js framework for simple sites.

Netflix didn't move away from react. They render landing pages with static react components through server-side rendering and only add the minimal interactivity on top through client side js to avoid shipping all of react's state management etc. to the client.

You can use React without jsx by the way. The syntax isn't great but it is doable.

I think you hit the nail on the head: React is a good fit for certain solutions (like interactivity rich web applications), while not a good fit for others (like adding minor interactivity into a form). There are trade offs to React vs Vue vs Angular vs Vanilla and which is best is contextual to the problem you are solving, rather than a more moralistic "X is THE winner" stance.

Innovation is not really measured in terms of how well something "scales down".

> only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites.

I agree completely, my whole career I've been building webapps, as in like software that really couldn't be server side rendered, such as very interactive charting and table applications or games (that didn't require Canvas and could work in DOM but needed lots of reactivity, such as a SQL query builder game or a terminal emulator game), where react works decently. Vue worked fine and so did backbone/marionette, whatever, a framework is a framework is a framework, React has a lot of libraries I can just chuck in to get a date picker or whatever so I use it.

Anyway, I would never build anything that can be server-rendered in react. Simple forms, e-commerce, blogs, portfolios, anything like that I'm just writing in HTML or Django or Hugo or hell, Wordpress. I tried out Astro for a blog just to pick up the framework and didn't understand why on earth I needed all this insane boilerplate to render Markdown files. Hugo solved that problem. If I need more complex than that, Vite + react, done.

I feel like there's a lot of devs out there that are using react cause they like the devx "nice to haves" that they're used to e.g. hooks or whatever, when they really don't need them for their page.

Look, just because you're the most popular doesn't mean you're the best, did you fools not learn anything from high school? Look at Microsoft in the 90s-2000s -- terrible fucking software, but it was by far the most widely used.