DEV Community: Amrendra kumar

Improving Your React Code by Avoiding Hooks Mistakes

Amrendra kumar — Tue, 30 Jun 2026 09:21:14 +0000

Quick Summary:

In 2026, planning to design a website or apps is quite easier. One more thing is came which named as React hooks, that also discussed in this Blog, Mainly react hooks are came from three sources like as: missing dependencies from component also breaks render component for 'useffect'.

Most teams reach for useCallback and useMemo before diagnosing the actual re-render cause, which adds complexity without fixing the bug. Fix the dependency array first, profile second, memoize last.

After this, you will be able to triage a Hooks-related bug report without guessing, and decide whether useMemo is solving a real problem or just adding noise.

For deeper patterns on component design, see these React architecture patterns.

What Actually Breaks: The 3 Hook Mistakes That Cause Production Bugs

These three are responsible for the majority of Hooks bugs that make it past code review. Each one looks correct at a glance and only breaks under specific render conditions.

Stale closures from missing dependencies

A closure inside useEffect, useCallback, or useMemo captures variables at the time the function was created, not at call time. Omit a dependency and the callback keeps using the value from the render where it was defined.

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // always logs 0 — stale closure
    }, 1000);
    return () => clearInterval(id);
  }, []); // missing 'count' dependency

  return <button onClick={() => setCount((c) => c + 1)}>Increment</button>;
}

The fix is not to silence the lint rule. Add count to the dependency array, or switch to the functional update form (setCount(c => c + 1)) if the effect doesn't actually need to read count directly. As per the React docs (react.dev, 2025), the dependency array exists specifically to keep effect callbacks synchronized with the latest render's values.

Conditional hook calls breaking render order

React tracks hook state by call order, not by name. A hook called behind a condition shifts every hook after it on the next render where the condition changes.

// Wrong — breaks hook order when `id` becomes empty
function Game({ id }) {
  if (!id) return <p>Select a game</p>;
  const [game, setGame] = useState(null);
  useEffect(() => { /* fetch game */ }, [id]);
  return <GameView game={game} />;
}

// Correct — hooks run unconditionally, logic moves after
function Game({ id }) {
  const [game, setGame] = useState(null);
  useEffect(() => {
    if (!id) return;
    /* fetch game */
  }, [id]);
  if (!id) return <p>Select a game</p>;
  return <GameView game={game} />;
}

Run eslint-plugin-react-hooks (npmjs.com) in CI, not just locally. This class of bug often passes a quick manual test and fails only under specific prop transitions in production.

Unbounded useEffect re-runs without cleanup

Every useEffect that sets a timer, subscription, or listener needs a cleanup function. Skip it and every re-run stacks another active subscription on top of the last one.

useEffect(() => {
  const timer = setTimeout(() => doSomething(), 1000);
  return () => clearTimeout(timer); // prevents leaks and duplicate timers
}, [doSomething]);

In codebases without this pattern enforced, a single screen with three subscribing effects can leak dozens of listeners after a few minutes of normal navigation. The symptom is rarely a crash — it's degraded performance that only shows up after the app has been open a while, which is why it survives code review.

useCallback vs useMemo vs Doing Nothing

Most Hooks guides tell you to memoize without explaining when memoization is wasted work. React re-runs a component function on every render regardless of memoization; useCallback and useMemo only stop downstream re-renders or recomputation, and they cost a comparison check every render to do it.

Situation	Use	Why
Function passed to a `React.memo` child	`useCallback`	Without it, a new function reference breaks the child's prop equality check every render
Expensive computation (sort, filter, transform) on large data	`useMemo`	Skips recomputation when inputs are unchanged
Function or value used only inside the same component	Neither	No downstream consumer benefits from referential stability; the memoization check costs more than the work it saves
Object or array literal passed as a prop	`useMemo` (or restructure props)	Object literals are a new reference every render, defeating `React.memo` on the receiving component
Simple inline handler with no memoized child	Neither	Premature memoization here is dead weight

In large React codebases, unnecessary useMemo/useCallback calls are one of the more common causes of code review churn — they signal a performance concern that was never measured, and they make diffs harder to read for no measurable gain.

