You install Node.js, run some npm commands, scaffold a React project with
Vite, and stare at a package.json next to a node_modules folder with
24 packages in it. Then you open another repository and it uses Next.js
instead of Vite, and nothing looks the same. Are these tools competing?
Overlapping? Doing completely different jobs? Here is the mental model
that makes the whole frontend ecosystem click: there are only four jobs,
and every tool you have met does exactly one of them.
The short answer
React is the UI library (components). npm is the package manager
(installs code and runs scripts). Node.js is the JavaScript runtime
that powers your dev tools on your machine. Vite is the build tool
(dev server + production bundler). Next.js is a React framework that
bundles React with routing, rendering options, and server capabilities.
The browser runs only HTML, CSS, and JavaScript - everything else exists
to turn your source code into those three.
The map: four jobs, not forty tools
Every tool in a frontend project does one of four jobs:
- Write the UI - React (components, state, JSX)
- Manage packages - npm (install dependencies, run scripts)
- Develop and build - Vite (dev server, production bundle)
- Structure the app - Next.js (routing, rendering, server features)
Where each tool lives
Follow a file from your machine to the user's browser.
YOUR MACHINE
Node.js
JS runtime for your tools
npm
Installs packages, runs scripts
Vite dev server
Serves modules, hot reloads
Your source code
React components, CSS, assets
Next.js framework (optional)
BUILD STEP
vite build
546ms, real run
USER'S BROWSER
HTML + CSS + JS
The only three things
a browser understands.
React runs here
as compiled JS.
No Node.js.
No npm. No Vite.
PRODUCTION
Static hosting
CDN serves the
dist/ files (Vite path)
or
Node.js server
Renders + serves
(Next.js path)
Read the diagram left to right: your machine does the work, the build
step converts source into static files, the browser runs only those
files, and production is either a dumb file host or a real server.
Everything in this article is a zoomed-in view of one of these boxes.
What the browser actually runs
Strip away every tool and the browser understands exactly three things:
HTML for structure, CSS for presentation, JavaScript for behavior. That
is the entire runtime contract. JSX is not on the list. TypeScript is
not on the list. Neither ever reaches a browser.
TypeScript is a development-time layer: you write typed JavaScript, a
compiler strips the types away, and plain JavaScript ships. Think of it
as spell-check for code - it catches mistakes while you write, then
deletes itself before publishing. Useful, optional, and invisible to
the user.
If a tool's output is not HTML, CSS, or JavaScript, it is a
development tool, not a runtime. That single test classifies almost
everything in this article.
Node.js and npm: the machine behind your machine
Here is the question beginners never get a straight answer to: if my
website runs in the browser, why did the tutorial make me install
Node.js? Because your development tools are JavaScript programs, and
JavaScript programs need somewhere to run outside a browser. Node.js is
that somewhere: a JavaScript runtime for your machine. npm ships with it.
npm itself is three things (per the official docs):
the registry (a giant public database of JavaScript packages), the CLI
(the npm command in your terminal), and the website where you browse
packages. When you run npm install react, the CLI downloads React from
the registry into a node_modules folder. That is the whole magic.
Two files run the show. package.json is the manifest: your project's
name, its dependencies, and its scripts. package-lock.json is the
receipt: the exact version of every package installed, so the project
builds identically on every machine. Commit both; ignore node_modules.
And npm run dev? It does less than you think. npm looks up the dev
entry under scripts in package.json and executes that command. Here is
a real one, generated minutes ago by scaffolding a project:
{
"name": "task-app",
"private": true,
"version": "0.0.0",
"type": "module",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"dependencies": {
"react": "^19.2.8",
"react-dom": "^19.2.8"
},
"devDependencies": {
"@vitejs/plugin-react": "^6.1.1",
"vite": "^8.3.0"
}
}
npm run dev here literally runs the vite command. npm is the
receptionist, not the engine: it reads the script name and dials the
number. The engine is whatever the script points to.
React: the UI library, nothing more
React calls itself "the library for web and native
user interfaces," and the word library is doing heavy lifting. A
library does one job you call into; a framework owns the project
structure and calls your code. React is the former. It gives you
components - self-contained pieces of UI written as JavaScript
functions - plus props (data flowing in) and state (data the component
owns). You describe what the screen should look like for any given
state, and React updates the DOM to match. That declarative model is
the entire idea; everything else is ecosystem.
function TaskItem({ task, onToggle }) {
return (
<li>
<input
type="checkbox"
checked={task.done}
onChange={() => onToggle(task.id)}
/>
<span className={task.done ? "done" : ""}>{task.title}</span>
</li>
);
}
Notice what is missing: no routing, no data fetching conventions, no
build setup, no opinion about where this component lives in an app.
React's own docs say it plainly: React does not prescribe routing and
data fetching, and for a whole app they recommend a full-stack React
framework. A component library is a powerful starting point and an
incomplete application. The tools below exist to complete it.
Vite: the dev server and the build
Vite ("veet", French for quick) is a build
tool with exactly two halves, and keeping them separate ends half the
confusion around it:
-
A dev server. Run
npm run devand Vite serves your source as native ES modules straight to the browser, with Hot Module Replacement that updates the page in milliseconds when you save. No bundling step while you work - that is where the speed comes from. -
A build command. Run
npm run buildand Vite bundles everything into minified, optimized static files indist/, ready for any static host.
Here is that build, run for real while writing this article:
Twenty modules in, one HTML file plus hashed assets out, in about half
a second. Those dist/ files are the entire website: upload them to any
static host and you are deployed. No Node.js runs in production here.
No npm. The browser gets HTML, CSS, and JS, exactly as the diagram
promised.
Two facts worth knowing in 2026: Vite's production bundler is now
Rolldown (Rust-based), and Vite requires
Node.js 20.19+ or 22.12+ on your machine - because, again, the dev
server and the build are programs that run on your machine, not in the
browser.
Next.js: the React framework
Next.js is "a React framework for building
full-stack web applications." Read that sentence carefully: it contains
React and adds the application structure React deliberately leaves out.
Where React + Vite says "here are sharp tools, architect it yourself,"
Next.js says "here is the architecture; fill in the pages."
What it actually adds:
-
File-based routing. A file at
app/tasks/page.tsxbecomes the/tasksroute. No router library to configure. - Rendering options per page. Static generation, server-side rendering, or client-side rendering - chosen where each fits, instead of one default for the whole app.
-
React Server Components. In the App Router, components run on the
server by default: they can read from a database directly and ship
zero JavaScript for themselves to the browser. Interactive parts opt
into the client with
'use client'. - API routes and server code living in the same project, so the frontend and its backend-adjacent logic deploy together.
- Its own build pipeline. Next.js configures its bundler and compiler for you (Turbopack-based in current releases) - you never touch that layer directly.
The honest trade: you give up some architectural freedom and accept a
bigger mental model (server components vs client components, caching
rules), and in return routing, rendering, and deployment conventions
arrive solved. For content sites, e-commerce, and SaaS marketing pages -
anything where SEO and first-load performance matter - that trade is
usually worth it.
"Is Next.js just a faster Vite?" No. Vite is a build tool; Next.js is
a framework that includes build tooling among many other things.
Comparing them directly is like comparing an engine to a car. Compare
complete setups instead: React + Vite vs React + Next.js.
From npm create to the browser: the full workflow
Here is everything above, in order, as one working session. This is the
React + Vite path - the Next.js path differs only in the framework box.
Node.js gives you a JavaScript runtime on your machine; npm (which
ships with it) fetches code from the registry. npm create vite
downloads a starter template, and npm install reads package.json
and fills node_modules - 24 packages for the default React
template in the real run above.
Your source lives in src/: React components (.jsx), styles,
assets. This is the only code you author. Everything else in the
project exists to serve, transform, or ship these files.
npm run dev executes the vite binary. Vite serves your modules
natively to the browser at localhost:5173 and hot-swaps edits in
milliseconds. Node.js is running the server; the browser is only
displaying the result.
npm run build compiles JSX, bundles modules, minifies, and hashes
filenames into dist/. Nothing in dist/ mentions Vite, npm, or
Node - they have done their jobs and left the building.
Upload dist/ to any static host. The browser downloads HTML, CSS,
and JS and runs your React app. Production involves zero Node.js
on this path - the runtime already did its work on your machine.
The resulting project looks like this:
React + Vite vs Next.js: the decision guide
| React + Vite | React + Next.js | |
|---|---|---|
| What it is | UI library + build tool | Full-stack React framework |
| Routing | You add it (e.g. React Router) | File-based, built in |
| Rendering | Client-side by default | Per-page: static, server, or client |
| Server code | Separate backend/API | API routes in the same project |
| SEO | Weak out of the box (empty HTML shell) | Strong (server-rendered HTML) |
| Dev server start | Near-instant | A few seconds |
| Production deploy | Any static host / CDN | Static export or a Node server |
| Best for | Learning React, dashboards, SPAs, internal tools | Blogs, e-commerce, marketing sites, SaaS |
- You are learning React and want the smallest possible setup
- The app is a dashboard, admin panel, or internal tool behind a login
- SEO does not matter (nobody Googles your admin panel)
You want full control over architecture and dependencies
Pages must rank on Google (blog, docs, store, landing pages)
You want routing, rendering, and API routes without assembling them
First-load performance is a business metric, not a nice-to-have
The team benefits from one opinionated structure
Two honest caveats. First, these are starting points, not destinies: a
Vite app can grow server rendering later, and a Next.js app can serve
fully client-side pages where that fits. Second, "popular" is not a
reason: pick the setup whose trade-offs match your project's actual
needs, which for a first learning project is almost always React + Vite.
If you turn this stack into client work, Next.js builds are one of the
best-paid freelance niches right now - the freelancing playbook
covers how to package it.
Where to run each setup
Once built, both paths need a home. These are the standard options with
official links - swap in referral links later where programs exist.
| Setup | Host | Why |
|---|---|---|
React + Vite (dist/ files) |
Cloudflare Pages | Free static hosting on a global CDN; deploy by dragging the folder |
React + Vite (dist/ files) |
Netlify | Drop-in static deploys with previews per commit |
| Next.js | Vercel | Built by the Next.js team; server features work with zero config |
{/* MONETIZATION NOTE: Vercel/Netlify/Cloudflare have partner or referral programs - replace official URLs with affiliate links once approved. */}
Frequently asked questions
Is React a framework or a library?
React is a library for building user interfaces, not a framework. It
handles components, props, and state - describing what the UI should
look like. It does not include routing, data fetching conventions, or
build tooling. That is why React projects pair it with tools like Vite
or frameworks like Next.js, which supply the missing application
structure.
Do I need Node.js to run a React app in the browser?
No. The browser runs your compiled JavaScript; it never sees Node.js.
You install Node.js because the development tools around React - npm,
Vite's dev server, build scripts - are JavaScript programs that need a
runtime outside the browser. In production, a plain React + Vite app is
static files on a CDN with no Node.js involved at all.
What does npm run dev actually do?
It looks up the dev script in your package.json and executes it. In a
Vite React project that script is simply the word vite, which starts
Vite's development server. npm itself does not compile anything or
start servers - it just runs the command the script names, the same way
typing it directly would.
Is Vite a replacement for React?
No. Vite and React do different jobs at different layers. React is the
UI library: components and rendering logic. Vite is the build tool: it
runs the dev server, transforms your modules during development, and
bundles everything into optimized static files for production. A React
project needs both a UI library and build tooling; Vite is one popular
choice for the tooling half.
Is Next.js just a faster Vite?
No, and this is the most common category error in frontend discussions.
Vite is a build tool; Next.js is a React framework. Next.js includes
React plus file-based routing, server rendering options, React Server
Components, and API routes - application architecture decisions, not
just faster builds. You compare setups (React + Vite vs React +
Next.js), never the two tools directly.
When should I pick React + Vite over Next.js?
Pick React + Vite when you are learning React, building a client-side
app like a dashboard or internal tool, or want full control over your
architecture with minimal opinions. Pick Next.js when you need
SEO-friendly server-rendered pages, file-based routing out of the box,
or backend-adjacent features like API routes in the same project.
What to do next
You now have the map. The fastest way to make it permanent is one
working session: scaffold the React + Vite project from this article,
open package.json, change one line of a component, watch the browser
update, then run the build and open dist/index.html directly. Seeing
the pipeline end to end once beats reading about it five times.
Then learn the layers in this order: JavaScript properly, React
components and state, npm scripts and dependencies, one deployment.
Add TypeScript when a project's size makes types pay for themselves.
Reach for Next.js when you have a real project that needs routing and
SEO - not before.
If you are a founder or developer who wants this kind of stack built
for a real product - a React + Vite app or a full Next.js build,
shipped with the deployment pipeline included - let's talk.
I build frontend systems like the ones in this article for clients.
Building in public: a companion video walks through this same mental
model with the diagram built live. It will be embedded here when it
lands.
Top comments (0)