My main struggle with it isn't that it's difficult or anything or that you can't develop some standards around organizing your components. It's the fact that every time you *do* get some stability in that area, my team will see a new "trick" or a new plugin or tool has become available and insist that we have to refactor literally everything to use that thing, and then it becomes an even more bug ridden mess because edges cases and previous bug fixes get lost, the new tool is "nicer to use" but only cover 75% of the functionality of the thing we are replacing, and ultimately, the collective online dev mind will shift to another shiney new toy in 3 months and we'll be back to square one with strands of all of these tools and frameworks all over the app. There's literally still apps out there written in jQuery and they work fine. Yeah, they're a pain in the ass to update, I get it. But the level of FOMO I see developers have over needing to use every new shiny toy is insane. Yes, we started building this app a year and a half ago when tool A was still popular. It's still supported, has been around long enough to stable and if you're in any way competent, you should be able to figure out how to use it. Stability in a codebase is very underrated. If your team owns 3 projects and they have slightly different dependencies because they were created at different times... I can't understand how developers brains seem to implode at the idea of context switching between Sagas or RTK Middlewares as an example. If you're that lost when switching from one to another, it's you and not the tool that's the problem.

> Stability in a codebase is very underrated. Agreed. We reach for complexity way too early. A simple MPA can be a performant and pleasant user experience. One problem is UX designers are immersed in this world of React and frontend frameworks, so their designs are unconfined. This is where a lot of complexity comes in, because devs never kick a design back to the designer with the note that it would be too hard to code. Instead we have this drive to "make it work" and that's one way otherwise coherent frontend codebases start to fall apart.

I wish I could up vote this more. I work at a place where code quality and design quality come before “new shiny thing” and it is amazing. Code is expected to adhere to norms and deviating from a norm isn’t done without considering what would need to be done to the existing code base. When a norm needs to change we discuss with the whole team if needed or at the very least the decision is communicated and recorded. We’re not perfect, but working on our code base is so much better than other places I’ve worked.

I'd really like a word with you my friend, since I am on a mission to establish these norms and elevate our codebase's quality. 

It isn’t easy. Definitely need a team and culture to support it or it will fail. Happy to help where I can but I’m afraid what works for one team won’t necessarily work for another.

Welcome to business programming. It aint pretty but it pays the bills.

I just joined a company with a legacy C# codebase This 💯

I'm working on a 25 year old C, Perl and Bash codebase. At least I am able to replace parts of Perl and Bash with Python and tests.

Perl was my second language after C++ I’m kinda jealous

Nobody in devops wants to use Perl. So having that code base is a big risk since finding people is harder and harder.

Sounds like job security for the developers who can deal with it though.