How to Diagnose a Re-render Problem Before You Memoize Anything

Don't memoize speculatively. Open React DevTools, enable the Profiler tab, and record an interaction that feels slow. The flame graph shows which components re-rendered and why DevTools labels the trigger as props, state, context, or parent re-render.

If the trigger is "parent re-rendered" and the child's props are unchanged primitives, wrap the child in React.memo first. Only add useCallback/useMemo upstream if the Profiler still shows the child re-rendering after that change that's the signal a new reference is breaking the memo check, not a guess.

This sequence (profile, then memo the child, then memoize the source if needed) catches the actual bottleneck instead of scattering useCallback across a component tree based on intuition. Teams that skip the Profiler step typically end up memoizing the wrong layer and still ship the original slowdown.

Do React 19's Compiler and Actions Change These Mistakes?

The React Compiler (react.dev, 2025) auto-memoizes components and values at build time, which removes the need for manual useCallback/useMemo in most cases when the compiler is enabled. It does not fix stale closures or conditional hook calls those are still runtime correctness bugs the compiler can't infer away.

useActionState and form Actions, introduced in React 19, replace a chunk of the manual useState + useEffect pattern previously used for form submission and pending states, which removes one entire category of dependency-array mistakes by removing the effect itself. The mistakes in this guide are not obsolete; they shift toward correctness (closures, hook order) rather than performance, since the compiler increasingly handles the performance side.

FAQ

1. What is the most common mistake with useEffect?

Omitting a dependency that the callback actually reads, which produces a stale closure. The effect keeps using the value from whichever render it was created in, not the latest one, until something forces a re-run with the correct dependency array.

2. Why does my useEffect cause an infinite loop?

Usually an object or array literal in the dependency array, or a state setter inside the effect that updates a value the effect also depends on. Each render creates a new reference, which the dependency comparison treats as changed, triggering another run.

3. Can I call a Hook inside a condition or loop?

No. React tracks hook state by call order across renders, and a conditional call shifts that order whenever the condition changes. Call hooks unconditionally at the top level and move conditional logic after the hook calls.

4. What is a stale closure in React Hooks?

A closure that captured a variable's value from a previous render and never updates, because it's missing from the dependency array. It shows up as a callback that logs or uses an outdated value even though the component has re-rendered with new state.

5. When should I use useCallback vs useMemo?

Use useCallback when passing a function to a memoized child component. Use useMemo for expensive computations or to stabilize object/array references passed as props. Skip both when nothing downstream depends on referential stability.

About the Author

Amrendra Kumar is a software engineer and technical writer at Code with Amrendra, where he covers React, Next.js, AI Agents, SaaS architecture, and cloud infrastructure. He has written 15+ technical articles on frontend engineering, system design, and modern web development.

LinkedIn | GitHub

Stop Wasting Renders: How to Handle Complex REST APIs in Your Frontend

Amrendra kumar — Tue, 16 Jun 2026 11:52:03 +0000

React REST API render optimization comes down to three problems: mixing server state with client state in useState, firing network requests on every component mount because staleTime defaults to 0, and creating request waterfalls through nested component data fetching.

This article covers the three architectural patterns that cause render waste when integrating REST APIs in React, and the exact production fixes for each. You will come away knowing how to separate server state from client state, configure TanStack Query's cache correctly, and eliminate request waterfalls without restructuring your entire component tree.

If you are also thinking about how component architecture affects render behaviour at scale, Building Reusable React Component Systems at Scale covers the structural decisions that compound with API integration patterns.

The Real Source of React Render Waste

Most render waste does not come from missing React.memo. It comes from storing server state in local useState.

Server state and client state have fundamentally different update requirements:

Server state: async, shared across components, stale after time, needs background refresh
Client state: synchronous, local to a component or feature, user-driven

When you put an API response into useState, every parent re-render, every context update, every sibling state change can cause your fetch cycle to reset or your component to re-render with data it already had. There is no deduplication, no shared cache, no background refresh. Separating these two concerns is the foundational step before any library decision.

