Next.js or plain React with Vite — how do you decide?

By whether the pages need to be indexable or personalised on the server. If public pages must rank, or content must render before JavaScript runs, Next.js earns its complexity. If the whole product sits behind a login and is rendered per user anyway, a Vite single-page app against a clean API is faster to build, easier to reason about, and cheaper to host. We ask what the crawler and the first-time visitor need to see, then pick.

We just need a website. Is React overkill?

Usually, yes. For a site of content pages that change when an editor changes them, a static site generator or server-rendered templates give better load and interaction numbers with far less machinery, and your marketing team can edit without a deploy pipeline. We will say so. React starts making sense when the site is also the front door to an application, or when logged-in behaviour and marketing pages share a design system.

Can React go into our existing Django, Laravel, or .NET application without a rewrite?

Yes, and it is often the right move. React mounts into a container element on a page your server still renders, so one screen — the reporting view, the scheduling grid, whatever hurts most — becomes a React island while the rest of the application continues unchanged. You get a working improvement this quarter and a route to migrating further only if the value keeps showing up.

A client-only React app can, because content that only exists after JavaScript executes is indexed slowly and unevenly, and any crawler or preview bot that does not execute scripts sees an empty shell. Server rendering removes the problem: HTML arrives complete, with metadata, canonical tags, and structured data emitted on the server. That is a rendering-strategy decision made at the start, not a plugin you add later.

After handover, can our own team maintain it?

That question should shape the technology choice, not follow it. If your engineers are React-fluent, we hand over a typed codebase, a component library, CI checks, and the upgrade path. If your team is entirely backend, we will tell you honestly that a React frontend adds a toolchain they will have to own, and discuss whether server-rendered templates or a smaller React surface is the better long-term answer for you.

React Development

React is the default UI layer for most product work we do, and it is a genuinely good default — component composition, a large hiring pool, and an ecosystem that has already solved the boring problems. It is also over-applied. Half the value we add on a React engagement is deciding which parts of your product actually need it.

Talk about your project See what we build

What React is

React is an open-source JavaScript library from Meta for building user interfaces out of components. You describe what the UI should look like for a given state, and React works out the minimum set of DOM changes needed to get there. On its own it is only the view layer — routing, data fetching, and server rendering come from the surrounding stack, most commonly Next.js, Remix/React Router, or a Vite single-page setup.

Prefer the short definition? Read the React glossary entry.

The honest version

When React is the right choice — and when it is not

Choosing a technology because it is popular is how projects end up expensive. Here is where we would pick it, and where we would tell you not to.

Good fit

Products with dense, stateful interaction: Multi-step flows with server round-trips, filterable tables, optimistic updates, live-updating dashboards. Once a screen has more than a handful of interdependent states, the alternative to a component model is hand-written DOM patching — which is what React was invented to replace.
One design system across many screens or several products: Composition plus TypeScript props means a button, a data table, or a form field is defined once and typechecked at every call site. A change to focus states or error styling propagates through the build rather than through a checklist.
A web app and a mobile app built by the same team: React Native shares the mental model, the TypeScript domain types, the Zod validation schemas, and often the API client. Two products, one set of engineers — a real cost argument for a founding team, not a stylistic one.
Long-lived software you intend to staff for years: Hiring is a legitimate architectural input. React is among the easiest frontend skills to hire for in Pune, elsewhere in India, and remotely. Choosing a more elegant but niche framework can mean a six-month search when your one frontend engineer leaves.
Modernising a legacy frontend without stopping delivery: React mounts into an existing server-rendered page as an island. You can replace the worst screen in a fifteen-year-old application this quarter, keep everything else running, and avoid the rewrite that eats two years.

We would choose something else

