React has grown beyond its original promise and it's causing more harm than good

[Osmose]

> React was meant to be a way to provide snappy page loads and UX.

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

[coldtea]

>This is a very common misconception

Not really a misconception: it was explicitly pushed and advertised as such, most of the advocacy (especially from React fans) at the time React was introduced and started gaining traction was about the virtual DOM being "faster".

>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.

I dunno, I used Redux for a few years, and it was a "pretty tedious and error-prone amount of work in complex web apps" too.

[latchkey]

The one way data binding was also important at the time, for people coming from Angular. It was a way to clearly differentiate the two frameworks.

[bell_tower]

Unfortunately people do not find out what it was meant for, before they start writing about it

[songbird23]

I dont use react professionally(vanilla) but its ideas of one way data binding and UI is a function of state have continuously been helpful in building predictable apps that doesnt grow too hairy. an app can still grow in complexity as it becomes bigger but the ideas definitely help

[symaxian]

Yeah, I cannot count how many times I've seen it claimed that the virtual DOM is the secret to why React(or another framework) is fast, completely missing the point of the virtual DOM.

The virtual DOM is not faster than performing direct mutations of the actual DOM, the virtual DOM is a tool that allows the normally slow approach of "blow away and rebuild the world" to be fast enough to put into use.

[ethanbond]

This was super informative, thanks for writing it up!

[dudefeliciano]

don't hooks break the whole concept of one way data binding?

[Gigacore]

> React is the automatic target for a lot of newbies. They jump straight into webdev, learn some HTML/CSS and eventually work their way towards React for employability.

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.

[cqqxo4zV46cp]

Yup. I’m hiring for a mid-level FE role right now, and the number of “React developers” that don’t know JS fundamentals is incomprehensible. I’m not talking about anything esoteric. Just the sorts of things that I as someone that’s far from a JS expert considers necessary to work in that space day to day. I’m more and more just taking it as a given now that someone won’t have much if any experience writing CSS by hand. If they do, never in an actual .css file. Always via some CSS in JS something or other. A strange new world out there.

[bryanrasmussen]

about 23-24 years ago me and another senior developer were working on some important parts of the product we were building, and we had a minor task for a company that was paying a little bit, so we handed it over to a guy who was junior but should really have been better (he had the wrong kind of Laziness).

After some hours I saw him walking around with that programmers walk we get when trying to figure out a particularly hard problem. So I went over to check on him.

He informed me that his code to read in the XML file and transform it with the XSLT I had given him worked perfectly in IE but in Netscape there was some sort of problem with the ActiveX control he was using.

So - I figure assuming "JSX works the same way" is the modern day version of that.

[at-fates-hands]

Interesting story.

When all the frameworks were taking off, I was at a huge company using a 15 years legacy front-end. My background was "traditional" front-end. HTML/CSS/JS and mostly jQuery at the time.

Every time I went in for an interview, the senior devs would always start with fundamental JS stuff and then go from there. I would consistently get comments about how I was the first person they interviewed who could actually talk to basic JS stuff like closures and scope chain. They said there was a huge influx of people learning React and Angular and had no idea the difference between the two or like you said, they were based on JS.

This was back around 2014/2015 and it looks as though not much has changed since then.

[greenie_beans]

was at a bar and i met some guy who was like a year into his first software dev job and somebody was asking us about learning to code and i said to learn html/css first and he was like, "you don't need to know that, just learn react. i don't know anything about html."

i kept my judgement to myself and just ignored his advice. hopefully he's learned html.

[MattDaEskimo]

This sounds like the complaints from a new developer that's frustrated over the layers of web dev.

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.

[treve]

Maybe it's a bit vague or don't have 'true insight', but I would still encourage anyone sharing their feelings, even if they're not expert level insights. React applications turning into a maintenance nightmare and the meta changing under your feet is a common sentiment and I think it's helpful if more people talk about this.

One issue in the frontend space is that React has been the default no-questions-asked choice, but my personal vague, no-true-insight feelings are also that you need a technically very proficient team to avoid it turning into a maintenance nightmare.

Many people work for SMBs, and it feels like there's not a great golden path currently for frontend. Doing a something simpler somehow feels like a bigger risk to the people I chat with.

