Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

old.reddit.com

Post reply on HN
Print view View original

11–20 of 52 posts

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

#11

Post by parthdesai »

twright wrote: post #9

> "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-e…

Loved react till v15, I'm lucky enough that I moved into a strictly backend role right about when react 16 was introduced. I don't comprehend how hooks stuff is more readable. I occasionally browse the front end code in our company when trying to debug an issue, and the code just looks so un-intuitive. It's littered with `useHooks`, `useEffect`, `useMemo` and stuff.

It's night and day comparing that to our backend/backoffice written in Elixir.

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

#12

Post by kabes »

yayr wrote: post #8

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.

Yeah. I think mobx is often disregarded as mutable state goes against the react philosophy. Instead they somehow rather make monstrosities of codebases (redux anyone?) just to avoid it.

And mobx is really just signals everyone now loves automated via proxy objects.

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

#13

Post by tstrimple »

jzig wrote: post #5

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.

Angular has the advantage of being opinionated. There are proscribed ways to do certain things and it’s “batteries included”. React is a much more loose and flexible tool and you’ve got to mix and match other components to have an equivalent framework. This means angular has some advantages when used by less experienced or cohesive teams. It’s easier for a react project to spiral into maintenance hell because you can mix and match tools and paradigms easily. I would expect most angular projects to be easier to understand. React puts all the consistency work on the developer.

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

#14

Post by mittermayr »

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.

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

#15

Post by mittermayr »

yayr wrote: post #8

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 optimized Mobx away by switching to "zustand" – it's another layer of simplification and I haven't had a project where it didn't work. Next to zero dependencies and it just "works". Mobx got me angry once they had too many breaking changes from 4 to 5 etc.

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

#16

Post by _heimdall »

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.

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

#17

Post by unconed »

bluelightning2k wrote: post #7

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.

In my experience React codebases turn into this mess for two reasons:

- front-end devs don't know how to think declaratively and think in terms of state transitions instead of realizing intent

- back-end devs build a classic REST-like API which provides zero affordances to drive a proper reactive front-end.

React-query is a good solution to the wrong problem. It's basically an elaborate and ornate footgun that allows you to stretch guess-based cache invalidation to its limits. Each piece of data has to be tagged with front-end only query keys, and cache invalidation requires you to re-implement and repeat your business logic optimistically in all the individual `onMutate` and `onSettled` handlers.

The actual problem to be solved is how to reliably sync data to a front-end and mutate it safely. Doing this well requires you to architect your data so it is syncable in the first place. You should separate sources of truth from derived data, you should use uniform APIs for CRUD manipulation, you should probably version your records, you should express mutations as universal patches, and so on.

Cache invalidation should only require substituting one globally addressable record with another one, and/or telling the front-end to refetch it from the source. If you are doing complex data surgery or traversals, you're doing it wrong, because that's what the reactive rendering is supposed to do for you. Anything else is a trap for juniors.

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

#19

Post by danielvaughn »

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.

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

#20

Post by jemmyw »

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.

Post reply on HN