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

31–40 of 52 posts

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

#31

Post by stevage »

mittermayr wrote: post #14

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 acr…

>but I would like to remind everyone about the absolute trainwreck we had before.

That isn't good enough. People make the same argument about Git. "But it was so much worse before Git".

React was a useful step forward for its time, but it's not a great solution now.

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

#32

Post by Jcampuzano2 »

squillion wrote: post #6

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.

I see this all the time, even with coworkers who have worked with react for years and when I question it they have such a hard time understanding what the issue is with this.

Not using derived state or in other words not using the minimal state required is one of the most common issues I end up seeing, people just add state everywhere not realizing a lot of the time additional state is not needed and every little variable doesn't need to be separate state.

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

#33

Post by Jcampuzano2 »

presentation wrote: post #28

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…

It doesn't help that React is the go-to for getting a job nowadays and most people skip over even the most basic fundamentals to just immediately learning React, without having ever understood the principles behind React or what problems it was created to solve in the first place.

Any developer who I work with who started off just learning React is notably lacking in understanding and skill at webdev when compared to those who did not just jump straight to React.

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

#34

Post by jgalt212 »

jemmyw wrote: post #20

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…

serious question: like writing classical UI desktop UI code

Why are front end app frameworks so different from desktop GUI frameworks?

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

#35

Post by azemetre »

parthdesai wrote: post #11
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/ba…

What does back office mean in this context?

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

#36

Post by deweller »

stevage wrote: post #29

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…

useEffect() replaces component lifecycle hooks in Vue. useRef() is the answer to this.$refs in Vue.

Agreed that Vue and React are very different flavors. I think Vue has a shallower learning curve. In spite of React's problems, I do feel it scales to larger apps a little better than Vue. Both are great solutions.

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

#37

Post by jmisavage »

tstrimple wrote: post #13
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…

Angular is only opinionated for a few things you can still end up with a mess of third party libraries mixed into Angular.

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

#39

Post by refulgentis »

kabes wrote: post #12
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.

My first real job was at FAANG with 2 co-technical leads with 0 reports and 3 people working with them.

They were iOS-specific, and called in to lead (and I was hired) after a sprint where not-iOS people had built an iOS app. It was pretty good!

The problem was, their heads had inflated so much that they had ascended to the heavens in terms of self-proclaimed computer scientist.

So they wasted months and months rewriting the app to have a Redux implementation in Objective-C, 4 years after Swift came out, and pitched it as a final solution to making the app reliable and dev velocity fast, as compared to that horrid codebase they had to inherit.

The relaunched app took 18 months, was missing features, had a 2/3 higher crash rate. And the core problem, network reliability, came down to them acting like the networking code was some prized expert-level thing only they could manage...but the issue was they re-implemented TCP and were blocking ACK packets on frame rendering. So it'd be really fast and normal then hit the ack queue limit, and only be able to send one packet every ~16 ms.

Just thinking out loud because it's very funny to find out Redux also ended up being too much in the JS community, and I hadn't heard till now.

But hey, our managers managers manager really liked that one video of that one stilted live replay the initial 6 months in demo could do.

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

#40

Post by blandblender »

unconed wrote: post #17
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…

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

There is a thing among park rangers where “if people are taking this shortcut despite the signs and fences, then it’s the trail that’s wrong, not the people”.

More software engs should think this way instead of “educating harder should solve incompetence”.

It’s not that people are incompetent. The trail is wrong.

Post reply on HN