A marketing site, blog, or documentation set: For pages whose content changes when an editor changes it — not when a user clicks — a React app ships tens of kilobytes of framework JavaScript, hydrates a tree, and re-derives markup the server could have sent finished. Astro, Eleventy, Hugo, or plain Django/Laravel templates give better LCP and INP with a fraction of the moving parts. If we build your brochure site in Next.js it should be because you also have a product in the same repo, not because React was on the brief.
Back-office CRUD where your only engineers are backend engineers: A React frontend forces a JSON API that would not otherwise exist, a second type system, a second build pipeline, a second deploy target, and a second place to get authorisation wrong. A Rails, Django, or Laravel app with server-rendered partials and htmx or Alpine for the interactive bits does the same job in one language. This is a case where we would talk you out of React — the deciding factor is who maintains it on the Monday after we leave.
Users on entry-level Android phones and intermittent mobile data: Parse and execute time is not the same on a Rs 8,000 handset as on a MacBook. Framework JavaScript plus a router plus a state library plus a component library is real main-thread time before anything renders, and a dropped connection mid-hydration leaves a page that looks ready but ignores taps. Progressively enhanced server HTML degrades honestly. This matters most for tier-2 and tier-3 consumer reach, and it is a product decision, not a tuning exercise.
Canvas, WebGL, spreadsheet grids, and high-frequency rendering: When tens of thousands of cells or sixty-frames-per-second scene updates are in play, reconciliation stops earning its keep and teams end up bypassing React with refs, memo walls, and imperative draw calls — React in name only, with all of its overhead and none of its clarity. Render to canvas directly, or use a fine-grained reactive framework like Solid or Svelte where an update touches one binding instead of re-running component functions.
When server rendering is required but you cannot run Node in production: React SSR needs a JavaScript runtime in your production environment. If your operations team runs only JVM or .NET workloads, has no appetite for a Node process to patch and monitor, and the pages must be indexable, the honest options are a static export with no per-request personalisation, or server-rendered templates in the stack your team already operates.

In practice

What we build with React

SaaS application frontends: multi-tenant dashboards, role-aware navigation, entitlement and billing screens wired to Stripe or Razorpay, and admin surfaces that internal teams use daily.
Design systems shipped as a versioned component library — design tokens, headless primitives with real keyboard and screen-reader behaviour, Storybook, and visual regression in CI so a padding change doesn't quietly break forty screens.
Next.js App Router builds where marketing pages are server-rendered and cached at the edge while the authenticated product shell is client-side, in one codebase and one deployment.
Regulated customer-facing UIs — patient portals, payment and KYC flows — where session timeout, PII masking in the DOM and logs, and idempotent submit behaviour are treated as frontend responsibilities, not backend ones.
Incremental React adoption inside an existing Django, Laravel, Rails, or .NET application: one screen at a time, mounted as islands into pages the server still renders, with no big-bang rewrite.

Positions

Decisions we have already made

Defaults we start from. They are arguable — but they are argued, not assumed, and we will change them for a good reason.

Rendering strategy: Server-first where the page is public, client-first where it is behind a login. Public routes use React Server Components in the Next.js App Router so the crawler and the first paint get finished HTML. An authenticated dashboard that is personalised on every request gains little from SSR and pays for it in cold starts and cache complexity — there we are happy to ship a Vite single-page app against a plain API. We do not put a private admin panel through server rendering to satisfy a diagram.
State management: No global store by default. Server data belongs in TanStack Query or in Server Components with server actions; shareable UI state (filters, tabs, pagination) belongs in the URL search params so a link reproduces the screen; form state belongs in the form. Zustand or Redux only for state the client genuinely owns — a document being edited, a live collaboration session, an offline queue. Most problems attributed to Redux are cache-invalidation problems wearing a costume.
API contract and data access: REST with an OpenAPI spec, and TypeScript clients generated from it, so a backend change breaks the frontend build rather than production. GraphQL when several clients with genuinely different data shapes justify the server-side cost, not as a default. On the server side we use Drizzle or hand-written SQL where the query shape matters and Prisma where a team values migration ergonomics more — and we never hide a hot PostgreSQL path behind an ORM we cannot read the plan for.
Deployment target and TypeScript settings: Vercel when the developer experience is worth the bill and there is no residency constraint. Otherwise the same Next.js app runs as a container on ECS Fargate or Cloud Run behind CloudFront, or inside your own AWS or Azure account in an India region where DPDP Act or client policy requires it. We keep platform-only primitives out of the application code so that stays a reversible choice. TypeScript runs in strict mode from the first commit; retrofitting strictness later is a project of its own.

Architecture

Things worth getting right early