For teams building on Next.js, the same separation applies at the framework level — Building Scalable Next.js Applications covers how to structure data fetching across App Router without coupling server state to component lifecycle.

Why `useEffect` + `useState` for API Calls Doesn't Scale

// This pattern breaks at scale
function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then(res => res.json())
      .then(setUser);

    // AbortController required to handle race conditions
    // when userId changes faster than the previous request resolves
    return () => controller.abort();
  }, [userId]);
}

Two components mounting simultaneously with the same userId fire two separate network requests. No shared cache. No deduplication.

Manual AbortController just to handle race conditions. This is not a pattern to optimise with memoization it is a pattern to replace above a certain complexity threshold.

Request Waterfalls: How to Diagnose and Fix Them

A request waterfall is when network requests execute sequentially that could run in parallel. Two patterns cause this in React.

Pattern 1 : Dependent queries: fetch user, then fetch posts using the user ID. The posts request cannot start until the user request resolves.

Pattern 2 : Nested component waterfalls: parent fetches data, conditionally renders a child, child fetches its own data. The child's request cannot start until the parent finishes rendering.

Both are diagnosable in Chrome DevTools Network tab. Look for sequential same-domain requests with no timing overlap.

Fixing Dependent Queries with `useQueries`

import { useQueries } from '@tanstack/react-query';

function Dashboard({ userId }: { userId: string }) {
  const results = useQueries({
    queries: [
      {
        queryKey: ['user', userId],
        queryFn: () => fetchUser(userId),
      },
      {
        queryKey: ['posts', userId],
        queryFn: () => fetchPosts(userId),
        // enabled prevents firing until userId exists,
        // but does NOT create a waterfall both queries
        // are registered and run in parallel on mount
        enabled: !!userId,
      },
    ],
  });

  const [userQuery, postsQuery] = results;
}

As per TanStack Query v5 docs (tanstack.com/query/latest/docs), useQueries runs all queries in parallel by default. The enabled flag controls whether a query fires not whether it waits for another query to complete.

Fixing Nested Component Waterfalls with Prefetching

// Route loader  executes before the component tree renders
export async function loader({ params }) {
  const queryClient = getQueryClient();

  // Prefetch child data so it's already in cache
  // when the child component mounts and calls useQuery
  await queryClient.prefetchQuery({
    queryKey: ['comments', params.postId],
    queryFn: () => fetchComments(params.postId),
  });

  return null;
}

The child component calls useQuery for comments and gets a cache hit immediately. The network request is gone from the component render cycle entirely.

`staleTime` and `gcTime`: The Two Config Values That Matter Most

The TanStack Query default is staleTime: 0. This means every component mount is treated as a cache miss and fires a network request. In a dashboard with 10 components reading the same endpoint, that is 10 requests on a single page load.

Configure staleTime per data type based on how often that data actually changes:

Data Type	Recommended `staleTime`	`gcTime`	Reasoning
User profile	5 minutes	10 minutes	Changes rarely mid-session
Live feed / notifications	10-30 seconds	1 minute	Needs to stay current
Config / reference data	1 hour	24 hours	Almost never changes
Search results	30 seconds	2 minutes	User expects fresh results

Source: TanStack Query v5 docs (tanstack.com/query/latest/docs). Configuration values based on production patterns. Last updated: June 2026.

For multi-tenant SaaS products where different tenants have different data freshness requirements, this configuration approach changes significantly — Designing Multi-Tenant SaaS Platforms for Scale covers the database and routing strategies that inform how per-tenant cache configuration should be structured.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 5 * 60 * 1000,  // 5 minutes: safe default for stable data
      gcTime: 10 * 60 * 1000,    // 10 minutes: keep in memory after unmount
    },
  },
});

// Override per query where freshness requirements differ
useQuery({
  queryKey: ['notifications'],
  queryFn: fetchNotifications,
  staleTime: 15 * 1000, // 15 seconds: this data must stay current
});

gcTime controls when inactive cached data gets garbage collected not how long it is considered fresh. Setting gcTime lower than staleTime means data is garbage collected before it goes stale, which defeats the cache entirely.

