What is React, and when is the weight worth it?
React is the default picture many founders carry for "modern front end." Components, state, effects, a build step, and a client bundle that hydrates into interactive UI. That picture is accurate and incomplete. React is a library for describing UI as functions of data. It is also a commitment to client side JavaScript weight, tooling complexity, and a hiring market that assumes React on every résumé.
The question is not whether React is good. The question is whether your product needs enough client side interactivity that the bundle, the build pipeline, and the mental model pay for themselves. Plenty of successful products answer no and ship faster with thinner approaches. Plenty of others live inside complex dashboards where React remains the pragmatic choice.
What React actually is
React lets you build interfaces from reusable components. When data changes, React reconciles a virtual representation of the UI and updates the DOM efficiently. State lives in components or external stores. Side effects fetch data, subscribe to websockets, and talk to browser APIs.
React is not a full framework by itself. Routing, data loading, forms, and styling usually come from adjacent libraries or meta frameworks like Next.js. That modularity helped React spread. It also means every React project is a custom stack unless you adopt strong conventions.
TypeScript pairs naturally with React for typed props and hooks. TypeScript for small teams explains the broader case. On the client, types help large component trees survive refactors. They do not remove the need to download JavaScript.
The weight you pay
Founders should name the costs explicitly instead of treating them as background noise.
Bundle size and parse time. Users download React plus your application code before interacting. Mobile networks and low end devices feel this cost. Performance work becomes a line item.
Build tooling. JSX or TSX requires transpilation. Local dev expects a bundler. CI must produce artifacts reliably. Simplicity on the server does not automatically transfer to the client.
Client state complexity. Rich UI pushes state into the browser: filters, optimistic updates, undo stacks, offline queues. State machines grow. Bugs migrate from server logs to reproduction steps involving click order.
SEO and first paint considerations. Server rendered React can mitigate blank screens, but setup adds ceremony compared to HTML forward approaches.
Ecosystem churn. Patterns shift. Meta frameworks evolve. Upgrades consume sprint capacity even when features stand still.
React's benefit is organizing complexity once complexity exists. If your product never reaches that threshold, you prepaid for capacity you will not use this year.
Where React earns its keep
React tends to justify itself when the UI is the product surface, not a thin skin over server rendered forms.
Dense interactive dashboards. Live charts, drag and drop layouts, multi pane editors, and tables with inline editing need fine grained updates. React's component model keeps those surfaces maintainable.
Long lived sessions with heavy client state. Project management tools, design canvases, and collaborative whiteboards keep users in one tab for hours. Client side state reduces round trips.
Design systems at scale. Shared component libraries with variants, accessibility baked in, and Storybook workflows map cleanly to React teams.
Mobile web parity expectations. Users expect app like transitions. React plus careful performance work can approximate that experience in the browser.
Large front end hiring pools. If your roadmap assumes several front end engineers, React familiarity reduces recruiting friction.
In these cases, the bundle is tuition for velocity and talent access. The mistake is paying tuition for a marketing site with one contact form.
Where lighter approaches win
Many SMB products are forms, tables, notifications, and admin screens backed by Postgres. That shape favors server forward patterns.
HTMX and progressive enhancement. HTML arrives from the server. Small attributes request partial updates. JavaScript stays thin. See How do you connect a simple front end to a typed API? for pairing thin UI with typed backends.
Server rendered templates with sprinkles. Most pages static. A few islands of interactivity via web components or minimal scripts.
Multi page applications with typed APIs. Full page navigations are fine for internal tools. Users prefer correct data over SPA transitions.
The pattern across these options: keep authoritative state on the server, keep client code proportional to actual interaction depth. Product engineering versus just development argues for matching tooling to outcomes, not résumés.
React in a typed product stack
React does not replace a data strategy. It consumes APIs shaped elsewhere. When types flow from the database to the client, React components import the same DTOs server templates use. Drift still hurts; it just hurts inside JSX instead of HTML.
Runtime choice on the server (Bun versus Node) is largely independent. React cares about what the browser downloads, not which runtime generated the JSON.
Common stack for React heavy products:
| Layer | Role |
|---|---|
| Postgres | Source of truth |
| Typed API | Stable shapes for clients |
| React SPA or meta framework | Interactive UI |
| CDN / static host | Serves built assets |
Preview environments should serve the same API contracts production uses. Client bundles should build in CI with the same environment variables documented for production, minus secrets.
Decision signals for founders
Ask these before mandating React repo wide.
How many distinct interactive surfaces exist? One admin table suggests thin UI. Five linked dashboards suggest React or similar.
How often do non engineers need to edit content? Marketing pages change weekly. CMS or markdown pipelines often beat SPA complexity.
What devices matter? Field users on older phones punish large bundles. Desk bound power users tolerate more.
What is the cost of a wrong interaction? Financial approvals and medical workflows need clarity and auditability. Fancy transitions rarely help.
Can you prototype the risky screen in isolation? Build the hardest UI first in a spike. If the spike drowns in state management, React may be appropriate. If the spike is a form post, reconsider.
Two or more answers pointing toward rich client interaction favor React with strict performance budgets. Two or more pointing toward document centric workflows favor server forward HTML.
Performance budgets are product decisions
If you choose React, treat performance as feature work.
Set bundle size ceilings per route. Measure largest contentful paint on real devices. Lazy load routes that are not on the critical path. Prefer server components or SSR where your meta framework supports them without turning every page into an architecture debate.
Users do not forgive slow software because the stack is modern. Founders should ask for dashboards that tie deploys to Core Web Vitals the same way they tie deploys to error rates.
Hiring and maintenance reality
React expertise is common. So is outdated React expertise. Interview for how candidates manage state, accessibility, and testing, not whether they recite hook rules from memory.
Maintenance includes dependency upgrades, breaking changes in routers, and security patches in transitive packages. Budget that work every quarter even when product managers see no visible features. Hidden front end debt surfaces as "we cannot ship this small change without a rewrite."
Coexistence strategies
Products can mix approaches. Marketing site static. App shell React. Admin HTMX. The key is boundary clarity: which routes load which assets, which teams own which surfaces, and which API contracts stay shared. Accidental duplication of business rules across a React app and server templates is the failure mode to guard against.
The larger point
React became popular because it tamed complex client UI better than ad hoc jQuery soup. It remains popular because hiring markets and component ecosystems compound. Neither history obligates your product to need it today.
Founders win when they match client weight to interaction depth. Pay for React when the UI is genuinely stateful, collaborative, and dense. Skip it when the product is mostly honest CRUD over a typed API with occasional sprinkles of JavaScript.
The goal is not the lightest possible stack for bragging rights. The goal is the lightest stack that still lets your team ship correct behavior under real users. React is sometimes that stack. It is never free.
Work with Kleto
I am James Cowan, a product engineer and the founder of Kleto. Kleto is a product engineering agency that ships production software from strategy through handoff. We help teams choose React when the interaction depth demands it, and reach for thinner patterns when speed and clarity matter more. If that matches your stack, contact Kleto and we will scope a sensible first step.