[danjac]

I have seen so many React code bases that are the polar opposite to "clean, manageable code" that I would strongly disagree with this premise.

That's not to say React is to blame, per se, but good code is the result of good developer practices rather than some framework.

[tauchunfall]

>For a static page it doesn't make sense to use React, obviously

JSX is a nice templating language. And when you use Deno or Bun you can use it directly on server-side. My server-side components have no hooks and use preact-render-to-string or `renderToString()` from `react-dom/server`.

Also there is Gatsby which is a popular content management system which also allow non-interactive statically rendered pages (as far as I remember).

[webprofusion]

True, but they're not a new developer, so maybe he's just saying what everyone thinks.

[mr_toad]

It actually is quite suitable for static pages where the content itself is quite dynamic (e.g. from a CMS or other database), especially when rendering repetitive data structures (e.g. lists of items). You use React on the server to render the contents on the fly as static html and serve that.

[vjerancrnjak]

A good question is "What is interactive?" Many "interactive" things can be done just with CSS and HTML.

* a list of elements you can select and delete/bulk-edit is feasible with <form>

* any kind of form with input

* hide/show toggle

* tabs

* accordions

Many single page apps aren't really interactive or require minimal JS.

Currently, we're doing things in JS (like forms, pages, tabs, virtualized lists & tree views, hovers, even buttons with JS click handlers) just because our server does not render HTML.

[greenie_beans]

lots of folks bash react without actually knowing how to use it.

[andrewstuart]

I love React but I use no state management, apart from useState locally within components.

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>
      );
    };

Trust me - once you switch to using custom events you can ditch all that crazy state and crazy usage of props to drive the behaviour of your application.

[hermanradtke]

I worked on a system where someone did this. They didn’t consider data races so managing this system became impossible.

I don’t use redux, but I also don’t think this is the way.

[emadda]

Why not use a MobX state class, then just write to state.cache_date? The state is in the parent lexical scope of the components, so no prop drilling or providers.

I used to use events just like this, but once the app gets bigger it’s hard to keep track as the event keys are strings. There is no IDE support for tracking usage (functions and class properties allow jumping to and from usage).

Also MobX tracks dependencies based on reads and auto re-renders changed components. This replaces having to hook up event receivers manually to re-render.

I think there are newer mobx state management systems nowadays (Signals is the new term).

[maronato]

Events and state need not be mutually exclusive. I like Vue’s approach of state going down the DOM tree and events going up. This works really well with Context and custom events that are dispatched by components (vs by the window as you did).

IMO global events can get messy quickly and make it really hard to develop more complex apps where you have the same component in multiple branches of the DOM firing the same events.

[gloosx]

React is actually really simple functional renderer, 20 files, 316 KB

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.

[mvdtnz]

I stopped writing anything in react the moment they introduced that ridiculous hooks API. Very clear they have no clue at all. There are plenty of other options that don't reach so hard to appeal to functional purist propeller-heads.

[maronato]

I couldn’t disagree more. Having components be pure functions makes testing and developing so much easier, not to mention the reusability of hooks. Class components were a mess. They had way too much business logic and state stuffed into them that it was impossible to maintain any reasonably large component.

Of course you can still write shitty code with functional components and hooks, but at least now the paradigm itself steers you towards more maintainable code

[chrisco255]

The hooks API is entirely optional. By all means you could continue using Redux or Mobx or class components.

[kaba0]

Sounds like you are the one without any clue, unless you have anything substantial to say.

[gustavus]

Cycle of frameworks:

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.”

[giljabeab]

On the contrary some much older and experienced frameworks are simplifying and consolidating. .NET for example

[kevinsync]

lol which of the Forsaken is React? Aginor, creator of the Shadow DOM?

[bemusedthrow75]

This article is written from a lack of experience of fundamentals and it is not very rigorous, but it's kinda sorta not wrong.

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?)

[namaria]

I also feel that there's a growing need to teach fundamentals to people across the board. On the other hand, there doesn't seem to be any market for it. So many people become 'developers' by attending 90 days bootcamps to get a job quickly and so many more avoid anything technical altogether because they're 'not a technical person'. So I doubt there's any market for teaching these basics...