SWR vs TanStack Query: Which One for Your Use Case

Feature	SWR v2	TanStack Query v5
Bundle size (gzipped)	~4.2KB	~13KB
Request deduplication	YES	YES
`staleTime` control	Limited	Full, per-query
Mutation handling	`useSWRMutation` (basic)	`useMutation` (full)
DevTools	NO (official)	YES
`useSuspenseQueries`	NO	YES
TypeScript inference	Good	Excellent (v5)
Optimistic updates	Manual	Built-in with rollback

Source: swr.vercel.app, tanstack.com/query/latest/docs. Bundle sizes from bundlephobia.com. Last updated: June 2026.

Decision rule: Use SWR if you need minimal bundle size and simple fetch-cache-revalidate patterns with Next.js. Use TanStack Query if you have mutations, dependent queries, DevTools requirements, or need useSuspenseQueries for waterfall elimination.

Optimistic Updates Without Breaking Data Integrity

The trap with optimistic updates is rollback handling. If the mutation fails, you must revert the UI without a flash or a stale cache entry surviving into the next render cycle.

const mutation = useMutation({
  mutationFn: (updatedPost) => updatePost(updatedPost),

  onMutate: async (updatedPost) => {
    // Cancel outgoing refetches to avoid overwriting
    // the optimistic update with stale server data
    await queryClient.cancelQueries({ queryKey: ['posts', updatedPost.id] });

    // Snapshot the previous value  this is the rollback target
    const previousPost = queryClient.getQueryData(['posts', updatedPost.id]);

    // Apply the optimistic change to the cache immediately
    queryClient.setQueryData(['posts', updatedPost.id], updatedPost);

    return { previousPost };
  },

  onError: (err, updatedPost, context) => {
    // Restore snapshot on failure
    queryClient.setQueryData(['posts', updatedPost.id], context.previousPost);
  },

  onSettled: (updatedPost) => {
    // Always refetch after success or error
    // to sync cache with actual server truth
    queryClient.invalidateQueries({ queryKey: ['posts', updatedPost.id] });
  },
});

onSettled runs after both success and error, ensuring the cache eventually reflects server truth regardless of what happened during the optimistic phase. Skipping onSettled leaves the cache in an optimistic state permanently if the server silently rejects the mutation

Production Checklist: React REST API Integration

Before shipping any React feature that calls a REST API, verify:

Server state lives in TanStack Query or SWR, not in useState
staleTime is configured per query based on actual data freshness requirements — not left at the default of 0
Network tab shows no sequential same-domain requests that could run in parallel
Mutations use onError rollback — not just onSuccess handling
QueryClient is instantiated per request in SSR contexts, never at module level (module-level QueryClient leaks data across users in server environments)
Query cancellation is wired for queries that depend on rapidly-changing props like search input

Conclusion

React render waste from REST APIs is an architectural problem, not a component-level one. The fix starts with separating server state from client state, then configuring your cache to match actual data freshness requirements, then eliminating waterfalls before they reach production.

Every pattern in this article is production-tested and applies directly to dashboards, SaaS products, and admin panels hitting REST endpoints at scale.

If this helped, follow on GitHub for production React patterns and annotated code samples: github.com/AmrendraCodes

About the Author

Amrendra Kumar is a software engineer and technical writer at Code with Amrendra, where he covers React, Next.js, AI Agents, SaaS architecture, and cloud infrastructure.

LinkedIn | GitHub

React vs Next.js: What Should Developers Choose?

Amrendra kumar — Mon, 08 Jun 2026 13:00:19 +0000

React + Vite vs Next.js: Production Decision Guide

Last Updated: June 2026
Last Reviewed: June 2026
Author: Amrendra Kumar

Quick Summary Box

React + Vite vs Next.js is not a tooling debate. It is an architecture decision. React + Vite fits client-heavy apps where routing, APIs, rendering, and deployment stay separate. Next.js fits product surfaces that need server rendering, metadata, image handling, route handlers, and React Server Components. Pick Vite when you want control. Pick Next.js when rendering strategy affects revenue, SEO, or infrastructure shape.

