React
Still our default. It has to re-earn that on every build.
We have shipped React 18 and 19 on eight-plus production products, and picked Vue over it twice. This is what keeps it the default, and what it costs a small team.
The verdict
For a product team of a normal size, React is still the right default frontend library, because its hiring pool and component ecosystem outweigh its state-management churn. Pick something else when the app is small and static enough that a lighter framework ships it faster.
We have shipped it on ZhoopZhoop, Trading CoPilot, and ExtraaJe, among others, across React 18 and 19. It is not a default we stopped questioning. Two builds went to Vue instead, because a smaller reactive model fit the team and the app better than React's component tree.
The cost of staying with React is not in the library itself. It is in the ecosystem around it: which state manager, which data-fetching layer, and how much server-component complexity a small team can absorb.
In short
5 things that decide this
- 01React's component model and hiring pool make it the safer default for most product teams, not a technical edge over its alternatives.
- 02State management has no settled answer. We have used TanStack Query and Zustand together on one build and plain context on another, and picking wrong costs a rewrite later.
- 03The split between server and client components adds a real decision to every new file: where does this code run, and what does that decide about what it can import.
- 04We chose Vue over React on two builds where the app was smaller and a simpler reactive model shipped it faster with less boilerplate.
- 05React Native lets a React team reach mobile without learning a second framework, which is why ExtraaJe shares one team across its web dashboard and its app.
For someone comparing frontend libraries
React is a JavaScript library for building user interfaces out of components. A component is a small, reusable piece of UI that manages its own state and re-renders when that state changes. React does not ship routing, data fetching, or a build tool. Those come from a surrounding framework, most often Next.js, or from libraries you choose yourself.
That gap is the whole trade-off. A team gets to pick the exact router, state layer and styling approach a product needs. It also has to make every one of those choices instead of inheriting one opinion.
Where it stands
Good at
- The largest hiring pool of any frontend library, which matters more than any framework feature once a client needs to grow or hand off a team.
- A component model that scales from a small dashboard to a large product without a rewrite, because the unit of composition never changes.
- React Native reuses the same component thinking on mobile, so ExtraaJe's web and app teams share one mental model instead of two.
- The largest library ecosystem for anything specific: charting, drag-and-drop, forms. Someone has usually solved the problem already.
Weak at
- State management has cycled through Redux, Context, Zustand, Jotai and TanStack Query inside our own project history, with no single winner. A junior team can burn real time picking one and then have to unwind it.
- The server-component split, where React 19 code decides per file whether it runs on the server or the client, adds a decision that older React code never had to make. Import a client-only library into a server component and the build fails in a way that reads unrelated to the actual mistake.
- React itself gives no routing or data-fetching opinion, so two teams building similar products in React can end up with almost no shared code between them.
- Re-render performance is opt-in, not automatic. A component tree that was not built with memoisation in mind can re-render far more than it needs to, and the fix is usually a structural change, not a one-line patch.
What we run it on, and when we don't
ZhoopZhoop is a collision-shop platform with a live call and appointment board. It runs React 19 with Vite, TanStack Query for the data layer, and Zustand for local state. Trading CoPilot, an alerts and execution dashboard, pairs React with FastAPI and Supabase, where most state is a live feed rather than local UI state. ExtraaJe runs React on its web dashboard and React Native on its employee mobile app, off one Supabase backend.
We have also shipped two products in Vue rather than React. Both were smaller, form-and-record-shaped products, where Vue's built-in reactivity and single-file components meant less code and fewer libraries to pick. React's advantage grows with the size and complexity of the app. Below a certain size, that advantage does not pay for its own setup cost.
- App shapeLive dashboard, many custom states, versus mostly forms and CRUD screens.
- Team sizeLarger team benefits from React's bigger hiring pool and library choice.
- Mobile reachNeeds a native app too? React Native reuses the team.
- DecisionReact by default. Vue when the app is small and the setup cost outweighs the ecosystem.
The two Vue builds were both smaller, form-heavy products where React's ecosystem had nothing to offer that Vue's defaults did not already cover.
Common questions
01Is React still the right choice in 2026?
For most product teams, yes. Its hiring pool and library ecosystem are still the largest of any frontend option. That matters more over a product's life than any single feature. It stops being the right choice on a small, mostly form-and-record app, where a lighter framework ships the same result with less setup.
02What state management should a new React project use?
There is no single right answer, which is itself the risk. On data-heavy dashboards, we pair a server-state library like TanStack Query with a small client-state store like Zustand. Simpler apps get plain context. The mistake is picking a heavy state library before knowing whether the app needs one.
03Does React lock a team into Next.js?
No. React is a UI library on its own. Next.js is one framework built around it, and Vite is a common alternative for apps that do not need server rendering. ZhoopZhoop runs React with Vite rather than Next.js, because it did not need server-rendered pages.
04When would you pick Vue over React?
Pick Vue on a smaller product shaped mostly around forms and records rather than a live, stateful dashboard. Its built-in reactivity and single-file components mean fewer libraries to choose. That is a real saving on a small team. We have shipped two products this way.
