![](./attachments/00016-2479171298.jpg) I'm no coding genius, but I've got the chops and experience, and that's why I'm feeling a tad emotional as I write this. I started with RoR web-apps almost a decade ago with the old-fashioned MVC style of web development. I soon moved to Go and React, with JSON APIs communicating between the two. I started using React around 2016, just before flux/redux started coming in. It was promised as "the V in MVC". I was so excited to learn this new view library from Facebook. Angular 1.4 was still pretty big so it was nice to see a competitor come up. While I owe a lot of my career to the above technologies (and more), I've recently had an experience that really depressed me, and made me realise the terrible state of the front-end development industry. I was refactoring an app on my own that was developed by an outsourced programmer that went MIA. It was written in the stack that I architected. Go and React. Postgres. ConnectRPC. React component library using Tailwind. Jotai for state management. All of the things that I've been with for years. Refactoring this thing was an absolute nightmare. After several weekends in this hellhole of navigating complex, decoupled software legos, I decided to take a step back, take a deep breath and figure out why it was such an unpleasant experience. Today, I'm here to talk about React and the frustrations that have emerged in the wake of what seems like a cargo cult. React has grown far beyond its original promise, and it's causing more harm than good to the software engineering industry. ## React is overengineered Another project popular in the OSS/Devops space is Kubernetes. Often you'd see a lot of articles saying "You are not Google", or "You don't have Google scale problems", as a counter to startups going all in on Kubernetes. There's a similar problem with React but much less visible. - You are not Facebook. - You do not have Facebook level problems. The complexity that comes with React is beyond the needs of the majority of projects. Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running. Why? Why are we using APPLICATION frameworks to build websites? If you're just building something CRUD-dy, or even something live and pushy (websockets, chat, games). Heck, even heavy media stuff like video streaming doesn't need an application view framework. Notice I'm just talking about the react-dom stuff. We haven't even gotten into state management, stupid component factory patterns, HOCs or routing yet. ## React is not fast React was meant to be a way to provide snappy page loads and UX. Actually achieving this, on the other hand, is a little more involved than you think. The idea is that if your servers are overloaded, your React app will continue to function fast because the rendering happens on the client side. But realistically, it'll be dog-slow anyway because all of the requests still have to do roundtrips to the server. Or that you have to handle failed calls, retries, timeouts, or handling an entire failed state. Not to mention the "dumb" API approach backends do now result in a lot of over-fetching from React apps, which compounds the problem! Time to first load is also poor as you're pushing large bundles down the wire, but with tree shaking and other techniques it has gotten a lot better over the years. ## React's talent pool is diluted React is the automatic target for a lot of newbies. They jump straight into webdev, learn some HTML/CSS and eventually work their way towards React for employability. This dilutes the talent pool and with it comes pros and cons. You spend so much more time sifting through junk candidates, but at least you have candidates. React devs are easy to find but good ones are not. While I'm whinging a lot about React, its still an impressive piece of technology. Its also, however, very complex and difficult to use correctly. Finding a dev who actually groks the gap between useEffect and useMemo, error boundaries, hook based fetching or my (un)favourite, authentication, is difficult. On the flipside, I guess a guy who is good at React will end up being a pretty dang good developer no matter what he or she works with. ## React should stay in its lane As the ecosystem grew and grew, new tools came up to handle issues FE devs run into often. The one that comes to mind immediately is routing. We're replacing the browser's router with a react router, hooking into browser history, messing up deep linking, and creating a whole stack of things to learn. Another is Next.js, the ultimate end game for react. Next.js attempts to replace pretty much everything, including server functions, authentication and even static pages! Its a kitchen sink framework that makes pure react developers happy, but its much too much of a round peg/square hole situation. ## React suffers churn As mentioned before, in the early days the amount of developments in the React world were absolutely insane. These days (after the introduction of hooks), things seemed to have settled down a bit. Then I open up my browser and suddenly learn about Recoil/Jotai/Zustand, and then sigh quietly in defeat as I pull up the documentation. Its all a bit overwhelming, and when you're deep in it, its hard to miss the forest for the trees. ...Why is there always a new way of doing things? ...Why am I learning the same thing but in a different way? ...Why was the "old" way inferior? ...Why change at all? Browsers don't move THAT quickly. ## Conclusion Honestly? The front-end community needs to chill out a bit. The majority of work done on the FE doesn't need to be that complicated. You're basically just rendering state after all. While I appreciate the intricacies of two-way binding with forms, and how to make everything stateless as possible, or the separation of state from UI, or "hyper-componentisation", I think we all really need to just step back and ask "why?". Why are we torturing ourselves with endless churn, and telling ourselves that its for the better?