What is React, and when is the weight worth it?
The founder wanted a marketing site with one contact form. The agency delivered Next.js, React Server Components, a component library, and a build pipeline that needed its own README. Page load on a mid range Android phone: four seconds before the form was usable. The form worked. The stack was resume driven.
React is the default picture many founders carry for "modern front end." Components, state, effects, a build step, a client bundle that hydrates into interactive UI. That picture is accurate. It is also 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. My default: skip React until you can name an interactive surface that genuinely needs it. Plenty of successful products ship faster with thinner approaches. Plenty of dense dashboards still justify React. Match weight to interaction depth.
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. Types help large component trees survive refactors. They do not remove the need to download JavaScript.
The weight you pay
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.
Client state complexity. Rich UI pushes state into the browser: filters, optimistic updates, undo stacks, offline queues. Bugs migrate from server logs to reproduction steps involving click order.
SEO and first paint. 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 justifies 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 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: 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.
| 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 documented environment variables.
Decision signals
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.
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.
Users do not forgive slow software because the stack is modern. Tie deploys to Core Web Vitals the same way you tie deploys to error rates.
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.
Products can mix approaches. Marketing site static. App shell React. Admin HTMX. The failure mode to guard against is duplicating business rules across a React app and server templates.
Lessons
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.
What I would tell a founder: 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.
What I would not do again: let résumé signaling pick the front end before the interaction requirements exist.
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, founder of Kleto. We help teams choose React when interaction depth demands it, and reach for thinner patterns when speed and clarity matter more. Contact Kleto if that matches your stack.