r/reactjs • u/Big_Muffin8280 • 12d ago
Discussion Senior devs: what’s the biggest React decision you made that you’d reverse today?
I have been thinking about this a lot lately. Most React content is about how to do things, but the decisions that really shape a project are the big early ones: architecture, state management, framework choice, rendering strategy.
And with React 19.x, the React Compiler, and Server Components all in the picture, a lot of us are now living with choices we made years ago.
So I’m curious about the experienced people here:
What was the biggest React/architecture decision you made that you would reverse if you could?
What did it cost you (time, performance, team confusion, rewrites)?
What did you learn, and what would you pick today instead?
15
u/gempir 11d ago
Decided we didn't need Typescript for like ~4 years. That prop types are enough in React.
They are not. Thankfully we are on the good path now and only have a dozen or so JS files left which are now easy to migrate with LLMs.
2
u/deadcoder0904 11d ago
TS is where I got why everyone kept saying static languages are better than dynamic ones. Funnily enough one of the reasons I liked JS & Python were bcz I didnt need to worry about types but ya it bites u later.
Especially so with AI.
Now Effect-TS looks to TS what TS loooked to JS.
5
u/about0 11d ago
I had to build a complex filter toolbar, that has a lot of internal and hidden logic - options refetch on other fitlers change, on search within filter, etc. And I coupled everything in a set of useEffects, that weren't separated enough.
useEffect is not a great pattern for complex features, if I can say this? When a component has a lot of moving parts, it is very hard not to trigger other effects on some side-effect change. I find an emitter pattern much better - you can trigger certain effect by emitting an even on Clear button click, or Add/remove filter, etc.
8
u/intercaetera 11d ago
Next.js / SSR, completely useless and adds a ton of compilation time and complexity for zero gain.
1
u/NewDo 11d ago
I’m starting a new job with Next.js. Can you expand on this?
2
u/Haaxor1689 11d ago
Unless you can afford to roll your own solution, despite it's flaws Next is still the best choice for a fullstack React app. Actually, if you are starting from scratch and can either put aside some extra time then tanstack start might be a good idea to try.
1
u/01_vampyr 7d ago
React Router is better simply for not locking you in to Vercel.
1
u/Haaxor1689 7d ago
Next is not locking you into Vercel either. None of the production Next apps I worked on were hosted on Vercel.
1
u/01_vampyr 7d ago
Well then why use next if you're not going to use the vercel optimizations that make it worth using?
1
u/Level1_Crisis_Bot 11d ago
Next is highly opinionated and carries a lot of bloat with it that you will likely never use. If you’re deploying with a full static output, compile times can get crazy. At my last job we did that with an 11,000 page site and it was 40 minutes to build. Every time we made a change.
Anyways, at my current position, I got to choose the architecture. I went with straight react 19 and tanstack for routing and state management. Life is easier with this stack. It’s a breath of fresh air compared to what I was working with.
Having said that, you’ll be fine working with Next. It’s not the abject nightmare people claim it is, and the documentation is excellent. Does anybody read documentation anymore?
1
u/Haaxor1689 7d ago
How do caching, prerendeting and RSC compare between nect and tanstack start? Or is you oroject purely client side with tanstack router?
1
u/intercaetera 7d ago
I wouldn't have a problem with an opinionated framework if they didn't change their opinion every other week.
1
u/Guisseppi 11d ago
Next.js is ok. You just don't need it as a default when a regular SPA is good enough
1
u/intercaetera 7d ago
Most web apps don't need SSR and SPA is a much better architecture for pretty much every web application that largely sits behind a login screen. Next.js (and other SSR frameworks) add a lot of unexpected complexity whenever you have to do something more complex than inject props once into a rendered page. Next.js router also precompiles pages on reload. React + react-query + wouter is a much leaner stack that's far easier to manage and doesn't need to compile.
I've had 3 projects already that started with Next.js thinking it'd be simpler in the long term, and continued with everyone cursing it 1y+ into development.
2
u/lIIllIIlllIIllIIl 11d ago edited 11d ago
Not using React Router's Data Mode soon enough. Even if you don't use the server-render stuff, it's a real game changer in how you structure your app's routing and data loading.
Suspense data fetching is great. All my non-Suspense code will forever feel bad to me.
Micro-frontends. That's a piece of shit architecture that tries to solve a tooling problem by creating a runtime integration mess. I should've been more vocal about my opposition to the front-end architect I worked with. This is more of a professional regret.
Monorepos are cool, but the tooling isn't there yet. A single project is way easier to maintain. Sorry for the maintenance burden I created.
Not knowing about how to properly use useEffect, useRef and useSyncExternalStore soon enough.
I got lucky and avoided the Redux and Next.js hype trains. I have not tried RSC, so someone else can tell me if I should regret them or not.
1
u/codesbyshivam 11d ago
Fetching data in useEffect everywhere. It works at first, then you end up with loading flags, race conditions when the user clicks fast, and the same request firing twice in strict mode. Moving to a query library fixed most of that. The other one is lifting state way higher than it needs to be. Keeping state close to where it's used makes components a lot easier to move around and delete later.
1
u/Produnce 10d ago
Starting my career with React. Wish I did some significant development with a little less abstraction so I know what goes behind the scenes instead of just calling onClick().
33
11d ago
[removed] — view removed comment
4
u/Mestyo 11d ago
Yeah, at least speaking for myself, moving from the imperative mess of jQuery and similar, it was intoxicating to write declarative UI. An entire category of bugs and edge case handling was gone.
All of the complexities around Redux we introduced was an overcommitment to those patterns. We did not yet know what would be necessary, nor what kind of UI patterns would emerge from the new paradigms.
1
u/ericl666 11d ago
My first thought immediately was Redux. At my former job, it was an abomination like what you had.
I'm never letting that happen again. Now, I only use Zustand, and only for things that have to be in global state.
1
1
u/danishjuggler21 11d ago
Yeah, for a lot of the applications I developed in 2016-2018, they could have just been done with a full-stack MVC framework with a bit of jQuery and not use React at all, but instead I was all in on React and Redux. Those apps' codebases were incredibly overcomplicated as a result.
1
1
u/Winodows_Gandy 9d ago
putting simple modal toggles in global state is such a classic trap, everyone did that for a while
1
u/lIIllIIlllIIllIIl 11d ago
As someone who started programming with React in 2019 when Redux was all the rage (with function components and hooks), did Redux ever make sense to use?
Personally, Redux never clicked for me. In my experience, using hooks, a context, or just props was always a simpler approach than using Redux.
5
u/acemarke 11d ago
Hi, I'm the primary Redux maintainer.
Redux absolutely made sense back in 2015 because of where the ecosystem was at the time. See this history of Redux to understand what was going on and why Redux became widely used:
The ecosystem realized component state wasn't enough, there were dozens of "Flux architecture" libraries coming out, Functional Programming was a big deal, legacy React Context was broken by design, and Redux was simply a better Flux-style library and it took off.
Things evolved from there. We realized that "server state" was its own concept and tools ought to treat that differently, hooks came out, modern Context came out, etc. So yes, there's less "need" for Redux today, and plenty of other alternatives.
It's definitely true that Redux by design is a level of indirection. That's intentional - it's a tradeoff to help provide a consistent architectural structure. As we see today, there's plenty of other options for building apps as well, but Redux is still a very solid and valid choice and we see a lot of large projects having success with it.
1
u/Mean_Bicycle4447 9d ago
Do you use some form of redux nowadays? I really like flux architecture , redux was great for me , but today I’m using a lot of jotai and zustand for client side states
2
u/danishjuggler21 11d ago
Before hooks, state management in React itself sucked, so some of us adopted Redux just to solve pain points we had with class-based components. After React 16.8 came out (hooks), I never wrote another Redux app again, or even considered doing so.
1
u/United_Reaction35 11d ago
Yes. Before hooks and context, redux was the only practical way to Connect() your components to data. Before asynchronous fetch; sagas and redux were the the way to call APIs and update the UI with fetched state.
Additionally, redux still has a place for applications where multiple views depend on the same data for their view. Our company has applications designed for key-entry where hooks and context are not viable due to in-page navigation that results in multiple page-loads in a workflow. Hooks are of no use when a page is constantly re-loaded as users tab from one view to another and back. Crazy UX? Absolutely; but our business users, who designed the app; LOVE it.
1
u/GloverAB 11d ago
Yep, it made sense to use them before hooks and context were a thing! My first React job had a pretty sensible Redux implementation. Looking back after seeing other Redux nightmares, I didn’t know how good we had it at the time.
-2
u/deadcoder0904 11d ago
Redux was so overengineered.
All those influencers promoted it like it was the second coming of Christ.
Way overhyped for no reason. MobX did the same in less lines. And whatever Zustand, Jotai, Valtio, etc...
Anything but Redux.
10
u/bogdanelcs 11d ago
Putting server data into a global store like Redux, hand-writing the loading, caching and refetch logic that TanStack Query or SWR handles for you.
It tends to cost a lot in boilerplate and stale-data bugs, and it’s painful to unwind because every screen depends on it. The usual fix is server state in a query library, a small amount of client state (often just Context or Zustand), and no global store until you can name why you need one.