The client is never the source of truth: Validation schemas are shared between client and server so the user gets instant feedback, but the server re-validates every payload as if the client were hostile — because it can be. Authorisation is enforced in the API and in row-level policy, never by hiding a button. A React app is a rendering of state the server owns; anything you can only see in DevTools is not a security boundary.
Caching and revalidation decided at design time: Which routes are static, which are dynamic per request, which stream behind Suspense, and what invalidates each cache tag — these get written down before the first screen is built. Retrofitting a cache strategy after a stale-data incident means auditing every fetch in the codebase. Where a page mixes public and per-user content, we split it at the component boundary rather than downgrading the whole route to dynamic.
Interaction latency is budgeted, not hoped for: React applications rarely fail on first paint; they fail on INP, when a click waits behind a long task caused by over-eager hydration, a date library pulled in whole, or a context provider re-rendering half the tree. We set a per-route JavaScript budget that fails the CI build when crossed, profile with the React Profiler and real-device traces rather than a laptop, and treat a regression as a bug with a ticket.
Built to stay upgradeable: Dependencies are pinned with automated update PRs and a test suite that makes accepting them safe. We avoid patterns already deprecated in React 19, keep component libraries swappable behind our own primitives, and document the upgrade path. The frontends that become expensive are the ones nobody dared to update for three years — that outcome is set by decisions made in the first month.

Around it

What React usually sits next to

Next.js
The framework we most often put around React — routing, Server Components, caching, and a production build we do not have to assemble ourselves.
TypeScript
Non-negotiable on anything long-lived. Props, API responses, and domain models are typed end to end so a contract change fails the build, not the customer.
React Native
When the same product needs iOS and Android, the component model and the domain types carry across instead of being rewritten twice.
Node.js
The runtime behind server rendering, server actions, and the build toolchain. Choosing React means agreeing to operate a Node process somewhere.
GraphQL
Worth the server complexity when web, mobile, and partner clients need genuinely different slices of the same graph — with typed documents on the React side.
WebSocket
For dashboards, chat, and collaborative editing where polling is the wrong shape and updates must arrive as they happen.

Questions

Common questions about React

Next.js or plain React with Vite — how do you decide?
By whether the pages need to be indexable or personalised on the server. If public pages must rank, or content must render before JavaScript runs, Next.js earns its complexity. If the whole product sits behind a login and is rendered per user anyway, a Vite single-page app against a clean API is faster to build, easier to reason about, and cheaper to host. We ask what the crawler and the first-time visitor need to see, then pick.
We just need a website. Is React overkill?
Usually, yes. For a site of content pages that change when an editor changes them, a static site generator or server-rendered templates give better load and interaction numbers with far less machinery, and your marketing team can edit without a deploy pipeline. We will say so. React starts making sense when the site is also the front door to an application, or when logged-in behaviour and marketing pages share a design system.
Can React go into our existing Django, Laravel, or .NET application without a rewrite?
Yes, and it is often the right move. React mounts into a container element on a page your server still renders, so one screen — the reporting view, the scheduling grid, whatever hurts most — becomes a React island while the rest of the application continues unchanged. You get a working improvement this quarter and a route to migrating further only if the value keeps showing up.
Does React hurt SEO?
A client-only React app can, because content that only exists after JavaScript executes is indexed slowly and unevenly, and any crawler or preview bot that does not execute scripts sees an empty shell. Server rendering removes the problem: HTML arrives complete, with metadata, canonical tags, and structured data emitted on the server. That is a rendering-strategy decision made at the start, not a plugin you add later.
After handover, can our own team maintain it?
That question should shape the technology choice, not follow it. If your engineers are React-fluent, we hand over a typed codebase, a component library, CI checks, and the upgrade path. If your team is entirely backend, we will tell you honestly that a React frontend adds a toolchain they will have to own, and discuss whether server-rendered templates or a smaller React surface is the better long-term answer for you.

Services that use React

Where it lands

Not sure React is the right call?

Send us the screens you have in mind and who will maintain them after launch. We will tell you which parts genuinely need React, which are better served by server-rendered pages, and what that means for cost and hiring — before anyone writes a component. Small focused pieces of work start around Rs 25,000; product builds are scoped after that conversation.

Talk to TantraDev All technologies