React chaos in mid and large web apps: Any different experiences?

I've been writing React for a long time, and I loved it for the first few years. I thought ui=f(state) was brilliant. But over time I've come to realize that what I really loved was JSX, and I was merely putting up with React's rendering model so that I could use it.

As I see it, React has the following problems:

  1. The web is inherently imperative. Using things like setTimeout or autofocus is a real pain with React.  
  2. The state of your application is orthogonal to the structure of your UI, and coupling the two causes a ton of headaches.  
  3. React takes complete control over your UI, so adding UI plugins usually requires specific integrations. The google maps SDK comes to mind.  
  4. By taking complete control over the rendering process, React creates a barrier between you and the DOM. You stop thinking about the web platform, and you start "thinking in React." This degrades your quality as a professional engineer and causes your platform expertise to deteriorate over time.

If you're a react developer that started in the industry in the last 4 or 5 years, I'm sorry. The web industry did a real disservice to newcomers by pushing people so heavily into learning react from day 1, potentially without ever learning HTML, CSS, or browser APIs.

Do yourself a favor and learn the platform if you jumped right into react. When react inevitably loses favor and the jobs dry up, you'll have a much easier time when you know the underlying platform and better understand why react does what it does.

Don't take the above as some claim that react is already dying, it could still have plenty of time left. It's just inevitable that it will eventually die and web development jobs will move on to something else.

It's one thing to complain about React causing chaos, valid, but I would like to remind everyone about the absolute trainwreck we had before. Just slightly before polyfills and opinionated frameworks. Sure, spinning up a quick JavaScript-infused html file with a jQuery CDN link was probably the fastest way to get going, but structurally, on anything larger, this was a horrendous nightmare for most projects I came across. The amount of variables that ended up window. or similar, the various slight differences of JavaScript versions/engines/browsers, the trillions of home-made everyone-does-it-their-own-way solutions to standard problems (from cookies to animations, from error handling to networking).

I like it more, than I liked it in the past. It's uncool to say that, but I was so happy to see structure in the world of JavaScript.

Strongly recommend React-query (now Tanstack Query). ~50% of those useEffect and useState hooks are simply loading data or tracking loading states, mutation state, etc. This really improves with Tanstack Query.

Even better is to get Tanstack Query for free with type-safe backend in T3 stack.

Hard to overstate how much the symptoms described in this thread can improve simply from this.

The whole argument about Angular ten years ago was the learning curve. I’m on a project now using React with Next and find the code so difficult to read or reason about.

The organized mid to large web app DOES NOT EXIST - it is a myth, like sasquatch. In the swath of experience I've had from working small startups to massive corporations I have never seen this mythical "organized mid-to-large sized web app" nor heard of anyone speak of it.

There will ALWAYS be cruft, and doubly so in a webapp since what is essentially the "build target" is always moving, heck the language it runs on is always moving.

The title of the post might as well be, "has anyone else worked in a mid to large sized web app code base?". The experience is ubiquitous and has nothing to do with React specifically. In fact the problems that the author mentions, "Large component files with excessive composability" for example, is easily overcome with the exceptional tooling that now exists in the JavaScript/TypeScript ecosystem - of course one might not realize the huge strides that have been taken here if they've only been doing web dev for a couple years.

Anecdotally - I really don't like to see Reddit posts pop up on HN, it degrades the quality of this site towards Reddit's level.

> "useEffect" [...] this function is absolutely not intuitive

100%. I've found `useEffect` is an effective foot-shotgun, even I still blast away some toes with it. What makes it some weird to me from the start (React 16.8, ~2019) is how they folded several, clearly named, lifecycle methods into this one callback. The motivation for this change [1] informs me that maybe I've just never worked on Facebook-scale front-ends or I've just forgotten the pain of explicitly having to write all those methods, but I rather liked their separation.

[1]: https://legacy.reactjs.org/docs/hooks-intro.html#complex-com...

We've definitely experienced chaos when building large React apps. I don't think it's necessarily React's fault (though I'm not particularly a fan), I think the complexity is inherent in managing stage in both a client app and a server app. We've since moved to building apps with Phoenix LiveView and been much more productive. I've also built some libraries to give you the same benefits (single source of state on the server) when serving the front end in Elixir isn't an option: https://github.com/launchscout/live_state.

I find working with React and Mobx a breeze, also for complex apps. Not sure, why this has not been more widely adopted. It eliminates usually the need to use those mentioned unintuitive and error prone state handling mechanisms.

I don't mind how the view part of react works, but I don't like how it gets so complicated managing state. With a lot of state libraries for it now just providing lots of hooks you end up with so much in the view. Like you'll have more than half the component be hook code managing state. While I prefer functional view components, there was something said for the encapsulation class components gave you.

We've got our own state framework for react that adds controller classes: it makes it easier to write imperative code, but with ours for the business logic rather than the view. It works a lot like mobx but class based. https://github.com/aha-app/mvc unfortunately we haven't put as much love into the oss library as we should have. We use it extensively in our apps.

I find it makes writing react code much more like writing classical UI desktop UI code, with wired up controllers and models.

My experience:

  1. Hooks and functional components were supposed to save us, but has made react harder to use in large codebases because most developers don’t use React as intended. A lot of foot guns because most JS devs don’t try really understand closures. I remembered way less problems and bad practices in the componentDidMount days. 
  2. React demos well for small apps, but its un-opinionated nature means there is no standard for large codebases that need to load remote data and manage shared global state. No one likes redux or any other de facto solution. React needs to come with batteries included, or at least strong opinions on how to manage large codebases.

I'm an experienced web dev, who mostly works with Vue. Sometimes I have to work on React apps.

Skimming through the list of sins, pretty much all of them look like things I do on a regular basis. I do not understand React. I find it pretty much incomprehensible, incredibly complicated, and overly complicated for what it does.

I can't really described what `useEffect()` does, only that it's a solution I use when other things don't work. I can't tell you when I should use `useRef()` rather than state or props.

I never have any of these issues in Vue. Its conceptual model has always been pretty easy to grasp, although it got messier in Vue 3 since they tried to copy React more.

With server components/actions you get rid of most useEffect()s and a lot of useState()s, and with the upcoming React compiler you get rid of useMemo(), useCallback(); Redux and other state management tools become pretty irrelevant for many server-component-driven apps as well.

But I agree that React attracts a lot of mediocre and inexperienced programmers, and does not provide very much guard rails against doing bad things, so predictably the average code quality is terrible.

I've encountered all the issue listed in the post. The worst for me is redundant (overdetermined) state, that is, when a state variable is actually derivable from other state variables. It's pointless, confusing, and broadens the space of possible states, including impossible and inconsistent ones.

Using HTMX after dealing react is a huge breath of fresh air for me.