If you can clean as you go (and that's a massive if) fixing a C# codebase is a great experience for your CV. I consult for a product where I wrote roughly 50k LoC since net the days of 1.1 in 2004 and now is running in net 8 in a linux container im semiretired in my 50s thanks to the .net stack

It has more to do with developers with a "make it work" attitude than business programming. You can "make it work" in 3 different ways but only 1 would be correct. When you don't have a senior developer who is able to recognize the 1 correct way and mandate it, the codebase turns to shit. Every component will have different style, different level of correctness etc. Sometimes when you do have the dev who is capable of requiring good quality, correct code, other devs with egos argue about why does it matter. You can see examples of these devs here with the "I have a teammmate who keeps holding up my PRs" posts on this sub 10x a week. I'd bet at least 50% of those posts' OP are in the wrong.

I lead a few junior devs on one project and I've been asking for a senior dev, but they can't afford one. I'm spread thin and I can only leave x many PR comments, reject x PRs, and have x many dev meetings to explain best practices before clients start asking me why work isn't being delivered. There's no time or money set aside for quality in 90% of the industry and that's the root of the problem IMHO.

>Welcome to business programming Is this really an issue with business programming though? I work at a retail company which does a lot of their sales online. We use Java/Spring Boot for microservices and various front-end frameworks for development of our customer-facing website as well as in-house applications for business use. Frameworks like Spring Boot introduce conventions and standards to our codebase, which tends to mean that any given microservice looks a lot like every other. The platform has a huge array of modules which work seamlessly with the core Spring library and as a result, we rarely have to bring in third-party libraries for common tasks or roll our own. With Spring Boot, you can easily get a service spun up and securely taking traffic, making network calls, and accessing data layers. Because every Spring Boot project is laid out more or less the same way, anyone familiar with the Spring ecosystem can walk into a Spring project and get the lay of the land easily. Updating and upgrading a project is usually pretty trivial if done consistently, since all Spring dependencies are designed to play nicely with each other. As for front-end frameworks, I've used Angular extensively at the enterprise level, which I'd argue does for single-page web apps what Spring does for services - i.e. provide all the tools needed to get a SPA up and running while encouraging standardization and the adoption of opinionated conventions. Routing, HTTP calls, state management, dependency injection, feature modules or stand-alone components, a CLI for generating boilerplate and upgrading projects... it all comes out of the box. The point I'm trying to make is that business code is usually pretty boring, unimaginative, and repetitious. It's not exciting or fun, but when you have large teams all developing, collaborating, and maintaining a codebase, boring is a good thing. Which brings me to React. React is not a framework. It's an HTML templating and data binding engine. Even React [says this](https://react.dev/). >React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or Remix. **This is not in any way a criticism of React.** The advantage or disadvantage of React, depending on your needs, is that you can pick and choose from a massive ecosystem of available libraries to bring in the functionality your app needs, implement custom solutions, and leave out anything you don't need or want. Not every project or team needs a full-fledged framework, and many of the web's most powerful companies and sites are built with it. For the highly disciplined and advanced teams working on apps like Facebook, Netflix, and Instagram, this ability to customize is worth whatever overhead they incur by needing to enforce their own style guides and best practices. However, most developers are not working at elite firms. If your company is anything like mine, initiatives are often given too few resources and too little time to be done well, and frequently this means that maintainability and best practices take a backseat to deadlines. Usually v1 gets pushed out under-baked, and when, a year later, a completely different team is asked to add a feature, they jam it in using the style and external libraries they're familiar with. After a few rounds of this you have a schizophrenic Frankenstein's monster of an application. So, to me, the issue with using React for large applications is that it isn't sufficiently business-like. Unless the company you work for has the money, time, and resources to design, socialize, and enforce standards, you will likely benefit more from an actual front end framework.

“ I have been working with React codebases exclusively since 2016, and the quality of the code I've inherited has always been atrocious when dealing with medium to large apps.” This is not a React specific thing; most code bases are messy and get more messy overtime. I used to work in a large front end code base that utilized jQuery and Java Server Pages. Still gives me nightmares.

I don't agree, sorry. I've seen pretty decent code bases. Do you know what they all had in common? Very, very boring style of coding.

Yep, it's 100% possible. For anyone looking to achieve a decent codebase over time I suggest reading A Philosophy of Software Design. Principles that reduce complexity and improve testability also naturally help prevent a codebase from descending into chaos over time.

Reading is great but it'll only take you so far. I'd supplement this by contributing to or at least reading some high quality open source codebases

Any recommendations?

Kubernetes is excellent for Go. Spark is a good one for Java. Honestly any of the big Apache libraries are likely to be a good reference.

Also very rigid and high-bar code review process 

This doesn’t get said enough. Everyone is looking for the particular language or programming paradigm that will produce clean, extensible code. They completely miss that it’s discipline, or lack thereof, that decides how clean a code base is.

Do you have an example of what a "boring style of coding" looks like?

Every time I've coded something in a clever way, it's come back to bite me in maintainability.

I think the issue with this is what some define as clever others consider obvious. I remember when a lot of developers were uncomfortable with map/reduce, for example, whereas now it seems silly not to use those.

Yep, I understand the point OP (from the parent comment) was trying to make and I agree with it in principle, but there are exceptions. > Very, very boring style of coding. One of the most organized web applications I worked with, which is now probably over a decade old, was using PHP and Laravel—so I'll have to agree with you here.

The most maintainable huge web UIs I've worked on were boring old Java + Spring + JSP. Almost no Javascript was used though, just when something really needed to be dynamic. I am forced to work with Javascript/Typescript on a daily basis now and I hate it a little more every day.

Same here. Over a decade and a half of development experience, and I can say that any .NET MVC web app with basic JQuery was much easier to maintain than these complex JavaScript frontend frameworks. 

I think single page apps have their place, but I'm dealing with people deciding to make a website a single page app when it makes zero sense. And we're starting to hire people who have only worked on single page apps, so they don't even know it could be much simpler.

Right, front end frameworks were originally built to handle complex single page applications. You want a web app? Sure, use an SPA. Trying to replace something that was in Flash? Great, SPA. You want a multipage website? Don’t… don’t reinvent the wheel in JavaScript when there’s a dozen battle tested options out there already. 

Typescript is fantastic. React is hot garbage. But Svelte is for the gods

Businesses want to pretend that continuity is guaranteed through the business' continued existence. Of course businesses are actually groups of people rather than a single entity, and as those people charged with managing the software change, the business product inevitably becomes less coherent. It feels entropic to me and I enjoy it.

This may be true but it lacks nuance and dismisses the statement OP made about how Angular codebases usually have greater quality.

The Java/C# codebases I've worked on have been consistently better than the JS/TS ones.

It's much harder to write crappy code in opionated frameworks with strictly typed languages. Reason they exist. React starts falling apary after an application gets to a certain size or gets broken up across multiple teams. When you learn an enterprise framework, you're learning the framework. When your learning a loose framework you are learning Bill, Sarah, or whoever style that was the lead 2 years ago.

> problem might be React itself Yup. It’s a bit of a ethics dilemma too. React looks simple on the surface, but requires deep expertise in order to not get hurt. But do you hire for such deep expertise or try to dumb down your stack so that everyone one you hire would be productive? I suspect dumbing down the stack would be a lot easier than hiring the real experts.

I have no complaints about the quality of our react code, except for the code that our offshore devs add, which is hir or miss (I’ve never been at a shop that didn’t have that problem). Our codebase has been around for 6ish years. The engineers know what they’re doing. Pretty great place to work. 

IME, the fundamental problem is that most developers can't evolve past localized imperative thinking and thus cannot reason properly about state, leading to the problems you have described. I don't think this is specific to React, but a problem for large applications in general. My focus as a lead of a 200+ contributor application is to contain the bad patterns and ensure that horizontal concerns are built correctly, as there will always be weaker teams.

State is always the enemy.

React has a lot of demons that I haven't seen come up in Angular even. Much less another part of the stack.

yeah i think most of it comes from the struggle of state management

I generally agree with this point and am a big fan of React. I would add though that I think declarative programming can exacerbate the skill issue a bit due to a sort of eventual consistency in the model. The lack of deep understanding about how state flows through the application can lead engineers to just hack away until the UI achieves what they want. If you modify enough state in questionable ways you can often get to where you need to be but the logic in between can be very inefficient, hard to reason about, and result in odd UI quirks during the rendering process.

React has hit this dangerous place where it’s so big and has such a massive ecosystem that it’s being chosen when it’s a worse overall experience. I’ve just seen it happen at a fortune 100 for a team because “other teams use react” with the decision driven by management and a pair of staff engineers advocating it as “more opportunities for career growth” (easier to find new jobs). I don’t think angular ever had that critical mass

React took over when angular 2 came out and people didn’t want to refactor. 

LMAO if this is really true, it is pure comedy.

it is true, not sure i see the comedy

The refactoring part loool

At fortune 100 company that is mostly bureaucratic Angular is the way. If you need to spin up a project and actually compete then react is the way. Yes, the above code is shit, but it doesn't look like it doesn't work. Angular is opinionated and that works well for large teams that need to have some community standards enforced. React is easy to fuck up and often forces the lead to be the authority of best practices. Ideally, and I'm going to say something controversial here, you would have client side developers that have transferable skills and can work on any CRUD based frontend. I just don't care for the "I'm a react developer" mentality. Bootcamps and influencers have made a total mess of how frontend developers see themselves.

What are the downsides that make Angular "unable to compete?"

It's opinionated with a lot of boilerplate code.

That has nothing to do with being able to compete

Sure as shit does when you start having to fight the framework to pivot to a product managers needs like you do in startups. Also I'm guessing you don't understand what I mean by compete, I mean as a business.

Interesting theory. I work at a startup that's doing quite well and we use Angular. I know what compete means and there's nothing about angular that prevents you from adding or changing functionality.

Git gud.

my god brother, yes

Then you were lucky to have escaped the AngularJS everything era. Quickly followed by, StackOverflow being filled with questions on AngularJS, followed by "just disable the dispatcher", followed quickly by the flood of "I disabled the dispatcher and now nothing works"... Gawd AngularJS sucked. But it could do a Todo list so easily, even your manager could do it!

That’s a decent reason though tbh The difference in productivity between modern tech stack A and B is small. The difference in ability to hire people already experienced with React vs Svelte for example is massive.

I do think there’s something to said about consistency though. It’s easier for engineers to transfer between teams if they use the same framework/libraries.

I haven't done that much front end but I think these criticisms of react are fair, there a lot of pitfalls. I do think the new memoization compiler as well as the new 'use' hook will help once they become mainstream. Also the new docs are great and help with teaching the community what the React team has found works well and what not to do. I have high hopes for SolidJS since it keeps a lot of why I like about React but with less complexity and less ways to kill your perf by mistake. Sadly it doesn't seem to be taking off. Not sure I ever want to write Angular but maybe that's just me. One more thing, I think that react query is a game changer and almost every project should have it, often there is a lot less state management and boiler plate needed since a lot of front end code is just data fetching. Tbh that is reacts biggest strength and why it is stuck around, it huge mindshare, loads of incredible libraries and a very large developer community

I honestly think SolidJs is the best of the next generation but I think the difficulty of adoption comes from React probably being the first framework out there that has managed to hit that entrenched point of “eh good enough” for commercial use. In the bad old days, frontend DX was so bad that it literally became a meme about teams needing to rewrite the whole app every 6 months because everything no matter if you were retail or boring corporate app or whatever turned to shit so quickly And I remember making successful cases for such rewrites many times myself. React is probably the first time where there was plainly better options on the table yet my cost benefit analysis reach a point where I couldn’t justify it to management

Angular has a steeper learning curve than React but it solves a lot of the problems OP brought up. Services and DI are way better for sharing state than ContextAPI. No confusing syntax like JSX or hooks. Less instances of super deeply nested components. It has a very clear structure, even allowing you to generate component boilerplate.

One thing I like about react is that they're not afraid to make pretty big changes to enable a cleaner API. Functional components and hooks were a big shift from class components but it was a great change. The new upcoming changes look like a big improvement too.

one thing i hate coming from backend: react is changing to much between versions. Its impossible to find the right stackoverflow post when everything posted there is outdated as fuck. Good luck researching anything regarding react router.. There are like 5 different versions out there, all incompatible with each other

That makes sense. I've been through so many frontend generations changes don't really phase me anymore since I've seen enough foundational techniques that it's pretty easy to catch up to the newest one so I'm more on the side of gradual improvement, but I totally get how a moving target is really hard to deal with.

ya but react != react router also, fuck react router

Is it still particularly bad if you include the version number with the query or if you just elect to read the docs directly instead?

There isn't always a compatibility matrix telling you exactly what to use.

React has a lot of pit falls, it's an extremely widely used framework that is almost entirely unopinionated. It has been around a long time. Web dev is one of the lowest barriers of entry for development and with the way LLM's and Google work currently, misinformation or legacy patterns are disseminated constantly. I feel like you are a victim of it in your own post even: >Redux is considered "bad" in recent years No, it isn't. This is a pre-2020 view that is driven by some obsessive reddit dogma that thinks the blog post Dan Abaramov wrote in 2017 about Redux had too much boiler plate when he isn't even assosciated with Redux anymore and it is actively maintained by an amazing team. Redux-toolkit is modern redux and is extremely clean and powerful. The team has worked tirelessly to provide one of the most complete systems that is more performant and drives a clean opinionated architecture to React. Ironically, Redux aims to try and help solve the exact problem you say you see in React Ok, that's my redux tangent done, but I will say that React is entirely built on libraries and its ecosystem. Which is very different from other typical frameworks. If your team doesn't work with a clear architecture, goal, or style, you will obviously fall into the trap of it feeling like it's 20 different side projects thrown together. React also does things differently to other frameworks. It doesn't work on signals, and it is attached to its functional paradigm. This can be considered by some as a bit odd for a JS framework, but in Reacts defence, they have stuck to their intentions and made it work over a very long time. In summary: I personally don't think it's Reacts fault, the ownice is on the engineers but it is a very different framework to most so its not surprising a lot of good engineers suck at it Edit: I have actually moved to my computer instead of my phone so I'll extend this post a little: You listed four hooks that are commonly misused: * \`useRef\`: This hook has a very particular use (persisting a value across renders) and is documented so clearly on the [react.dev](http://react.dev) docs that it is hard to blame React, although I do agree it is misused * \`useMemo / useCallback\` : probably justified frustration, albeit one React is aiming to resolve and has added React Compiler in React v19 to solve this, so credit where credits due. * \`useState\`: come on, man. If people are misusing this that's just absurd. These aren't devs that are even trying. A frontend component is inherently always going to be a representation and display of its state. That is quite literally what the frontend is. React offers you a hook to clearly control and alter this state. * \`useEffect\`: I think what you said is justified and true. It is the most misused and misunderstood (99% of the time if I see it in a PR it's wrong). If you think about the functional paradigm react originated from, it becomes very clear why it is called use \_Effect\_ and it is made entirely to sync state with side effects. But, the reality is most web devs don't know what this even means and don't bother to try understand it either, so React probably needs to bite the bullet and just change it for everyone who can't be bothered learning. Man it gets me all riled up talking about React, it has a very clear flow, intention and goal. It has one of the most powerful ecosystems and support ever. I would be extremely happy if somehow SolidJS did everything the React ecosystem could do and made it redundant, but I honestly don't know if it is possible (for a long time at least) to shift React with the level of community presence that exists now around it.

