A standalone module, separate from the main track: what each one actually is, how they work under the hood, and — most importantly — when they pay off and when they don't.
React is a library (not a full framework) for building user interfaces, created by Facebook and released in 2013. It solves a specific problem: keeping the visual interface in sync with data that changes over time, without you having to manually manipulate HTML on every change.
React's core idea is composition through components: instead of thinking about the entire page at once, you break the interface into independent, reusable pieces (a button, a product card, a form), each with its own data and behavior, and assemble the screen by combining these pieces like blocks.
Why React was born: before it, manually updating the interface (finding an element in the DOM and changing its content) in large, highly interactive applications became hard to maintain as the number of screens and interactions grew — small changes in one place would break other parts of the page without warning. React proposed describing what the interface should look like for a given data state, and letting React itself decide what actually needs to change on screen.
2. How React works under the hood
React's core mechanism is reconciliation, popularly (though somewhat loosely) associated with the term "virtual DOM". Broadly, it works like this:
Each component describes, through JSX, what the interface should look like for the current data state — this description is an in-memory data structure, not the page's actual HTML.
When a component's state (internal data) or props (received data) change, React generates a new version of that description.
React compares the new version with the previous one (the "diff" between them) and calculates the smallest set of changes needed in the browser's real DOM.
Only those specific changes get applied to the actual screen — instead of recreating everything from scratch on every update.
This process is what enables fast, fluid updates even in complex interfaces, and it's why concepts like the key in lists exist: they help React know exactly which specific item changed, was added, or removed, instead of recreating the entire list.
3. What Next.js is
Next.js is a framework built on top of React, created by the company Vercel. If React solves "how to structure and update the interface", Next.js solves a set of problems React alone doesn't define an answer for: where each part of your code should run (server or client), how to structure routes, how to fetch data efficiently, and how to ship all of that optimized for production.
Next.js doesn't replace React — it adds a layer of architectural decisions and tooling around it, so each project doesn't have to reinvent these solutions from scratch.
What React alone doesn't solve
Routing between pages (needs an extra library, like React Router)
Server-side rendering (by default, everything runs in the client's browser)
Build configuration (Vite or Webpack need to be set up separately)
Per-page image, font, and SEO optimization
What Next.js delivers out of the box
File and folder-based routing (App Router)
Per-page rendering choice: server, client, or hybrid
Build and bundler already configured and optimized by default
Automatic image, font, and SEO metadata optimization
4. How Next.js works under the hood
The most important concept in modern Next.js (App Router) is the distinction between Server Components and Client Components:
Server Components (the default): run only on the server, generate ready-made HTML, and don't send extra JavaScript to the user's browser. Great for parts of the page that don't need interactivity (text, listings, content coming straight from a database).
Client Components (explicitly marked with "use client" at the top of the file): run in the browser, and are required whenever the interface needs real interactivity — clicks, forms, local state, effects.
Beyond that, Next.js decides, per route, a rendering strategy (Lesson 8 of the main track will go deeper into this):
Strategy
When the HTML is generated
SSR (Server-Side Rendering)
On every request, the moment the user asks for the page
SSG (Static Site Generation)
Once, at project build time
ISR (Incremental Static Regeneration)
Like SSG, but automatically revalidated from time to time
It's this flexibility — being able to mix all three strategies, page by page, within the same project — that sets Next.js apart from a plain React application, which by default only knows how to do one thing: render everything in the client's browser (CSR).
5. React alone vs React + Next.js
Plain React (e.g. with Vite)
React + Next.js
Routing
Needs an extra library
File-based, included
Rendering
Client-only (CSR) by default
Server, client, or hybrid, per route
SEO
Requires extra manual work
Natively solved via SSR/SSG
Build configuration
You choose and configure it (e.g. Vite)
Built in, little to configure
Learning curve
Simpler to get started
More concepts to learn upfront (Server/Client Components, rendering strategies)
6. When to use it
Plain React (no Next.js) pays off when: you're building an application that doesn't need SEO (an internal dashboard, a tool behind a login, a "desktop-like" app running in the browser), a separate backend already serves data via API, and you want the fewest possible layers between your code and the final result.
Next.js pays off when: the project needs to show up well in search engines (content sites, e-commerce, landing pages), you want to mix static content with dynamic parts in the same application, or you'd rather have routing, build, and optimizations already solved instead of assembling every piece by hand.
7. When it's not worth it
Not every project needs React (with or without Next.js). It's worth considering simpler alternatives when:
The site is mostly static (few pages, little to no dynamic data): plain HTML/CSS, or a simpler static site generator, delivers the same result with much less complexity and less JavaScript for the user to download.
It's a small widget embedded in another page (a counter, a standalone form): loading React's entire runtime for that is often disproportionate to the problem.
Extreme performance is the number one requirement and even a few extra kilobytes of JavaScript matter (e.g. pages that need to load on very slow connections or very limited devices).
The team isn't familiar with the modern JavaScript ecosystem and the timeline doesn't allow for the learning curve — in that case, a more opinionated framework in another language (like Django or Rails, covered in Module 1's extra material) might deliver value faster.
The practical rule of thumb: React and Next.js are very good at solving the problem of complex interfaces, with heavy state and interaction, that also need good performance and good SEO at the same time. If your project doesn't have that complexity, adopting these tools might mean paying a learning and maintenance cost without getting the benefit they were designed to deliver.
Share:
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.
Imersão · Next.js + React
Imersão em React e Next.js
Módulo separado da trilha principal: o que cada um é de fato, como funcionam por baixo dos panos, e — o mais importante — em que situações eles compensam ou não compensam usar.
React é uma biblioteca (não um framework completo) para construir interfaces de usuário, criada pelo Facebook e lançada em 2013. Ele resolve um problema específico: manter a interface visual sincronizada com os dados que mudam ao longo do tempo, sem você precisar manipular o HTML manualmente a cada mudança.
A ideia central do React é a composição por componentes: em vez de pensar na página inteira de uma vez, você quebra a interface em pedaços independentes e reutilizáveis (um botão, um card de produto, um formulário), cada um com seus próprios dados e comportamento, e monta a tela combinando esses pedaços como blocos.
Por que o React nasceu: antes dele, atualizar a interface manualmente (buscar um elemento no DOM e mudar seu conteúdo) em aplicações grandes e muito interativas ficava difícil de manter conforme o número de telas e interações crescia — pequenas mudanças em um lugar quebravam outras partes da página sem aviso. O React propôs descrever como a interface deveria estar para um determinado estado de dados, e deixar o próprio React decidir o que precisa mudar de verdade na tela.
2. Como o React funciona por baixo dos panos
O mecanismo central do React é a reconciliação, popularmente (embora de forma simplificada) associada ao termo "DOM virtual". Funciona assim, em linhas gerais:
Cada componente descreve, através de JSX, como a interface deveria se parecer para o estado atual dos dados — essa descrição é uma estrutura de dados em memória, não o HTML real da página.
Quando o state (dados internos) ou as props (dados recebidos) de um componente mudam, o React gera uma nova versão dessa descrição.
O React compara a versão nova com a versão anterior (a "diferença" entre elas) e calcula o menor conjunto de mudanças necessárias no DOM real do navegador.
Só essas mudanças específicas são aplicadas na tela de verdade — em vez de recriar tudo do zero a cada atualização.
Esse processo é o que permite atualizações rápidas e fluidas mesmo em interfaces complexas, e é a razão pela qual conceitos como a key em listas existem: eles ajudam o React a saber exatamente qual item específico mudou, foi adicionado ou removido, em vez de recriar a lista inteira.
3. O que é Next.js
Next.js é um framework construído em cima do React, criado pela empresa Vercel. Se o React resolve "como estruturar e atualizar a interface", o Next.js resolve um conjunto de problemas que o React sozinho não define uma resposta: onde cada parte do código deve rodar (servidor ou cliente), como estruturar rotas, como buscar dados de forma eficiente, e como entregar tudo isso otimizado para produção.
Next.js não substitui o React — ele adiciona uma camada de decisões arquiteturais e ferramentas em volta dele, para que cada projeto não precise reinventar essas soluções do zero.
O que o React sozinho não resolve
Roteamento entre páginas (precisa de biblioteca extra, como React Router)
Renderização no servidor (por padrão, tudo roda no navegador do cliente)
Configuração de build (Vite ou Webpack precisam ser configurados à parte)
Otimização de imagens, fontes, SEO por página
O que o Next.js entrega pronto
Roteamento baseado em pastas e arquivos (App Router)
Escolha de renderização por página: servidor, cliente, ou híbrido
Build e bundler já configurados e otimizados por padrão
Otimização automática de imagem, fonte, metadados de SEO
4. Como o Next.js funciona por baixo dos panos
O conceito mais importante do Next.js moderno (App Router) é a distinção entre Server Components e Client Components:
Server Components (o padrão): rodam só no servidor, geram HTML pronto, e não enviam JavaScript extra para o navegador do usuário. Ótimos para partes da página que não precisam de interatividade (texto, listagens, conteúdo vindo direto de banco de dados).
Client Components (marcados explicitamente com "use client" no topo do arquivo): rodam no navegador, e são necessários sempre que a interface precisa de interatividade real — cliques, formulários, estado local, efeitos.
Além disso, o Next.js decide, por rota, uma estratégia de renderização (a Lição 8 da trilha principal vai aprofundar isso):
Estratégia
Quando o HTML é gerado
SSR (Server-Side Rendering)
A cada requisição, no momento em que o usuário pede a página
SSG (Static Site Generation)
Uma vez, no momento do build do projeto
ISR (Incremental Static Regeneration)
Como SSG, mas revalidado automaticamente de tempos em tempos
É essa flexibilidade — poder misturar as três estratégias, página por página, dentro do mesmo projeto — que diferencia o Next.js de uma aplicação React pura, que por padrão só sabe fazer uma coisa: renderizar tudo no navegador do cliente (CSR).
5. React sozinho vs React + Next.js
React puro (ex: com Vite)
React + Next.js
Roteamento
Precisa de biblioteca extra
Baseado em arquivos, incluído
Renderização
Só no cliente (CSR), por padrão
Servidor, cliente ou híbrido, por rota
SEO
Exige trabalho manual extra
Resolvido nativamente via SSR/SSG
Configuração de build
Você escolhe e configura (Vite, por ex.)
Embutida, pouco a configurar
Curva de aprendizado
Mais simples de começar
Mais conceitos para entender de início (Server/Client Components, estratégias de renderização)
6. Quando usar
React puro (sem Next.js) compensa quando: você está construindo uma aplicação que não precisa de SEO (um painel interno, uma ferramenta atrás de login, um app "tipo desktop" rodando no navegador), já existe um backend separado servindo dados via API, e você quer o mínimo de camadas entre o seu código e o resultado final.
Next.js compensa quando: o projeto precisa aparecer bem em buscadores (sites de conteúdo, e-commerce, landing pages), você quer misturar conteúdo estático com partes dinâmicas na mesma aplicação, ou prefere ter roteamento, build e otimizações já resolvidos em vez de montar cada peça manualmente.
7. Quando não compensa usar
Nem todo projeto precisa de React (com ou sem Next.js). Vale considerar alternativas mais simples quando:
O site é majoritariamente estático (poucas páginas, pouco ou nenhum dado dinâmico): HTML/CSS puro, ou um gerador de site estático mais simples, entrega o mesmo resultado com muito menos complexidade e menos JavaScript para o usuário baixar.
É um widget pequeno embutido em outra página (um contador, um formulário isolado): carregar todo o runtime do React para isso costuma ser desproporcional ao problema.
Performance extrema é o requisito número um e até alguns kilobytes de JavaScript a mais importam (ex: páginas que precisam carregar em conexões muito lentas ou dispositivos muito limitados).
O time não tem familiaridade com o ecossistema JavaScript moderno e o prazo não permite a curva de aprendizado — nesse caso, um framework mais opinativo em outra linguagem (como Django ou Rails, vistos no material complementar do Módulo 1) pode entregar valor mais rápido.
A régua prática: React e Next.js resolvem muito bem o problema de interfaces complexas, com muito estado e muita interatividade, que também precisam de boa performance e bom SEO ao mesmo tempo. Se o seu projeto não tem essa complexidade, adotar essas ferramentas pode ser pagar um custo de aprendizado e de manutenção sem ganhar o benefício que elas foram desenhadas para entregar.
Compartilhar:
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.