Introduction

This guide helps you decide whether a production React project should use React + Vite or Next.js. The decision comes down to rendering, routing, infrastructure ownership, caching, and team boundaries. React + Vite gives you a smaller frontend surface with fewer framework rules. Next.js gives you a full-stack React runtime with server rendering, file-based routing, route handlers, and React Server Components.

For more React architecture patterns, read the React performance guides. After this guide, you should be able to defend the choice in a technical design review.

React + Vite vs Next.js: The Actual Comparison

React + Vite is a frontend app setup. Next.js is a React framework with routing, rendering, server functions, image handling, and deployment conventions.

The wrong comparison is “which is faster?” Vite usually gives a faster local dev server. Next.js gives more production primitives. Those are different axes.

Criteria	React + Vite	Next.js
App type	Client-rendered SPA by default	Full-stack React framework
Routing	Add React Router or TanStack Router	File-based routing included
Rendering	CSR by default	CSR, SSR, SSG, streaming, RSC
Server code	Separate backend required	Route Handlers and Server Actions
SEO control	Manual setup	Metadata API and server rendering
Image handling	Manual CDN or library setup	Built-in Image component
Hosting	Static hosting works well	Server or platform runtime often needed
Team fit	Frontend and backend split	Product teams shipping vertical slices

Source: React docs, Next.js docs, Vite docs. Last updated: June 2026.

In shipped dashboards, I usually keep React + Vite when the app sits behind auth and depends on API latency anyway. I reach for Next.js when the first document response, metadata, caching, or content route matters.

How Rendering Models Differ: CSR, SSR, SSG, RSC

Rendering decides where HTML gets created and how much JavaScript the browser must hydrate.

React + Vite gives you client-side rendering unless you add a meta-framework or custom SSR pipeline. Next.js gives rendering choices at the route level. That is useful, but it also creates more failure modes.

Rendering model	React + Vite	Next.js	Best use case
CSR	Default	Supported	Dashboards, internal tools, authenticated apps
SSR	Custom setup	Built in	Request-specific pages
SSG	Build pipeline required	Built in	Blogs, docs, marketing pages
RSC	Not available by default	App Router default	Server-first UI with smaller client bundles

Source: React Server Components docs, Next.js App Router docs. Last updated: June 2026.

React Server Components render ahead of time in a server environment separate from the client app or SSR server, according to React docs. Next.js App Router uses Server Components by default, which changes where data fetching and component execution happen.

The RSC Client Boundary Gotcha

The biggest App Router mistake is putting 'use client' too high in the tree. That turns every imported child module into client code.

Bad boundary:

'use client'

import { ProductList } from './ProductList'
import { getProducts } from '@/lib/products'

export default async function ProductsPage() {
  // This is wrong because Client Components cannot directly run server-only data access.
  const products = await getProducts()

  return <ProductList products={products} />
}

Correct boundary:

import { ProductListClient } from './ProductListClient'
import { getProducts } from '@/lib/products'

export default async function ProductsPage() {
  // Runs on the server. Database tokens and private APIs stay off the client bundle.
  const products = await getProducts()

  return <ProductListClient products={products} />
}

'use client'

type Product = {
  id: string
  name: string
  price: number
}

export function ProductListClient({ products }: { products: Product[] }) {
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>
          {product.name}: ${product.price}
        </li>
      ))}
    </ul>
  )
}

React docs define 'use client' as a boundary in the module dependency tree. In practice, that means the directive does not only affect one component. It affects the imported subtree below that file.

Feature Comparison: React + Vite vs Next.js

Next.js ships product-level features. React + Vite asks you to choose those parts yourself.

That is not a weakness. It is the core trade-off.

Routing

React + Vite needs a router library. React Router and TanStack Router both work well for serious apps. You get explicit route objects, loader patterns if your router supports them, and fewer framework file conventions.

Next.js gives file-based routing through the App Router. Layouts, nested segments, loading states, and route-level server rendering live inside the framework.