[dbrueck]

His points are why I like Svelte. YMMV, but for me it hits the sweet spot of not having to do a lot of stuff by hand like we did in the jQuery (and earlier) days while also not being this massive, intrusive thing.

[darylteo]

And thus the cycle of JS libraries continues.

- Large standard library exists

- "It does too much! It's slow! It's too hard to use"

- "Here's a new library. It's 28kb and lightning fast"

- Becomes new standard library

- "... but it doesn't do this thing"

- 2 rewrites later

- Large standard library exists

[tuan]

> Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running.

It feels like the author is confused between react (the library) and the its ecosystem. They don't need all those things in order to use React.

- Routing: Not mandatory. You can just use server side routing. You're no longer a SPA in this case, but do you need to be a SPA ?

- SSR: I actually do not understand the new obsession with SSR. If you need SEO, add a static marketing page, that might be enough for a lot of scenarios.

- CSS-in-JS: just write a plain css file and class names

- State management: useState + context API works for a lot of simple apps.

I don't even understand why "hot reloading" is even listed in the complaints. It's a nicety, not a requirement. It's not even "react".

[nitwit005]

People seem convinced they need to pull in 12 different libraries and frameworks these days, and then get mad that it's complicated.

Of course it's complicated. You made it complicated.

[adamzochowski]

Oh the irony of a text blog bemoaning complexity that won't load without javascript.

[bottlepalm]

Did I miss the part where he suggested what to use that's better than React?

At this point we've been through enough front end churn, React is fine. Components, static typing, a javascript/html based templating language. Server and client side rendering. With Next.js my DX is better than anything I've used before.

Vanilla JS? Yea, no thanks. I'm not going back to square one, choose your own adventure custom framework because of your skill issue.

[rdgddffd]

This just sounds like a bunch of vaguries that could be written about any framework. And React works fine for small projects. There’s no need to loop in a bunch of dependencies like css in js or graphql either I’ve been using it for years.

[Aeolun]

I have to agree that with the introduction of React 18, and the new versions of Next and SSR everything has taken a turn for the worse. I’m sure it’s all very fancy and advanced, but it’s become completely impossible to reason about.

[zamalek]

React has lived long enough to become the villain. It definitely pushed web apps in the correct direction, but it has grown some nasty kludges to account for things that were very hard to foresee. Choosing to use it nowadays for greenfields projects comes across as cargo cutting to me.

I somewhat disagree that the approach is ill-suited to simple sites, server-side JSX is a strong step in the right direction. If you're using it on the server you may as well use it on the client, even for minor interactivity problems.

[jinushaun]

As someone who has been doing React for nearly as long as it’s been public, the honeymooon is definitely over. Hooks were supposed to save us, but now my projects are more complicated and harder to maintain than the old class based components. My team is constantly fixing useEffect and useCallback bugs. UseEffect just traded one foot gun for another.

As Vue and Svelte have shown, maybe it’s time for react to include a compile step to automate some of the boilerplate/tedium and reduce avoidable bugs.

[niceice]

But without the complexity that layers of abstraction create, Snapchat would only have 1 person working on buttons instead of 400.

[koonsolo]

Here is the number 1 thing you need to realize about web development: it goes from simple article websites to ecommerce to full blown applications like Photopea or Figma.

People act as if it's all 'web development'. And then you get things like "We need to move back to server side rendering". And I think: why the hell did you think using a front-end only framework was ever good for your e-commerce website?

It boils down to this: figure out what you're actually doing, and get the best tools for that.

React is an awesome framework, but if you're building a simple blog, why the hell would you use that?

[malakai521]

I've done front-end with PHP, ASP.NET Web Forms, Razor, jQuery, AngularJS, Angular and React and React was by far the most enjoyable experience I've had. It made front-end development tolerable and even fun. I've never seen React code that was as horrible as Angular one.

[acomplexplan]

This post is just a list of grievances that don’t convince me in any way why I don’t need it.

Maybe, I don’t care if it’s “overengineered” or maybe I don’t need something fast or maybe I need an abundance of talent to work on it. There are plenty of reasons why it might often be the best choice.