As a backend-leaning developer, I value clarity and structural integrity in software. Frontend frameworks—React in particular—often feel like IKEA furniture. Quick to assemble, elegant at first glance, but flimsy underneath and easy to misuse.

IKEA and React: A Fitting Analogy

React makes UI building easy—much like IKEA simplifies furniture shopping. With a few components, some props, and a sprinkle of state, you can whip up a decent-looking interface. It’s modular, highly customizable, and well-documented.

But like IKEA furniture:

• The clean finish hides a maze of oddly named parts and screws.
• Skip the manual, and you’re one Allen wrench away from disaster.
• The final product often lacks the long-term solidity of something custom-built by a craftsman.

This isn’t to say React is bad — just like IKEA furniture isn’t bad. It solves a real problem: democratizing frontend development, giving people tools to build fast, with low friction. That’s a win in many cases.

But there’s a cost.

Abstraction Piled on Abstraction

React and similar “frameworks” push complexity forward. One of the most frustrating aspects of modern frontend frameworks is the excessive layering that exists solely to manage the chaos React invites. Hooks, effects, context, providers, memoization — the deeper you go, the more you feel like you’re juggling abstractions to cover the shortcomings of earlier abstractions.

In a typical React project, it’s common to:

• Use useEffect to fix what shouldn’t have broken in the first place.
• Reach for Redux or Zustand because context is awkward for state.
• Add caching libraries because your frontend is now handling business logic that used to live comfortably on the server.

It’s like building a desk and realizing halfway through that you need more screws, then needing a new tool to tighten the new screws, and then a shelf to store all those tools.

“Sugar Layers” for Developer Experience (DX)

• Tools like React, Next.js, Vite, and state libraries (Redux, Zustand, etc.) often exist to smooth over JavaScript’s weaknesses, not because they make systems more robust.
• These abstractions are designed for DX (developer experience) — to make coding feel better, even if it adds overhead, indirection, and performance cost.

But that DX comfort can mean:

• Poor separation of concerns
• Flimsy architectural layers
• Reliance on client-side logic where server-side would be safer and more testable

The Fragility Beneath the Simplicity

• Hooks promise functional purity and elegance — until you’re stuck debugging a stale closure or wrestling with useEffect dependencies.
• Component trees can grow into unreadable forests, where state and logic leak in unpredictable ways.
• Tooling overhead becomes a necessary evil — bundlers, linters, transpilers, state libraries, and routing mechanisms are practically mandatory to build a “real” app.

React encourages you to build with prefabs, but the internal skeleton — the core architecture — is your responsibility. And many developers, especially frontend-first ones, don’t have the training to do that well.

Separation of Concerns — React’s vs Backend’s

One of the biggest ironies in React’s design philosophy is to promote separation of concerns — however front-end and back-end’s definition of the term is subjective to the central theme of the concern.

In React:

• Components are the unit of separation.
• Logic, markup (JSX), and sometimes even styling (CSS-in-JS) are bundled together.
• The idea is to group related functionality, not layered responsibilities.

This is fundamentally different from backend architecture, where:

• Concerns are separated by layer — models, services, controllers, views.
• Code is organized by responsibility, not by visual output.
• The system is designed to scale across complexity and time, not just for developer ergonomics.

This difference leads to architectural conflict:

• In React, a single component might handle rendering, data fetching, state management, and even optimistic UI updates.
• From a backend mindset, this is a violation of proper boundaries — a breach of the Single Responsibility Principle, even if it’s “convenient.”

So while React encourages a form of separation of concerns, it often disrupts the more robust, layered concerns that backend systems rely on.

A Backend Developer’s Perspective

Coming from the backend world, I value:

• Separation of concerns: Coupled with DDD considerations to help with cohesion and maintenance.
• Well-defined services: Clear responsibilities that mirror business logic.
• Simplicity: No need to re-implement patterns that already work on the server unless there are deprecation risks.
• Stability: Don’t entrust crucial behaviour to brittle client-side code that varies by browser.

From this standpoint, frontend frameworks like React often feel like a way to sidestep good architecture in favour of rapid, shallow development. It shifts complexity to the client, sometimes unnecessarily.

The React ecosystem builds an illusion of robustness by layering libraries on top of a lightweight core:

• React Router for routing,
• Redux, Zustand, or Recoil for state,
• Next.js or Vite for rendering and bundling,
• and an endless buffet of component kits just to avoid CSS.

It feels like more effort is spent assembling the furniture than ensuring the building is structurally sound.

My Preferred Approach: Light Frontend, Heavy Backend

I believe in a lean frontend that focuses on display, interaction, and user experience — while delegating all real business logic, validation, and state to the backend.

• The frontend should not be the source of truth.
• It should not re-implement domain logic.
• It should not be trusted to handle side effects or critical data transformations.

React, in its flexibility, lets teams violate these principles — often without realizing it.

Frontend Frameworks and the Illusion of “Full-Stack”

There’s a growing trend of treating frontend developers as “full-stack” because they can plug into Firebase, use Next.js APIs, or wire up GraphQL calls. But in many cases, this is just pushing serious application logic into the UI, often without the architectural rigour needed for enterprise systems.

React enables this by making it too easy to build things that look right but behave poorly.

This democratization isn’t inherently bad — but as a backend developer, it feels like we’re compromising long-term stability for short-term convenience. Real-world systems benefit from a backend that acts as the system’s brain, not one that offloads decision-making to the browser.

React’s Creators Acknowledge This

Even react’s own creators warn against overusing it. Dan Abramov, one of React’s most influential voices, has openly said:

“React was not designed to be the foundation of your whole app. It’s a library for building user interfaces — not an application framework.”

And yet… most teams use React as if it’s a full-stack panacea.

This misuse isn’t just bad engineering — it reflects a deeper trend where frontend tooling tries to replace backend discipline. The result? Apps that feel modern but lack stability, security, or scalability.

So What’s the Alternative?

I’m not saying React is bad. It has its place. It’s fantastic for interactive dashboards, internal tools, and UI-heavy experiences.

But for enterprise-grade apps with deep business logic and complex domain models, I advocate for:

• Backend-first architecture: Let your server do the heavy lifting. Use a thin UI layer to display results and capture user input.
• Progressive enhancement: Don’t make your app fail just because JS fails.
• Simpler UIs: The more logic you move to the front, the harder it is to maintain — especially across browsers and devices.

A good test: If your React app needs a backend framework to simulate backend behaviour, maybe you should just… use the backend.

Final Thoughts: Build with Intention

IKEA is great — if you need a bookshelf fast. But if you’re building a skyscraper, you don’t want a thousand people with Allen wrenches and self-tapping screws figuring it out as they go.

React makes frontend development accessible and productive. That’s not a flaw — that’s a feature. But the ease of use shouldn’t mask its limitations.

For teams building software that needs to last — not just launch — it’s worth asking:

Are we assembling furniture… or are we constructing architecture?