Choose Vite when your team wants explicit route config. Choose Next.js when route folders, layouts, and server-first routing reduce glue code.

Data Fetching

React + Vite usually pairs with TanStack Query, SWR, Apollo, or custom fetch wrappers. Data fetching happens in the browser unless your backend prepares data separately.

Next.js lets Server Components fetch data before the client bundle runs. Route Handlers handle custom HTTP endpoints inside the app directory. Server Actions can handle mutations from forms and Client Components.

The trade-off is debugging complexity. Server and client execution now share one repo but not one runtime.

Image Optimization

React + Vite does not include image transformation. You usually rely on Cloudinary, Imgix, a CDN, or build-time image tooling.

Next.js includes the Image component. The docs state that it can serve correctly sized images, modern formats, layout stability, lazy loading, and remote image resizing through the Next.js server.

For ecommerce, blogs, and landing pages, this can reduce layout shift work. For authenticated SaaS dashboards, image handling rarely decides the framework.

API Endpoints

React + Vite does not include backend endpoints. You deploy APIs separately through Express, Fastify, NestJS, Lambda, Cloudflare Workers, or another backend.

Next.js supports Route Handlers in the app directory using the Web Request and Response APIs. That is useful for webhooks, lightweight BFF endpoints, auth callbacks, and internal product APIs.

For large backend domains, do not bury core business services inside Next.js routes. Keep domain APIs separate and use Next.js as the product edge.

Deployment Cost and Infrastructure Trade-offs

React + Vite is cheap to deploy because it can compile into static assets. Next.js cost depends on which features you use.

A static Next.js app can be cheap. A Next.js app using SSR, image transformation, server functions, middleware, and cache invalidation needs runtime capacity.

Option	React + Vite	Next.js	Cost at scale	Server requirement
Static CDN	Natural fit	Works for static export limits	Low	No app server
Vercel	Works	Best platform fit	Can rise with SSR and image usage	Managed
AWS S3 + CloudFront	Natural fit	Needs extra setup for SSR	Low for static assets	No for static, yes for SSR
Node server	Usually backend only	Common for self-hosting	Depends on traffic	Yes
Serverless functions	API layer only	Route-level server execution	Can spike with request volume	Managed
Kubernetes	Overkill for many SPAs	Useful for platform teams	Operational cost high	Yes

Source: Vite deployment docs, Next.js deployment docs, AWS hosting patterns. Last updated: June 2026.

In architecture reviews, I separate framework cost from platform cost. Next.js is not automatically expensive. It becomes expensive when every route becomes request-rendered and image processing sits on the app platform instead of a tuned CDN path.

Decision Matrix: Which to Choose for Your Project Type

Pick the framework based on product shape, not developer preference.

Project archetype	Better choice	Reason
Internal admin dashboard	React + Vite	SEO does not matter and APIs already exist
Authenticated SaaS app	React + Vite or Next.js	Use Vite for app shell, Next.js for marketing plus app routes
Content-heavy blog	Next.js	SSG, metadata, routing, and image handling matter
Ecommerce storefront	Next.js	Server rendering, product metadata, and image handling affect conversion
Real-time collaboration app	React + Vite	Client state, sockets, and backend services dominate
Multi-tenant B2B platform	Next.js with separate backend	Product routes and server components help, but domain APIs stay separate

Source: React docs, Next.js docs, production architecture patterns. Last updated: June 2026.

A practical hybrid is common: Next.js for public pages, pricing, docs, SEO pages, and account entry points. React + Vite for the logged-in workspace if the app behaves like a desktop product.

When to Migrate a React SPA to Next.js

Do not migrate only because Next.js is popular. Migrate when the current SPA creates measurable product or engineering pain.

Trigger 1: SEO Depends on Rendered Content

If crawlers need product descriptions, docs pages, canonical metadata, structured data, or localized content, a pure SPA becomes fragile.

You can patch metadata with prerendering, but once content routes multiply, Next.js usually reduces custom infrastructure.

Trigger 2: The Backend-for-Frontend Layer Keeps Growing

