Cooldecode · Lesson 06 · Main track

What Next.js is, and why it exists "on top of" React

You already know what React is: components, JSX, state, props, hooks. Today we understand why almost nobody uses "plain" React in production — and what exactly a framework like Next.js adds on top of it.

01The problem React alone doesn't solve

React is a UI library — it knows how to turn state into elements on screen and keep them in sync. That's it. It doesn't decide how pages navigate between each other, doesn't know how to fetch data before rendering, doesn't know how to bundle your code for production, doesn't know where the page should be rendered (server or browser), and doesn't come with anything ready for SEO.

To build a real application with plain React, you choose and wire up everything yourself: a router (React Router), a build tool (Vite, Webpack), a data-fetching strategy, a way to generate HTML on the server if you need SEO, and so on. That's doable, but it's setup work that repeats itself in almost every project.

In one sentence

Next.js is a framework built on top of React that already comes with routing, server-side rendering, build optimizations and project conventions ready to go — so you don't need to make those decisions (or rebuild them) from scratch in every project.

02What Next.js adds, in practice

File-based routing: your project's folder structure already defines the application's routes — there's no route config file to keep up to date.
Server-side rendering: Next.js can generate a page's HTML on the server (or even at build time) before sending it to the browser, which helps SEO and time-to-first-paint.
Built-in data fetching: components can fetch data directly on the server, without needing a separate API just to feed the screen.
Automatic optimizations: code splitting per page, image, font and script optimization — all with minimal configuration.
Convention over configuration: there's a "right" way to organize layouts, error pages, loading states and metadata, so different teams end up structuring projects in similar ways.

03Comparing with plain React

Aspect	Plain React (+ Vite, e.g.)	Next.js
Routing	You choose and configure a library	Folder-based, already included
Server-side rendering	You need to build your own solution	Supported natively
SEO	Hard without manually configured SSR	Much simpler by default
Learning curve	Lower to get started	Higher (more framework-specific concepts)
Architecture flexibility	Total — you decide everything	Guided by the framework's conventions

When Next.js makes sense

A public application that depends on SEO (blog, e-commerce, marketing site)
You want productivity and don't need to reinvent basic architecture decisions
Larger teams, where shared conventions prevent divergence between projects

When plain React is enough

An internal application, behind a login, with no need for SEO
A quick prototype or a small, isolated tool
You want total control over every piece of the stack

04Practical example: the same screen, two ways

In plain React, an "About" page is just another component rendered by a router you configured:

// Plain React with React Router
<Routes>
  <Route path="/about" element={<About />} />
</Routes>

In Next.js, the same route is born just by creating a file in the right place — there's no route list to keep in sync with the components:

// Next.js — App Router
// file: app/about/page.jsx
export default function About() {
  return <h1>About us</h1>;
}
// already available at /about, no extra configuration

It's this kind of pre-made decision — multiplied by dozens of others (images, fonts, cache, build) — that makes Next.js the most common way to use React in production today.

Newsletter

Learn what AI is creating for you. Don't get lost.

Get notified when a new deep dive or lesson goes up. No spam, just new posts.

Cooldecode · Lição 06 · Trilha principal

O que é Next.js e por que ele existe "em cima" do React

Você já sabe o que é React: componentes, JSX, state, props, hooks. Hoje entendemos por que quase ninguém usa React "puro" em produção — e o que exatamente um framework como o Next.js adiciona por cima dele.

01O problema que o React sozinho não resolve

React é uma biblioteca de interface — ele sabe transformar state em elementos na tela e mantê-los sincronizados. Só isso. Ele não decide como as páginas navegam entre si, não sabe como buscar dados antes de renderizar, não sabe empacotar seu código para produção, não sabe onde a página deve ser renderizada (no servidor ou no navegador) e não vem com nada pronto para SEO.

Para montar uma aplicação real com React puro, você mesmo escolhe e conecta: um roteador (React Router), uma ferramenta de build (Vite, Webpack), uma estratégia de busca de dados, uma forma de gerar HTML no servidor se precisar de SEO, e assim por diante. Isso é viável, mas é trabalho de configuração que se repete em praticamente todo projeto.

Em uma frase

Next.js é um framework construído sobre o React que já vem com roteamento, renderização no servidor, otimizações de build e convenções de projeto prontas — para você não precisar tomar essas decisões (ou remontá-las) do zero em cada projeto.

02O que o Next.js adiciona, na prática

Roteamento por arquivos: a estrutura de pastas do seu projeto já define as rotas da aplicação — não existe um arquivo de configuração de rotas para manter atualizado.
Renderização no servidor: o Next.js consegue gerar o HTML de uma página no servidor (ou até em tempo de build) antes de mandar para o navegador, o que ajuda SEO e o tempo até a primeira tela aparecer.
Busca de dados integrada: componentes podem buscar dados diretamente no servidor, sem precisar de uma API separada só para alimentar a tela.
Otimizações automáticas: divisão de código por página, otimização de imagens, fontes e scripts — tudo com configuração mínima.
Convenção sobre configuração: existe um jeito "certo" de organizar layouts, páginas de erro, carregamento e metadados, então times diferentes acabam estruturando projetos de forma parecida.

03Comparando com React puro

Aspecto	React puro (+ Vite, por ex.)	Next.js
Roteamento	Você escolhe e configura uma lib	Baseado em pastas, já incluso
Renderização no servidor	Precisa montar sua própria solução	Suportada nativamente
SEO	Difícil sem SSR configurado à mão	Muito mais simples por padrão
Curva de aprendizado	Mais baixa para começar	Mais alta (mais conceitos próprios)
Flexibilidade de arquitetura	Total — você decide tudo	Guiada pelas convenções do framework

Quando faz sentido usar Next.js

Aplicação pública que depende de SEO (blog, e-commerce, marketing site)
Você quer produtividade e não precisa reinventar decisões básicas de arquitetura
Times maiores, onde convenções compartilhadas evitam divergência entre projetos

Quando React puro basta

Aplicação interna, atrás de login, sem necessidade de SEO
Protótipo rápido ou ferramenta pequena e isolada
Você quer controle total sobre cada peça do stack

04Exemplo prático: a mesma tela, dois jeitos

Em React puro, uma página "Sobre" é só mais um componente renderizado por um roteador que você configurou:

// React puro com React Router
<Routes>
  <Route path="/sobre" element={<Sobre />} />
</Routes>

No Next.js, a mesma rota nasce só de criar um arquivo no lugar certo — não existe uma lista de rotas para manter sincronizada com os componentes:

// Next.js — App Router
// arquivo: app/sobre/page.jsx
export default function Sobre() {
  return <h1>Sobre nós</h1>;
}
// já disponível em /sobre, sem configuração adicional

É esse tipo de decisão pré-tomada — multiplicada por dezenas de outras (imagens, fontes, cache, build) — que faz o Next.js ser hoje a forma mais comum de usar React em produção.

Newsletter

Saiba o que a IA está criando pra você. Não fique por fora.

Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.