Imagine a developer joins a new project . The app has three pages and a contact form. Simple enough, right? But the tech stack includes React, Redux, React Query, Zustand, Styled Components, TypeScript, Vite, Cypress, Storybook, and a custom design system. That's a lot of tools for a website that could have been built in a weekend.
If you've worked in web development for a while, this probably sounds familiar. We now have more tools than ever, but somewhere along the way, building websites became more complicated than it needs to be. This post looks at why that happens, what it costs, and how you can make smarter choices.
Why Are We Building Such Complicated Things?
There's even a term for it now: React fatigue. Developers who loved JavaScript frameworks are now asking, “Was all this complexity worth it?”
Years ago, building a website meant writing some HTML, adding a little JavaScript, and maybe using jQuery. Today, even a “simple” project can come with a build process, a state manager, dozens of packages, and a setup guide that takes days to get through.
The tools themselves aren't the problem. Most of them were built to solve real, hard problems . The issue is that we often use them even when we don't have those problems.
So how did we get here?
- Showing off on a resume: Some developers choose trendy tools because they look impressive, not because the project needs them.
- Following tutorials blindly : Most coding tutorials use feature-heavy setups. Beginners assume that's just how things are done.
- Starter templates include too much: Tools like Create React App come loaded with features. Most teams never remove what they don't use.
- Worrying about the future: “What if we need this feature later?” has been the excuse behind a lot of unnecessary setup.
What Does an Overcomplicated Stack Actually Cost You?
Complexity isn't just annoying. It has real business consequences, especially for any web development company that needs to deliver projects on time and within budget.
A setup that took six developers three months to configure is not an advantage. It's hidden debt that you'll keep paying for.
New team members take forever to get up to speed
When a new developer joins a project with 40+ packages and a custom build process, they spend their first few weeks just trying to understand how everything fits together. That's time they're not building features or fixing bugs.
Finding bugs becomes a guessing game
The more layers your app has, the harder it is to know where something went wrong. Is the bug in the component? The state manager? The data fetching layer? Simpler systems break in obvious ways, which actually makes them easier to fix.
Your website can end up slower
Here's something that surprises a lot of people: using a big framework doesn't make your website fast. Sending too much JavaScript to the browser, using too many rendering layers, and adding unnecessary packages can actually make your site slower. Performance experts keep coming back to the same advice: ship less code.
When Does Complexity Actually Make Sense?
This isn't about going back to writing everything from scratch. Big tools exist because some projects genuinely need them.
More complex setups make sense when:
- You're building something highly interactive, like a design tool, a dashboard, or a real-time app
- Multiple teams are working on the same product at the same time
- Your app has complex data that changes a lot and needs careful management
- You have the team size and experience to maintain that level of tooling
The right question isn't “Is this a good tool?” It's “Does this tool fix a problem we actually have right now?”
Good developers don't always use the most powerful tools. They use the most fitting ones. That's a different skill entirely.
How to Keep Things Simple Without Cutting Corners
Whether you work alone or at a web development company, keeping complexity under control is mostly about habits and honest decision-making.
Start by listing what you actually need
Before picking a framework, write down what the project requires. A content website with a few pages might be better served by Astro, plain HTML, or a lightweight tool like Eleventy. Not everything needs to be a React app.
Choose tools your team already knows well
There's real value in using familiar technology. Your team can move faster, debug more easily, and find answers online without much trouble. A new tool that launched last month might be exciting, but the hidden cost of learning it during a live project is often higher than expected.
Wait until complexity earns its place
You don't need a state management library until passing data between components becomes genuinely messy. You don't need a micro-frontend setup until teams are actually blocking each other. Many smart engineering decisions are really just decisions not to build something before it's needed.
Clean up your dependencies from time to time
Check what packages your project is using. You'll often find tools nobody added on purpose, packages that solve problems you no longer have, or three different libraries doing the same job. Keeping your dependencies lean is one of the simplest ways to keep a project healthy.
Things Are Starting to Shift
The web development world is slowly waking up to this problem. HTMX became popular by letting HTML do more without needing much JavaScript. Svelte and SolidJS gained fans by removing the need for a heavy runtime. Astro won a following with its “zero JavaScript by default” approach because it named something developers were already feeling.
Even the React team's push toward Server Components is, in part, an admission that sending all that JavaScript to the browser was never the ideal solution. The tools are improving. But better tools alone won't fix things if teams keep reaching for complexity out of habit or insecurity.
What This Means for You and Your Team
If you work at or run a web development company, this conversation isn't just about code. It's about how you run projects. Complicated stacks are harder to estimate, harder to hand off, and harder to explain to clients. They don't see your build pipeline. They see whether the project shipped on time.
The developers who will stand out are the ones who can look at a project and say: “Here's the simplest setup that gets this done well.” That kind of clear thinking is rarer than you'd expect, and it's worth a lot.
Complexity should only show up when the project truly needs it, not as a default. The web was built to be open, fast, and easy to use. That's still worth building toward.
The real question was never “React or no React.” It was always: what does this project actually need, and are we honest enough to build just that?