A Vite app often starts with direct API calls. Later, the frontend needs auth shaping, request aggregation, feature flags, analytics enrichment, and webhook-adjacent endpoints.

That is the point where Route Handlers or a dedicated BFF becomes useful.

Trigger 3: Initial Load Carries Too Much Client JavaScript

If the first route downloads code for data fetching, formatting, layout decisions, and non-interactive content, server-first rendering can cut client work.

React Server Components help because server-only UI does not add to the client JavaScript bundle in the same way Client Components do.

React 19 Changes the Equation

React 19 makes the framework decision less about React itself and more about the runtime around React.

React 19 added stable APIs around Actions, Server Functions, document metadata, and Server Components support through frameworks. React docs also clarify that there is no directive for Server Components. 'use server' marks Server Functions, not Server Components.

This matters because plain React + Vite does not automatically give you RSC infrastructure. The React features exist, but you need a framework or integration layer to wire bundling, transport, routing, and server execution.

Next.js already integrates those pieces in App Router. That gives it an advantage for teams that want server-first React now.

Remix and TanStack Start as Alternatives

Next.js is not the only route.

Remix focuses on web fundamentals, nested routing, server loaders, actions, and progressive behavior. React Router framework mode now carries much of that direction.

TanStack Start targets type-safe full-stack React with TanStack Router, server functions, and streaming patterns. It fits teams already invested in TanStack Query and router primitives.

The decision is not Next.js or nothing. The real decision is:

SPA toolchain: React + Vite
Full-stack React framework: Next.js, Remix, or TanStack Start
Custom platform: React with your own SSR, routing, and backend edge

FAQ

1. Is React + Vite better than Next.js?

React + Vite is better for client-heavy apps, internal tools, and products with a separate backend. Next.js is better when routing, server rendering, metadata, image handling, or React Server Components affect the product.

2. Should I use Next.js for every React project?

No. Next.js adds server and framework behavior that many apps do not need. A dashboard behind auth with existing APIs often ships faster with React + Vite.

3. Is Vite only for small React apps?

No. Vite can handle serious production SPAs. The limit is not Vite. The limit is whether your product needs server rendering, route-level data loading, metadata, and backend endpoints inside the React app.

4. Does Next.js replace a backend?

No. Next.js can host Route Handlers and Server Actions, but it should not hide complex domain services. Payments, permissions, billing, reporting, and integrations often deserve dedicated backend services.

5. Does React 19 make Vite equal to Next.js?

No. React 19 adds framework-facing capabilities, but Vite alone does not provide RSC transport, server routing, or request rendering. You still need framework integration for those features.

6. When should I migrate from Vite to Next.js?

Migrate when SEO, server-rendered content, metadata, route-level caching, or BFF endpoints become recurring problems. Do not migrate only for local developer speed or framework popularity.

7. Is Next.js more expensive to deploy than Vite?

Often, yes, when you use SSR, image processing, middleware, and server functions heavily. A Vite SPA on static hosting usually has a simpler cost model.

8. Can I use React + Vite for SaaS?

Yes. Many SaaS workspaces fit React + Vite well because they run behind login and depend on APIs. Use Next.js when the SaaS also needs public pages, docs, pricing, SEO, and server-rendered entry routes.

Conclusion + CTA

React + Vite vs Next.js comes down to ownership. React + Vite keeps the frontend thin, explicit, and easy to host. Next.js gives you a server-aware React runtime with routing, rendering, metadata, image handling, Route Handlers, and React Server Components.

Choose React + Vite for dashboards, internal tools, real-time workspaces, and apps with a strong backend boundary.

Choose Next.js for content-heavy products, ecommerce, docs, marketing pages, SEO routes, and product surfaces where the first HTML response matters.

If this helped, follow Amrendra Kumar on GitHub for more production-grade React and Next.js patterns: https://github.com/AmrendraCodes

About the Author
Amrendra Kumar is a software engineer and technical writer at
Code with Amrendra, where he
covers React, Next.js, AI Agents, SaaS architecture, and cloud
infrastructure. He has written 200+ technical articles on frontend
engineering, system design, and modern web development.
LinkedIn |
GitHub