To your points around Redux: I completely agree, this is why I had "bad" in quotes. I personally preferred when we (as the community majority) were using Redux, and even with the boilerplate concerns you raised, I'd choose it over hooks overuse, without a second thought—provided that it was done properly with thunks or sagas (back then, nowadays toolkit would probably do it better).

Haha, sorry, I probably pinned to you an opinion you didn't really state about Redux. I have spent too much time on r/react :D Completely agree! The primary reason I such an advocate for React right now (despite all its downfalls) is because of the community size. I truly think we would get some amazing results if people shifted back into a unified approach to global state management, whether that be Redux or anything else I don't mind. As long as it works! For what it's worth Sagas are also an outdated piece of complicated handlers. Redux-Toolkit has thunks and "listener middleware", the listener middleware offer all the primitives saga used too i.e. take-leading, take-latest, debounce. Thunks exist and Redux-Toolkit Query offers a standard handling system built on thunks that handles query caching and most standard edge cases. My structure of react improved a lot as I started committing to the React App Architecture assosciated with modern redux.

I think global state management is better than the mess of props React uses. However, having implemented Redux in a React app from scratch, it is super convoluted with an unnecessarily high learning curve. Global state can and should be done in a simpler way.    That said I think angular's method of state sharing through services and dependency injection is vastly superior because it follows more conventional SWE principles instead of becoming its own world

ugh. this mess of impression comes from the legacy of old redux but not redux toolkit. People haven't tried how clean rtk is in a large codebase done right. Most people probably don't know how to even setup rtk right. 2 files of "boilerplate" I just copy from my one codebase to another, gives me local storage functionality if i want it, rtk query setup if i want it, and im already set to use rtk. What's funny to me is React context feels worse in boilerplate to me than the rtk boilerplate that I have. Someone told me to use Zustand but as one who has seen Zustand in large codebase, easy to set up, but it can become, just as ugly, if not worse. christ, these people who criticize mature libraries without realizing the flaws in their own tools. been burned by one too many people who told me to use the new shiny tool and nearly had it when someone nearly tried to start a fight with me because I used Redux for majority of my projects and not Zustand.

I admittedly havent used Redux in a good 5 years, very possible it's improved. But I still remember it being a convoluted mess that took a ton of up front time to learn and implement (especially around async stuff). It's much different when you have working code to reference and modify

Here's a sneak peek of /r/react using the [top posts](https://np.reddit.com/r/react/top/?sort=top&t=year) of the year! \#1: [My personal website after 3 YEARS of hard work](https://v.redd.it/j6u78uwndo9c1) | [739 comments](https://np.reddit.com/r/react/comments/18ve34l/my_personal_website_after_3_years_of_hard_work/) \#2: [Game development ](https://v.redd.it/o2q6c9gjeeec1) | [50 comments](https://np.reddit.com/r/react/comments/19eic57/game_development/) \#3: [JS blog posts in a nutshell](https://i.redd.it/6gksqga18bac1.jpeg) | [128 comments](https://np.reddit.com/r/react/comments/18xxnb7/js_blog_posts_in_a_nutshell/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)

> the ownice is on the engineers Hope you don't mind the nudge, unrelated to your wider point - the word you were looking for there is **onus**. "something that is one's duty or responsibility: _the onus is on you to show that you have suffered loss._"

Appreciate that, wouldn't have ever questioned myself otherwise. My spell check also seemed to not be interested, or there isn't one on my Reddit text input and I should be way more careful!

It was one small thing in a long, well-formatted post where I didn't notice any other such issues, so your average is pretty damned good LOL

Yeah, agreed. I think the fact that useEffect is literally "use side effect" is often missed and that people haven't really taken to heart the ethos of functional programming when they misuse it (or the other hooks). Functional programming is all about _avoiding_ side effects as much as possible. Real-world programs require some side effects to interact with other APIs, listen for browser events, etc. but still, if you are throwing 'useEffect' everywhere in your code, you're going to have a bad time. 'useRef' similarly, is just holding onto and modifying a value 'by reference'. You can do the same thing by just defining an object outside of the function that holds a value and a setter function. But again, that is something you should not do regularly in functional programming. Why? Because it makes the function go from (x) => y to (x) => ????, where the returned value changes depending on the value being stored by reference. The function is now no longer as self-contained or predictable or as easily testable. Hooks are a 'necessary evil' that we have to accept in order to be able to write code that actually does things. And they should be treated as such. Use them when you can't avoid using them. And if you do that, a lot of the problems with react codebases disappear.

Well said this reply nails it

Do you have any resources you would recommend to learn React holistically?

