This is a very common misconception. React was meant to provide one-way data flow. With an app built directly on the DOM you have to deal with the DOM having its own state to manage on top of the state your own code is storing. You have a list of comments in a variable, and a list of DOM elements for each comment, and nothing but your own code is making sure they stay in sync with each other. React changed things so that the state of the DOM is always derived from your own app's state, which eliminates what turned out to be a pretty tedious and error-prone amount of work in complex web apps.

It wasn't the first to provide this but its API was unique and compelling vs existing alternatives. The virtual DOM, server-side rendering, etc. are not things that make React faster than non-React code, they are things that counteract the inherent slowness in React's design to make it competitive with non-React code.

Watch the original JSConf talk where React was publicly announced and released, and notice how the talk is mostly about the one-way data binding, and the virtual DOM/reconciliation are mentioned in the back half as ways React catches up to non-React app speeds: https://www.youtube.com/watch?v=GW0rj4sNH2w

This has been the trend largely for last 3 to 4 years with the candidates (<5 yoe) I have interviewed. I probe them on core fundamentals of Javascript, HTML and CSS. When I get to the nuances, most of them outright call it out saying that they are React developers and do not do Javascript without realizing the fact that React is based on Javascript. And other common misconception is that they assume JSX works the same way while writing the vanilla Javascript code.

React does a fantastic job working with common developer principles such as Don't Repeat Yourself, and Single Source of Truth.

Their points come across as overly vague and lack any true insights into development besides initial impressions.

For a static page it doesn't make sense to use React, obviously. For a highly interactive page it, or another framework is critical to clean, manageable code.

State management in React is a major source of pain and complexity and if you build you application using events then you can eliminate state entirely.

Most state management in react is used to fill out props and get the application to behave in a certain way - don't do it - too hard, drop all that.

Here is how to control your React application and make it simple and get rid of all state except useState:

    const ImageComponent = () => {
      const [cacheBust, setCacheBust] = useState(0);

      useEffect(() => {
        const eventListener = () => setCacheBust(Date.now());
        window.addEventListener('customEvent', eventListener);
        return () => window.removeEventListener('customEvent', eventListener);
      }, []);

      return (
        <div>
          <h2>Profile Image</h2>
          <img
            src={`https://example.com/profile-image.jpg?cachebust=${cacheBust}`} // Image URL with cacheBust as query param
            alt="Profile"
            style={{ maxWidth: '200px' }}
          />
        </div>
      );
    };

    // Component that dispatches custom event
    const DispatcherComponent = () => {
      const dispatchCustomEvent = () => window.dispatchEvent(new CustomEvent('customEvent'));

      return (
        <div>
          <h2>Dispatcher Component</h2>
          <button onClick={dispatchCustomEvent}>Reload Image</button>
        </div>
      );
    };

It is not difficult or complex at all to use pure functions and seven hooks. They are documented exceptionally well.

All the complexity author is complaining about he created himself. You can keep the browser router if you want, it can be synced with reactive state using a single side-effect and a single reducer, you don't need to replace it with react-router. You don't need to use Next.js. You don't need SSR or graphql. You can use just regular CSS if you want. This is not complexity that "comes with React", React comes with nothing like that. This is complexity you are stuffing into it.

Young dev: it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use.

Time passes, framework becomes popular blogs write about how framework X is the future. If you don't have 10 years in framework X you can't get a job. People start using it for things features get added to accommodate needs. People argue saying it's necessary it fits the demand. Framework X becomes a gigantic bloated monstrosity, development slows as useless bureaucratic leeches posing as developers create a "foundation" to "shepherd Framework X towards a bright future." At this point usually the creator leaves or is driven out.

A young developer comes along and says to himself "it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use."

The Wheel of Development turns, and frameworks come and pass, leaving defaults that become best practices. Best practices fades to srandards, and even standards is long forgotten when the problem that gave it birth comes again.”

I have been thinking for a while about specialising in teaching how the web came to be, so people who are non-technical can understand enough to commission work, understand proposals, etc.; because I think people have no sense of what goes on under the hood.

But increasingly I think it's junior developers and web-oriented designers who need to be taught it.

(Also the developers of Hacker News: "flag" should be idempotent, surely, and not a GET request?)