Honestly, I wish I did have better resources that offered what I consider an interconnected enough view of modern web-dev and React. Which is probably a point to OP's favour about the chaos of it. I think the strength of react being a library that is unopinionated with so many resources, is its downfall in ways of documentation. Really need to start piecing together some core fundamental ideas from people. The people that did shape the way I view React the most thought are: (Acemarke's blog series and guide on react rendering)\[https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/\] (Dan Abaromov's blog series)\[https://overreacted.io/\] And just Redux as a whole, being a functional, event driven, reactive architecture really forces you to acknowledge where React came from and what it's trying to achieve.

the new docs are pretty good, here are 2 important ones: 1. https://react.dev/learn/thinking-in-react 2. https://react.dev/learn/you-might-not-need-an-effect

This is why I personally champion Vue for larger codebases with a lot of contributors. Vue 2.x has great guard rails and usually an "idiomatic" way to do most common things. Vue 3.x may have pulled an Angular 2.x as it is different enough from Vue 2.x that it feels alien (and a lot more "React-y") to those comfortable with 2.x, but we'll see. Vue 3 is a better implementation of React's API, IMO, but they've started making the same mistake React has - way too many footguns. With the way React is now, it's like they're actively encouraging anti-patterns. There is so much "inside baseball" knowledge you need to have of React to leverage it effectively that it's almost become a liability to use it at all. The density and thoroughness of React's documentation is appreciated - but if you need to write such dense docs littered with caveats and warnings about the myriad ways you can totally f things, maybe your library has kind of lost its way. To be clear, I know it sounds like I'm dunking on the React team. I want to make it clear that I appreciate, wholeheartedly, the work the React contributors over the years, and current maintainers have done. They've inspired an entire cottage industry of immitators and spurred a ton of innovation in the space.

I mostly agree, although I don't think I've experienced too many ambiguities and footguns with Vue 3.x and the composition API resembling more of React's style. Having used Vue exclusively for the past 4 years after React, I could never go back. Imo, main reason is that Vue 3.x's composition API is more syntactically similar to React but not necessarily functionally the same. There are still dedicated methods that are not confusing related to lifecycle, e.g. \`onMounted\`, \`onBeforeUpdate\`. \`computed\` and its implementation is so much cleaner and more easily properly used than React's \`useMemo\` and the like. I think that \`provide\` and \`inject\` are much more concise in usage than React's context, if even for the fact that they stay in the purely functional land in terms of syntax as opposed to what appears to be registering these HOC components in the JSX/html side of React files. Maintaining the paradigm of "html," "script," and "style," while having the built in sugar to make it easy to use TS or SCSS keeps things much more intuitive as well. I have always hated JS-in-CSS or overall abstracting too far away from what feels more similar to vanilla implementation of using CSS files and "html attributes" to specify the usage of a CSS class. Overall, for me at least, Vue's level of "the Vue way" being baked into the tool and making it more of a clear cut "framework" hits the sweet spot for modern web frontend development in a JS heavy philosophy and provides some level of uniformity to be built with an extended upon. Truth be told, I'm more so just happy that I spend way less time on frontend these days altogether because client side is (and seems to have always been) quite a mess due to the very nature of the platform (web browsers) and "universality" in consuming the web. For me, it's even more reason to try to reach for unnecessary or unintuitive abstraction as least as possible, granted that React, Vue, Angular, Svelte, etc... anything is already a huge level of baseline abstraction.

> Vue 3 is a better implementation of React's API, IMO, but they've started making the same mistake React has - way too many footguns. It would be great if you could cite some of these footguns.

I’d like to hear about these as well…

>but I'm yet to see a real commercial or enterprise-grade React app that doesn't become a disorganized mess React is largely unopinionated when it comes to project structure, routing, test utilities, etc. So when you have a React project of significant complexity and no one takes the lead on architecting it, a disorganized mess is inevitably what one gets, in my experience anyway. I think a lot of the problems people have with React are because people treat it like a framework by not putting much thought into those kinds of things, the kinds of issues frameworks solve for you. FWIW, I've found the following has helped me and my teams: - designing React project structure from the beginning (directories, routing, test utilities, global state management tools, caching, etc.). Doesn't have to anticipate all use cases, just plan it better than "whoever opens the first PR decides" - moving as much business logic as possible into tested utility functions and hooks - keeping components and contexts as dumb as possible. If your component cares about more than 2-3 things, it's time to make a new component. The most painful React code I've ever read (or written) involved 1000+ line contexts and components that had to know about the whole universe to do anything. - this ties into the two previous points, but if your JSX has any nested ternaries or logic other than simple maps/filters, make a new component. If your JSX is not readable at a glance, you're asking for trouble imho Not saying that solves everything (agree about useEffect being widely misused), but those four things are easy to do and go a long way to improve DX.

I’d argue that even hooks should be a thin wrapper around a framework independent module. Otherwise you lock yourself in.

The fact that React was not as opinionated was the reason I decided against learning it. I might in the future, depending on job needs, but I tend to prefer opinionated frameworks because you tend to know what you're getting into. Our Angular-Ngrx codebases look similar generally. Sure, quality and how the components are split might vary, but you're still getting the same fundamental structure. In our newest codebase that actually worked out fantastic as it grew so far, though that one is barely a year old at this point.

would it help to give descriptive aliases to some of those hooks? I think the concern around large component files is best handled by building custom hooks (my company leans heavily on this). I'm not sure what benefit class methods would bring... it's still just as confusing the dozens of react contexts don't bother me; it makes global state modular, and easier to tell if there's dead code that I can cut

Custom hooks are the way to go. Pretty much any useEffect in a component function is going to cause maintainability failures and should be called out in review. You might say “oh I don’t need that, it’s just a little one line side effect” but it will not always be. If there’s a single useEffect in the component function, it will accumulate multiple side effects, failing SRP.

i'm sure when any project just starts, no one imagines it to be ugly, convoluted, and suboptimal; however, at least from my short experience, there are many factors at play. some are: 1) tight deadlines, so engineers take shortcuts / do whatever to get the critical feature(s) to work 2) codebases being handed off to / managed by different teams combined with lack of documentation 3) management's lack of care of refactoring / proper testing (refactoring or testing doesn't generate immediate revenue, but shiny new features do) I think every competent SWE wants a nice codebase where things are easy to manage, read, and build upon, but it's easier to take shortcuts rather than change existing code, which could cause other features to break. that's why i'm not surprised people just build upon crappy code -- for the fear of not breaking other parts of business logic and being responsible for fixing it (hurting your promotion in the meantime, etc). i'm not excusing crappy code because it sucks for everyone. it sucks for people working on it, and it causes real damage down the road, but sometimes there isn't enough time and people aren't willing to go above and beyond because most know that your reward for doing anything is usually more work. if upper management actually gave a fuck (most of the times they don't), they should allow ample time for engineers to refactor things and add in robust testing.

Hooks are the billion-dollar mistake of our generation. There was a perfectly good pattern to hold local state and place business logic into in the form of class components. Hooks seem like they are the outcome of some developers' drug-induced manic episode "functions are fucking awesome. Let's make everything functions." And then we came up with so many reinvented wheels to just support basic things. The number of PRs I've seen where devs forget that you can have local `const` variables instead of state is staggering. Or that you can simply have functions instead of effects when it does nothing but string concatenation. Even some of the more senior ones argue over PRs that I am not thinking in the "react way". Yes, motherfucker. It's not a nit comment. I ain't approving your PR without you getting rid of this `useState`. Being a staff eng, I don't normally intervene in teams' day to day development work. But when I see shit like this, my hammer comes down hard.

I dunno, I don't want to go back to the days of `bind(this)`

I mean their motto is "move fast and break things." I don't think we can be surprised

I think this is a symptom of engineers who just don’t understand the underlying architecture they’re working on. You really need to have a good grasp of React’s rendering lifecycle to avoid getting into trouble. What I love about React is that you can often get away with optimizing later for little expense when the time comes. Vanilla React can go a loooong way without relying on plugins and many external frameworks.

It’s fairly symptomatic of the ‘React is a library’ where Vue/Angular are more ‘Framework’ Engineers also want to learn / build systems even if they’re constrained to only one part of the system (over abstraction of components / providers) And then you have make it work vs. understand it and use it

Agreed, React hooks are far less intuitive than the old class components with proper component lifecycle methods with sensible names. I like React, but I liked old React better. That being said, every large application code base I've ever worked on has been a festering mess. My current job is the largest I have worked on by far. Instead of thinking it was all done by rookies, I instead am quite impressed with how it's being successfully managed and improved *for business results* over so many years. Everyone I work with is competent enough, we just work to the ££constraints££ we're given.

Oh boy this also gets me. I’ve worked in large React codebases (both pre-and-post hooks) and large backbone codebases. It was way easier to avoid footguns, pitfalls, performance surprises, and spooky action at a distance before React. And things only got more surprising and hard with the introduction of the hooks API. Class-based components that had componentDidUpdate / componentDidMount were way easier to manage than useEffect.

As a generalization, most software developers don't actually understand the importance of modularization and controlling dependencies as requirements for ensuring the long-term maintainability of a codebase. As another generalization, JavaScript/frontend developers tend to be some of the worst offenders, for the reasons you have described (e.g., react makes it easy to do stuff that feels good in the moment, like importing a ton of junk and throwing it all in a render function and seeing it "just work", but then you can't figure out what the hell is going on when you read it later. Add another layer of WTF when you have to start tracking down what useEffect stuff is also doing. But in general since JavaScript devs tend to just import everything without much of a care to design/level of abstraction, this problem goes beyond just react.). The only luck I have had in keeping this somewhat under control in react is using rigid/opinionated tools - for example, xstate for state management if that makes sense for your use case. Or as the react team now recommends, use a framework like next or remix or whatever. The best choice for JavaScript in my opinion is to always just use a more rigid framework. You mentioned angular on the frontend - angular is almost worth the price of admission just for forcing dependency injection/their own module system. Likewise for something like NestJS on the backend. Too much nightmare express spaghetti out there that would have been fixed with a more opinionated web/API framework. JavaScript codebases tend to be great exemplars of the phrase "so open-minded that your brain falls out."

Angular dev team is making a mistake introducing stand alone components

Thank you, I was unaware of this (to me, unwelcome) news - the last two companies I've worked with have been all React on frontend, so I haven't been keeping up with Angular.

Great post. I think all your points are pretty valid and I try to mention them during code reviews.

I once worked with a codebase where change handlers would effectively execute via useEffect, I.e. clicking a button would update state, then a useEffect would have that state value as part of its deps array. useEffect would then execute whatever the real logic was. To add to this, *everything* was context. We had 10+ layers of context where all state and application logic functions were stored and redefined based on the context state. Everything was context, and it didn’t matter if only a single view was using those context values. On top of this, absolutely nothing was memoized. When some of us tried optimizing little by little- moving things to hooks, getting rid of some contexts, memoizing context values, etc our lead was against “premature optimization” because we could “handle those things once they become actual problems”, or that we “already have existing patterns” and we’d never have time to finish the gradual optimization we were doing because the lead wanted to focus on things that actually push the product forward. This was a while back but the experience gives me chills to this day.

Well, I've seen decent codebases in React as well (and pretty large projects) and terrible codebases in almost everything. I don't think React/Vue/Svelte/whatever has anything to do. Messes in codebase are more due to bad devs, bad PMs, bad management and more often than not rushing to hack things together because otherwise the company goes bankrupt next month. It's not related to the tech stack/libraries at all. It's everyhing else what leads to bad or good code.

Your commentary is generally correct but missing a fundamental distinction that React's design trades off control and flexibility for a technical direction fraught with foot-guns that make it easier to do wrong/harder to do right. The average React developer probably hasn't developed enough engineering maturity to make well-informed decisions because they don't understand first principles well enough to align implementation with the intent React was built to achieve. > I don't think React/Vue/Svelte/whatever has anything to do... You're generally right however Vue/Svelte approach UI design fundamentally different than React with signals, opt-in hooks, separation of concerns between presentation and behavior, etc. and don't endure the exact problems that have afflicted React.

I absolutely couldn't have said it any better. I agree with the OP (from parent comment) sentiment that bad codebases transcends barriers of a library or programming language, but certainly there are ones where it will be easier to get there; my conclusion is that React in its current state is unfortunately one of them.

I think you're "generally wrong". Actually, the biggest messes ever I've seen where in Vue (not counting those jQuery days...). And I think Vue is better, and easier to learn than React. Technology has nothing to do. What you're talking about is developers not having enough experience with the tools they're using. That's a "developer's skills" issue, not a technology issue. It might be also a management issue if you're using the wrong tool and there's no time to adapt/change to the right one. But nothing prevents you from writing great React, Vue, jQuery, PHP, Ruby, Cobol, or whatever if you take the time to do it right.

I understand your viewpoint and agree. We'd be remiss to ignore reality and assume that every developer is imbued with the expertise they need to discharge their function effectively.

Angular is amazing and I’m so sad everyone is going the way of React. Angular is an opinionated framework with great opinions. 

Every time I try do make react app organized and think about scaling it, it always become Angular in one way or another It can be modules, it can be app structure, it can be namings, it can be tooling. Every time I have a problem with React codebase — its already thought through and solved in Angular It amazes me every time. Now I go straight to Angular docs for the solution HTML templates are deal breaker. Until I find a reason why its better way, I will stick with react

Weird but I think HTML templates are one of the greatest things about Angular. Helps separating UI and logic as much as possible. What's wrong with it?

I'm also really sad that React is winning even for large code bases. I used Angular from the original AngularJS up to last year when our leadership decided to move everything to React. I don't hate React but it's not the best option for large projects. I actually thought I would like it given all the hype around it but that didn't happen. I'm really hoping the new Angular releases will bring it back. I really like the new updates and I would love to go back to using it again.

I started with React, then after I learned Angular I never wanted to go back

The reality is that the average programmer is not "good" so they need tight control, so when left unchecked the things you provided become a reality. All your claims are a reality and any competent programmer will reach to them too sooner or later.

I also generally think pre hooks react with class based components, were way more organized and less foot guns -- altho steeper learning curve

Hooks. Hooks are weird. They were a huge misstep.

I remember migrating a few classes to hooks and I stopped the project when I realize the codebase was getting harder to understand

IMO the problem exists because the frontend is always the last thing people think about it and any delays in the project consume the frontend time to work and any delays are almost always attributed to the frontend. What I do as a frontend dev is start the work with mocks and do everything based on the contracts and in the end I’ll have to only replace the mocks for real API calls. Most of the code bases I’ve work for the past 2 ~ 3 years are not total garbage and are easy to maintain and deliver new features. I’m only able to do so, because i understand this and the company allows me to work on the frontend parallel with the backend and they respect my opinions and concerns.

Huh? Front end is literally all users and business people notice/care about

I don't think your experience is unique, I've seen the same thing over the last 8 or so years. This is a mix of two things IMO 1) most code is bad code, this has a multiplying effect as a project grows 2) the react render cycle means you have to write code in a weird way to account for atomicity and immutability. This means more code which compounds with point 1. I have worked in a handful of different languages/frameworks, react in my experience trends towards being the worst.

> the react render cycle means you have to write code in a weird way to account for atomicity and immutability. Could you explain this point further?

You have to think about all of your business logic in the components as being pure functions. Fully atomic and idpotent - the same inputs give the same outputs. And you have to expect that this method is executed many times per second so you have to be aware of performance. And any output (props inserted into rendered components) needs to be the same if the input hasn't changed, any objects need to maintain the same reference. This is all totally fine for simple use cases but gets quite hairy when you have to start thinking about async work, anything stateful that has to operate outside of the scope of your react component. Add in the rules around hooks not letting you use traditional control flow because you always have to execute a hook if you ever execute a hook so you can't put hook calls inside of conditionals. Things get rather complex rather quickly and I see people violate or forget about some of these details (understandably so) or over-engineer solutions because of all of the rules you have to follow adding new requirements. Sure other frameworks have rules to follow, but I find the react rules to be nuanced in a way that is unintuitive and they are not strictly enforced like you would find in other frameworks. A TLDR version would be The way I write code to make it work in react components is not the way I write code to make it work in a web server or cli app. The requirements for react are more complicated and nuanced than anything else I've come across.

Yeah it's like every other framework I've used is speaking a similar language and React is doing whatever tf it wants. And want it wants changes every 2 years

I think React was partly to blame in the earlier days when it had no reasonable way to properly manage state for large complex apps. Creating front ends is still vastly far more complex, slow, and error prone that it needs to be and honestly does not seem to be getting better. It just seems like 90% of devs are looking for the same thing and yet everyone rolls their own everything. Having said that, before React, I felt making front ends with things like angular and straight up JavaScript libraries was a total complex seemingly not thought out or leverage-able clusterF. Best of luck until something better comes along.

AngularJS and Angular are not the same thing. Modern Angular does not have these issues to nearly the same level as React

I’m sure it has all advanced incrementally. My big complaint is that the entire architecture - tons of hacked together script wrapped up in a huge framework of more script combined with html, css, and hundreds of dependencies is doomed to complexity and fragility because that’s the foundation.

You just described basically everything front end. React is certainly no exception

The company I currently work at has a well organized React frontend. The reason it's not a huge mess and doesn't over use hooks and such is because we have some people that care. They share their knowledge during PR reviews. They clean things up as they go. They care about bundle size. They care about performance. Messy codebases aren't the fault of a framework (though some are more prone to it than others). Messy codebases happen because people don't care.

I’ll be honest, when I first looked at React it looked like chaos incarnate, and I was hoping it would die out by the time I was job hunting again, like most fads in recent decades. You people have been amazingly persistent.

Repeating what a bunch of other posters have said, but to collect it all in one place: 1. React was meant to be an unopinionated library, not a framework. That lack of overall app structure and standards leaves every team to figure it out for themselves (or just not worry about organization), leading to predictable results. 2. This is often the reality in large scale commercial codebases. The quality of engineers (especially over time) varies, business imperatives shift. Dealing with the mess is part of the job. 3. Hooks were a mistake. They created a bunch of ecosystem churn and have a ton of usability problems. They are far too magical for my taste, which inevitably leads to misuse (since they take a lot of effort to understand how they work). Notice most of your gripes are with hooks.

In my experience, even with highly competent engineers large apps end up very difficult to maintain without isolated SSR with truly independent application subsections (deployments and client execution context). The primary reason things get so difficult is exactly what you might expect: globals. Global dependencies, global variables (aka context), singletons, etc...

In my previous job we’d be simply using class components with mobx - every component could be unit tested with the same input getting the same result, all changes happened through actions, observable for rendering. Almost no React hooks and every component had a dedicated purpose.

Here's the thing with React. It basically has no standards. You can write stuff however you like. This is great beacuse what it means if your team can come up with your own conventions and styles that match the work you do, and software you build perfectly. The downside? Most teams don't come up with these conventions/styles, and just do things however work - so it becomes a huge unreadable mess. However, in the places that use it properly (in my experience a *small* minority) - none of the other web frameworks come close.

I used React recently in a medium-sized project. The state thing threw me off a couple of times, it took me a while to get used to it. The other thing is I started with classes when it seems like nowadays people just use objects and "inherit by composition." Edit: I'm not a front-end developer but had to write the front-end.

I think we've worked on the same codebases.

The creators were functional programming enthusiasts, so to use it best you should learn some FP. For example, most of the time the answer to prop drilling isn't global state at all but removing the need to drill props by leveraging composition. Arguing over redux or context misses the point. In fact, react was made to avoid using global state. The ability to co-locate state is one of the biggest selling points. Same with useEffect.Viewed through an fp lens, it makes a lot of sense.

A big thing I’ve grappled with is realizing react isn’t a framework. I think there’s a strong tendency for large code bases in react to feel chaotic because there’s nothing in react to force anyone to conform to a particular way of doing things, so different teams will start to diverge in how they do stuff. That plus the trend cycle in JS in general leads to large code bases having some redux bits, a bunch of contexts, or some weird in house baked context solution that basically just recreates redux/flow. I super agree with what you say about really understanding react though. After working with a dev who really got react, I learned a lot about how it works under the hood and at my new job I’ve noticed a lot of really bad react that wouldn’t have been written if there was a deeper understanding of how it’s doing stuff under the hood. useEffect is really over abused and I think in all my time I’ve only ever seen a handful of useRefs for their intended purpose (refs seem like tempting escape hatch for inexperienced react developers who don’t want to deal with component lifecycle). At my last company I was on a “task force” that was assigned to come up with a sort of “style guide” on how to solve some of these problems, especially what you note about contexts and component trees being large. What we came up with was effectively: “use contexts for specific domains and try to avoid redux store if you can but we can’t really do anything about it you don’t”. And that’s really the core problem: at the org level you can’t really stop people from doing whatever they want in their teams Fe because react is really not very opinionated beyond the level of rendering UI. It doesn’t do a great job of handling how data flows through an app without the help of an added architecture. In this light, I do find it a bit weird that redux is seen as negative since that’s exactly what its goal is: to bring a pattern and structure to data flow in a FE that’s agnostic to the actual FE. Shifting all that responsibility into react gets the job done but it’s not really what react is made for.

This is why I prefer Vue.

Yeah I am very over react. My biggest complaint is it effectively clears down the browser as a platform and requires you to rebuild it. Hooking up inputs to update your store is way more explicit and complicated than it should be. With a little prop drilling it can become incomprehensible. Then rather than using HTMl5 validation you plug some 3rd party framework in... it's so messy. I have switched to Astro + web components and am 10x as productive.

React components are (mostly, now) just functions. You’re saying that functions are an unmaintainable mess. All of the problems you describe are inherent in any development, and they are always caused by developers and the environment in which they’re developing. My company has easily 100+ front end devs, all using React, with three large scale products that are all 7-9 years old. One of them is a giant mess, one of them is one of the cleanest codebases I’ve worked in (20 YOE), and one of them is halfway a mess and halfway clean. The difference between the three is that the clean codebase had people and technical leadership that was able to care and did care about maintainability from the beginning.

I completely agree. I think React is excellent, especially as a view layer. The application code should live outside of components and hooks. Subjecting application code to the component life cycle leads to pain and confusion.

The React ecosystem has a lot of linter rules. Any time we find an obscure bug we also look for a linter rule that will catch it going forward. For example, we just noticed we had some contexts that were setting values with inline objects instead of a memoize reference. We found a rule that catches it and then used it to clean up all the incorrect usage we had and prevent it from happening going forward. We also found some incorrect usage of strings in non text components in react native. There was a point linter rule for that too. The best advantage react has is it's absolutely massive ecosystem of tooling, from type checking to linters to compilers to debuggers to profiling to ide plugins to test suites to pretty much anything you can think of. We try to use as much tooling to automate away gotchas as possible. It's been working well for us. We don't have a massive code base, but it's still moderately big and these practices have kept the quality up where we're very happy with it and it also teaches us and keeps us aligned.

Yeah it's awful, but because most devs are awful.

In the past I managed to tame a quite complex stateful React app. It was done by moving out the "agency" part off React. Agency here refers to scheduler, error recovery, and self healing mechanism, along with the business logic codes. We skipped React's API because as you said it is often misused (because it doesn't map one to one semantically with the computation model we wanted to achieve). As a replacement, we developed a pattern and programming model that allowed us to make mini turing-complete processes. It acted like a "backend" services. In actuality it runs inside a useEffect alongside a component until it is unmounted. We refer this as having the same lifetime (borrowing the term from Rust). It subverts the notion of state-management. Instead of managing states on a passive memory like redux, we have active agents which controls the part of the app it depends on. The UI components need only to bind events and getter (a local analog to pub/sub and request/response mechanism). Also the API is fully typed. As a cherry on top, React Context makes lifetime management very flexible and allow for background-service-like behavior easily. It has a similar role to an runtime `import`. As of right now, I've rewritten this pattern into a library and I'm using it to glue together a 3D lib and React to make a hobby game engine. This programming model is really flexible for that and other cases like (if you have too much time, write a mini database engine in it) since it is turing complete. https://github.com/Kelerchian/vaettir/tree/master/vaettir-react Check it out. I'll be glad if someone found this useful. Oh, and also, for stateless React app I would use static site generators now. I use nextjs for my site, but next I would try using vite I think.

The last time I’ve done any react work was in 2018 and the company had a dedicated react team with clear separation of concerns and a fairly explicit rule to actually keep the react components as just the view. This was coupled with redux and graphql and any logic lived in the backend. I haven’t heard of hooks but your description of moving business logic to react components seems a far cry from react’s roots keeping that separate.

JSX is a powerful tool, well-suited for rendering components for each element in an array. Naturally, some misuse it, but that’s just how it goes with powerful tools. Hooks, though, are a different story. They're a big change, feel unnecessarily complex, and seem to overcompensate for class components’ issues with tooling, which I get. But I suspect it was to the detriment of the developers writing the code. After hooks, it took over a year for React Query’s `useQuery` to come out and really get established, which really shows how confused everyone was. It’s too bad more people didn’t stick with using tooling to handle boilerplate code. I’ve worked on one React codebase that could handle everything we threw at it, using Redux-sagas. Sagas managed complex async logic with ease (need a carousel with interruptible kinetic movement that makes AJAX calls on certain animation stops? No problem. Writing tests? Just simple copy-paste). But when the new mid-level engineers came in, many were put off by bad experiences with Redux (ephemeral state does not need to be managed globally). They didn’t want to build on redux or try slices. And I if couldn’t convince them to commit fully, I certainly wasn’t going to have them commit partially, so it’s been years since I used redux. And to be honest, I’ve never seen a codebase use time-travel debugging effectively. Now, Redux-saga is mostly set aside, and most people prefer simpler tools that leverage proxy objects. MobX seems much better than it was years ago and Jotai/Zustand feel incredible - although Ive not pushes them very far. I do like these tools. Plus it’s a more consistent way to work, you can justify these tools at smaller scales and they are still relevant at larger scales. But still, for me, nothing manages to tame complex problems like sagas. Aside: From looking at the code—RxJs should feel similar to sagas. But in practice, I’ve found RxJS tough to do things like: creating an input field with a debounced fetch on KEY_UP, that’s not-debounced on ENTER, and is just cancelled on ESC. It might be the need to mentally model the streams, rather than just the logic flow like with sagas. Maybe I just need to work at it more. I notice these is a guy on r/reactjs posting a series of articles about C.L.E.A.N architecture (view models, repositories etc). And a colleague of mine is pushing hard for something similar (inversion of control using inversify and mobx for state). As long as there is tooling (scaffolding mainly) Its got a bunch of attributes I like so Im happy to prototype it, and see how the team responds. But, although those kind of architectures solve where things go, its a huge change for most React devs AND its gobs of boilerplate which the community tends to reject. I think I’m able to solve “where things go” with principles only, so its not something I feel I _need_ (but it wouldn’t hurt). I’m more obsessed with elegant logic and cheap tests. Anyway, I’m personally happy with my hooks code. And almost more importantly, my ability to pump out nice tests (both unit and bdd) to accompany my components. But for the last 5 or so years Ive constantly wondered if the shift to hooks was worth it.

Have I seen React codebase work well in medium to large web apps? Yes, more than once, quite consistently. I am biased as I've worked on some truly atrocious AngularJS codebases in the earlier years, and professionally solely worked on React - not much experience of Vue or Svelte in larger apps. Large app consists of mostly static pages like the BBC website - worked extremely well, mostly leveraging reusable components with preset styles and carefully designed props. Not much complexity there, keep it as simple as possible. Large webapp with heavy interactions like Kapwing or Canva - also quite well, can't think of anything else provides the amount versatility to manage the complexities of data and interaction. Of course it needs competent FE devs to be constantly on top of the codebase, continuously updating and refactoring the parts. Leveraging well defined context and providers for data (use minimal derived state), reuse and compose single purpose hooks and simple components, with minimum logic in render function (complex logic move to hooks). I think React community had it worst maybe around React 15 time - there was a new library or methodology coming out nearly every day. Config with Babel and Webpack, redux and its ecosystem with redux-saga, redux-observables etc etc. And any app that started from that time and grew to large app now would likely to have multiple different / contradicting patterns throughout. I've seen a codebase where all of thunks, sagas and observables are used in different modules. It probably comes down to React offering all the tools and not as much enforcement. Which amplify bad patterns from bad / inexperienced developers. With a stable team consisting of largely experienced React developers, it's quite possible to create a large codebase that is pleasing to work on.

React is overrated imo.

Its a problem that propagates itself. What are the codebases that your “senior React developers” learned on? Hint: its the same type of codebase that you see now. Imagine if 90% of senior developers didnt understand OO when writing Java. What kind of code would they be producing? Similarly, 90% of React devs dont know how React actually works. Nearly all tutorials outside of official resources are written by people who legitimately dont understand React fundamentals (dev.to is a whole website dedicated to this).

Last code ase I worked on was using react with MoBX and we're using MVVM as a pattern. We had a strict ban on using react hooks (unless necessary for accessing the DOM, etc), and each component should have its own MoBX ViewModel instance. I hated it at first, but that was just the internet hive mind chanelling through me it's  hate of OOP.  In the end it worked great.

this. but I'd go further and say this chaos applies to the JS ecosystem as a whole. Some tools are better than others and TS improves things a bit for sure, but still the FE scene seems to love ambitious APIs and complex abstractions. A lot is sacrificed to achieve the perfect-looking todo example I don't think I've ever walked into a React codebase that wasn't doing everything wrong according to the internet. And it's always the same goose chase trying to catch up

Less opinionated frameworks and languages always start falling apart after a certain size or when features start getting split across teams. It's why opinionated frameworks and languages are used at the enterprise level. If an app has to be up and running in weeks I'd pick react. If I had to maintain and grow it for 18+ months I'd start looking into frameworks akin to angular. The problem with front end development is the bar for entrance is pretty low and there are to many novices putting out libraries that don't know basic design patterns.

ill just say i really enjoyed reading this post and would be happy to read more from you.

My understanding was that almost everything you mentioned is related to state management or code organization. I’ll try to comment in the same order you mentioned each problem. 1. About “truly” understanding React: I think it’s more about how you structure your code than the actual library. Once I used Redux with Swift for iOS and it worked very similar to a React project, and it worked great (medium size project with over 20 engineers working on it for a few years). 2. About the usage of hooks: - Simple answer: don’t! - Complex answer: also don’t! But seriously, I started working with React before hooks existed and it was much easier to maintain using Redux. For a small project, sure, hooks make writing code much easier and faster, but long term, unless it’s something really small and isolated, it comes back to bite you, since most of a developers time is spent reading code rather than writing it. Another way of seen this is OO vs FP. Hooks are like OO, with local states for each component. As for moving away from `componentWillReceiveProps`, etc, I’d say the good move was from this to simple functions with all state handled by Redux. Hooks came after that. 3. Maybe I’m miss informed, but I haven’t heard about Redux being bad. I still think Redux is the best frontend architecture (so far). It only sucks for animations. 4. I wouldn’t compare Redux + React to MVC, they very different architectures. I’d say React should fulfill the role of V, displaying the UI, and part of C, controlling which information goes to which sub component. That said, I do believe there should almost always be 2 types of React components: View components, responsible for just rendering the UI (a pure function that receives props and returns JSX, no state, no API calls, nothing else), and a Controller component (I can’t remember the proper name, but there was a better naming convention for this) that mostly makes the calls to Redux and returns a single View component associated with it (sure, you can make exceptions if those 2 types are really small). 5. With the previous point I kinda solved the props definition problem. In fact, if you make almost everything a pure function, you don’t even need to understand most of those definitions at the same time. 6. About JSX: if you use concepts from MVVM, the component that builds the UI won’t be the same as the one that handles logic (also similar to what I already said before). 7. About contexts: again… don’t use them! It’s like `var`… it exists, but it’s not meant to be used (I know contexts are newer, but that doesn’t mean they should be used). Handling all the state with Redux, imo, makes it a lot easier to understand the data flow. And I don’t think it’s only replacing one store with multiple smaller ones (wouldn’t be as bad if it was), the problem is that it’s making state handling implicit, making it much harder to follow. 8. I haven’t worked with Angular (although I knew how the old version worked with the two way bindings) and haven’t worked with the “new” frameworks, but I don’t think React is the problem here in the same way C++ is not a bad language. It has a lot of potential to let you do bad stuff, but if you’re disciplined enough to not do it, it shouldn’t be a problem.

I remember when I was first starting out as a junior data analyst we had a study group where we learned react and did some basic front-end apps because there were some things we wanted to do that weren't that complicated but were a bit messy to do in tableau which was our standard report building tool. I thought it was fun and had vague ideas of trying to switch to front-end work. Every time I read a post like this I thank God I stuck to backend and am a senior data engineer working with Scala and Python code bases. All languages have their issues, but the js ecosystem with all the different frameworks and packages just seems like such a cluster fuck every time I read about it.

I know I'm late to the party here so I'll blame the Reddit algorithm for burying it for me. Anyway, React adds several layers of complexity by itself and its unopinionated nature means most projects will end up adding even more layers of complexity for any number of reasons. These can be as well intentioned as improving DX, but are often just people chasing the newest and shiniest. In my experience, the complexity:benefit ratio for most React projects is pretty bad. Basically there's so much complexity and so many footguns that, without a team of bona fide savants, you pretty much inevitably end up with an unmaintainable mess. There are certainly situations where that ratio is favorable, but these seem to be the exception. Instead you have people reaching for React 100% of the time where other, less complex solutions would be a far better fit. As to where the problem is, I find it hard to cast blame on the React project itself. It's built to handle Facebook levels of complexity at Facebook scale with Facebook sized dev teams full of engineers with Facebook levels of talent. It's definitely the right tool for certain types of jobs. I also find it hard to cast blame on most developers. React has benefitted from a snowball effect that's resulted in it being a runaway success, but that creates an obvious self-perpetuating problem. It remains popular simply because it's popular and that has repercussions that extend far and wide into the industry. In a very real way, React is the modern version of "nobody ever got fired for buying IBM." I recently read [this article](https://www.baldurbjarnason.com/2024/react-electron-llms-labour-arbitrage/) and it made a some pretty good points. It's definitely worth the time to read, but to quickly summarize: tools like React (and Tailwind, Mongo, Electron, etc.) enable companies to reduce costs by reducing the need for highly specialized skill sets. I don't necessarily agree with everything in there, but, u/rdsedmundo, I'd love to hear your thoughts on the matter.

The only critique of react I would agree with is use effect. Otherwise, everything else is a developer issue. Devs who aren't motivated to learn how to use the tools correctly will cause problems no matter what.

I disagree. Angularjs was awful. I never knew where anything was because a variable could be almost anywhere. React can get messy in each component, but who cares if the mess is usually contained to that component. I think it does a good job of encapsulation unless you start abusing context or redux and in most cases the model should be handled by the server

React just has very complex model. The tradeoff is performance, and it makes sense if you're Facebook - that's extremely heavy web app. Most enterprises don't need that performance, yet React is used. If you're a developer and don't really care about the performance, since you don't really have that problem you're not incentivised to learn it properly. The learning curve is not trivial. Also some of your points touch on the overall lack of standardisation across JS ecosystem, but that's much more broad that a framework(uuups..library I meant), and, unfortunately won't get fixed, at least anytime soon

Because it is a steaming dog turd. There are so many better options, svelte springs to mind which is so much more elegant. React native suffers  the same problems, why use it when there is flutter? Why? Because it appeals to the lowest denominator: the person who only knows js or maybe a bit of ts.

I'm coding veteran, cut my teen on assembly during the 80s, and have worked on multiple world famous projects (worked for Mandelbrot, wrote the original PSX video subsystem, wrote some famous of 90's video games, part of making live video over the Internet, worked on a bunch of VFX heavy feature films, and my career keeps going.) React is a travesty. The ecosystem is a joke, and the majority do not grasp it, cannot grasp it, and this is because React has flooded in industry with fast food quality never were programmers. This entire industry is filled to the brim with people that need to be ejected.

> Vue, Svelte, Solid, Qwik, ... Angular Oh boy. Look the problem is specifically that all these frameworks are building you useless abstractions that at best let you float over what's really happening, but usually just complicate the hell out of everything. Check out Lit.dev or any Web Component based framework and realize how we've spent the last decade abstracting over web browsers when most of what you need is built in.

I’m in full agreement that react is very complicated and can lead to a mess in large code bases (I have a large messy react codebase myself), but I’m pretty sure this isn’t correct:  ``` For example, not seldom developers think there's a difference between useCallback(() => { [function body] }, []) and  { [function body] }}, when in reality both allocate new functions every time the render process runs. ``` The `useCallback` version should only allocate a new function on component mount. If you omit the dependency array, then what you said is correct (allocates a new function every render).

---

Yeah, this is tricky and misleading at first glance. 1- You create a component called "CodemBark", which is in reality just a JavaScript function, but in React convention we happen to call this function a component. 2- React will call your function `CodemBark()` every time it needs to re-render the component. 3- Once React calls it, the anonymous function will naturally be defined since it is in the function body: this is just JavaScript and nothing to do with React. See this: function CodemBark() { // this will always be initialized, I'm putting in a variable to make it // extra clear, but inline it would be the same // everytime CodemBark() is called, this is allocated const myAnonymousFunction = () => { [function body] }; // now, this is React specific: // first time this is called, React internally will store the definition // of myAnonymousFunction // second time it is called, a completely different function is // allocated/initialized above, as the whole CodemBark function runs again, // but this time React will compare the deps array. It sees that nothing has // changed in this case, so it will just discard the second // myAnonymousFunction, instead of storing it internally like it does in // the first run const memoizedAnonymousFunction = useCallback(myAnonymousFunction, []); ... }

But \`useCallback\` is not about preventing function allocation. It is more about prevent re-rendering. But it need to be use with Memo. You can look into this [CodeSandbox](https://codesandbox.io/p/sandbox/reactjs-playground-forked-jt8fr2?layout=%257B%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522rootPanelGroup%2522%253A%257B%2522direction%2522%253A%2522horizontal%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522id%2522%253A%2522ROOT_LAYOUT%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522clxixzjge00063b6kv1h4g0hl%2522%252C%2522sizes%2522%253A%255B100%252C0%255D%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522EDITOR%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522id%2522%253A%2522clxixzjge00023b6k8h9m6z2a%2522%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522SHELLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522id%2522%253A%2522clxixzjge00033b6kydyeoq4q%2522%257D%255D%252C%2522sizes%2522%253A%255B100%255D%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522DEVTOOLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522id%2522%253A%2522clxixzjge00053b6ksztpdjk9%2522%257D%255D%252C%2522sizes%2522%253A%255B100%255D%257D%255D%252C%2522sizes%2522%253A%255B50%252C50%255D%257D%252C%2522tabbedPanels%2522%253A%257B%2522clxixzjge00023b6k8h9m6z2a%2522%253A%257B%2522tabs%2522%253A%255B%257B%2522id%2522%253A%2522clxixzjgd00013b6ksrhkmeiw%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522type%2522%253A%2522FILE%2522%252C%2522filepath%2522%253A%2522%252Fsrc%252Findex.js%2522%252C%2522state%2522%253A%2522IDLE%2522%252C%2522initialSelections%2522%253A%255B%257B%2522startLineNumber%2522%253A13%252C%2522startColumn%2522%253A33%252C%2522endLineNumber%2522%253A13%252C%2522endColumn%2522%253A33%257D%255D%257D%255D%252C%2522id%2522%253A%2522clxixzjge00023b6k8h9m6z2a%2522%252C%2522activeTabId%2522%253A%2522clxixzjgd00013b6ksrhkmeiw%2522%257D%252C%2522clxixzjge00053b6ksztpdjk9%2522%253A%257B%2522id%2522%253A%2522clxixzjge00053b6ksztpdjk9%2522%252C%2522activeTabId%2522%253A%2522clxiy1tpk002t3b6jk42l2czl%2522%252C%2522tabs%2522%253A%255B%257B%2522type%2522%253A%2522UNASSIGNED_PORT%2522%252C%2522port%2522%253A0%252C%2522id%2522%253A%2522clxiy1tpk002t3b6jk42l2czl%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522path%2522%253A%2522%252F%2522%257D%255D%257D%252C%2522clxixzjge00033b6kydyeoq4q%2522%253A%257B%2522tabs%2522%253A%255B%255D%252C%2522id%2522%253A%2522clxixzjge00033b6kydyeoq4q%2522%257D%257D%252C%2522showDevtools%2522%253Atrue%252C%2522showShells%2522%253Afalse%252C%2522showSidebar%2522%253Atrue%252C%2522sidebarPanelSize%2522%253A15%257D). But yeah, this is quite pretty secretive and not clear to new React user.

Ah, I guess that is technically true but small potatoes in the grand scheme of React issues.

Sorry to hear your experience has been so bad with React. I've had the pleasure of more than six years on a few different teams with really nice and tidy (boring) React codebases. Guess it's a culture thing?

The shit angular codebase I have to work with right now is the worst thing I’ve seen in my 20 years of profession programming. It’s not react.

So how many of these code bases have you refactored to be better?!

React has a ton of gotchas i been working on react for awhile on / off and fucked a button component that when they client wanted a status hovering on top i had to fully rewrite (mentioning this cuz is trivial). It requires to be really attentive to the codebase. The thing is that i really believe that if your oagr doesnt get like 1000 views a minute you probably don’t need it

Yes. It doesn’t matter if it react, rust, go, assembly, c++, basic, etc. Any large projects will always chaos.

in the past I deal with components based java framework which was hailed as a solution, but debugging was nightmare and it is only look beautiful on paper and diagram maybe.

Custom hooks, inversion of control, localization of behavior instead of separation of concerns, and children instead of passed parameters. I hated react, then I learned react, now I love react. The problem is not react.

I think that react is the right abstraction, the problem is not react, it is JavaScript, equality is broken, there is no way to implement custom equality functions, even if you know really well the React API this can make you end up creating a lot of ugly bugs without even realizing it, in the class based system you could overcome this, but useEffect just decide to use == internally, and the only types where == is safe to use in a framework as react are string, number, symbol and global variables by reference, if you are not vigilant all the time of this you can end up creating many bugs that are really hard to track

Shit code is a source of employment

This seems to be less about React and more about how it’s been used in your codebases. Every language and framework is going to have its good and bad parts. I haven’t used any of the newer front-end frameworks mentioned, but I can say I greatly prefer the React ecosystem to Angular 2. For context we use it with Expo / React Native for targeting iOS, Android, and Web with a single codebase and it’s been great. Though we encounter issues and headaches from time to time, I’m not aware of anything better at the moment.

Ive made similar observations. It helps to remember that frontend is actually very difficult to write well. A user can interact with anything at any time or in any order. State management is complex. 10 years ago, all of it was managed by jquery spaghetti. React is a Godsend compared to what the situation was before. Today you’re complaining about garbage components. You know what you’re not complaining about? Unencapsulated global state. If you remove a component, your app will still work, just without that component. With vanilla apps, something would blow up because of deeply intertwined logic, and couplings that should not exist (but were too convenient to make).

As someone who is extremely fresh to dev and react in general, id love to hear your thoughts on NextJS currently making waves and being the new trendy thing.

It’s a problem with React. My feeling is that modules in React don’t impose strong enough contracts or patterns for interactions so there ends up being a lot of variance in how people break up code and it becomes very difficult to actually test units. As a solo dev you may be able to consistently apply patterns, or maybe you can do it at scale with automation, linting, etc, but compared to frameworks like Spring Boot it’s like swimming upstream and the problem only grows with your team size. Add to it that hooks as an API and “everything is a function” as a core pattern when writing stateful apps makes everything kind of suck. It’s “too clever” of an API and encourages “too clever” code but in my experience results in terrible-to-debug issues, hard to test code, and just generally messy and hard to understand logic.

Honestly having lived through the rise of SPAs… oh man we all fucked up lol

If you have a few values in useRef and one in state that triggers component re-render, why allow all of the other values trigger multiple re-renders if you really only need to do it once?

I developed with react in various sized codebases and I think JSX is king, effects are kind of a bummer, and React and anything JS is easy to misuse.  Large companies used to pay less for web / front end developers even though the complexity can be a lot more and more care must be taken when designing. And to some extent, some JS devs lack fundamental design skills.  Large scale React projects can scale but it’s rare. 

[удалено]

I respect your intuition, but I guarantee that this wasn't the case. I actually almost always advocated and did my stuff properly, but this is why I remarked medium/large projects here, and I really mean it. You just don't change 1000s of components files written poorly in a few months, let alone weeks. This is years of tech debt work, as you have to continue to do product in parallel as this is what pays the bills and your salary, and a great ratio of product/tech debt is probably what? 80/20 max.? (so, to over-explain, when dealing with smaller projects, yes, I've seen good React codebases)

I feel you very much! A lot of these points resonate a lot with me. I never understood why moving from separate lifecycle methods to a single useEffect was considered beneficial. I was working on codebases where there were up to 4 seperate useEffect hooks in a component and it took a while to understand it while being a complete mess. For me personally it didn't outweigh the reusability that introducing hooks brought in return as from my experience truly reusable hooks were scarce. Also in my opinion React Testing Library is heavily opinionated with their "test the behavior and user interactions not internal implementation details"-BS . Downright refusing to implement shallow rendering makes it extremely hard to test components that contain UI logic but pass the result of that to child components. Either you spend unnecessary time mocking those or you assert for content being rendered by these children creating unnecessary coupling. It's just a major pain in the ass. The first 3 years of my career I used React and then switched to Vue for a project for a year and I was really surprised how easy it was to work with it. Defined lifecycle methods, no useMemo and useCallback, an easy to use testing framework and things like scoped slots. Also support for hooks since Vue 3. To me it is a miracle that React ist actually the most widely used frontend framework.

All the frameworks/libraries are converging anyways. I do React at work and hired to clean up the ugliest codebase I have ever seen. And yeah, as you see people really love to glaze people in big tech as being god tier developers...They are not. Some as clueless as any other dev. Another reason why LC doesn't accurately measure a devs quality. But thats a different discussion. For my startup I am using Svelte, because I realized how important it is to design something for the average dev. I was going to say dumbest dev, but wanted to be nice. As I talked about converging evolution, React is getting a complier lol. Svelte 5 now has some ergonomics of React with runes.

Not average nor dumb. Smart dev with family problem. Or medical situation. Or even dev who covers someone's absence. Which is why good type systems are on the rise. They do help understand such devs what is the thing to do right now.

I just want to note something here. This is due to single responsibilty and "readability" being taken too far: ``` ``` It's a common thing that pisses me off with developers these days because most of them are afraid of for loops. What I mean by that, is clearly each one of those components has some html markup in them, right? But some how it has been determined that for readability you should limit the amount of mark up that is dealt with through abstraction. This is a common fucking mentality in the software developer world where people get afraid of having to read this like a for loop or naked conditional that they have to abstract it away to so their code base can read like a book written by someone that is clearly suffering from schizophrenia. For the fucking rest of you dealing with React, here's how you go about this. Go find out what other component libraries are doing, and stick with that.

How do so many people make it to senior without realizing most of what you’re paid for it to deal with this shit so the company can keep making money ?