← Back to Cooldecode
Lesson 01 · Week 1

How the web works today: client, server, build tools, and where every piece of the "modern stack" fits

Before learning React, Next.js, Supabase or any other tool, you need a clear mental map of who does what when you visit a website. Without that map, every new tool becomes a loose name with nowhere to attach to.

The basic model: client and server

The entire web runs on a simple idea: there's a machine that asks for something (the client) and a machine that answers (the server). When you type an address in the browser, this happens:

Browser (client)
→
HTTP request
→
Server
→
Response (HTML/JSON/etc)
→
Browser renders

The client is, in the vast majority of cases, the browser — but it can also be a mobile app, another server, or a script making an API call. The server is any machine configured to listen for requests and send back a response. That can be a physical server sitting in a cold room somewhere, or — much more common today — a function that runs for a few milliseconds in the cloud and then "shuts down".

This client/server pair is the foundation of everything. React, Next.js, Vercel, Supabase — all of these tools exist to make that request-and-response cycle faster, more organized, or cheaper to maintain. None of them replace this model; they all live inside it.

What the server actually stores and does

A modern web server usually handles three responsibilities:

  1. Business logic — rules that decide what can or can't happen (e.g., "a user can't buy more items than exist in stock").
  2. Data access — reading and writing to a database (that's what SQL does, a topic Lesson 11 will dig into).
  3. Content delivery — returning ready-made HTML, or JSON data for the client to build the screen.

It's this third responsibility — how content is delivered — that separates the "classic" web from the web you'll study in the next lessons.

Classic web: the server sends ready HTML

In the older (and still extremely common) model, the server assembles the complete HTML page and sends it ready to the browser. The browser only needs to display it. That's what WordPress, plain PHP, or Django/Rails applications do by default.

Modern web: the client assembles the page with JavaScript

Starting in the 2010s, a different model gained traction: the server sends a nearly empty HTML shell plus a bunch of JavaScript, and it's that JavaScript, running in the user's browser, that builds the interface, fetches data via API, and updates the screen without reloading the whole page. This is the model React popularized, and it's the reason practically everything you'll study in this track exists.

Key point: "frontend" and "backend" aren't technologies — they're places where code runs. Frontend runs on the user's device (the browser). Backend runs on a machine you control. The confusion most beginners have is thinking certain languages are "frontend" or "backend" — in reality, today, JavaScript runs comfortably on both sides.

Build tools: why your code needs to be "processed" before it runs

Here's a piece that confuses a lot of people: if the browser already understands HTML, CSS and JavaScript natively, why does almost no modern project write "raw" code that goes straight to the browser?

The answer is that, today, the code you write is rarely the code the browser receives. In between there's a step called build (compiling/bundling), done by build tools. They solve practical problems:

Without a build tool
  • You write JSX (React's syntax) and the browser doesn't understand it natively
  • Every JS file is a separate HTTP request — slow with many files
  • Modern code (ES2023) might not run on older browsers
  • CSS and images aren't automatically optimized
With a build tool
  • JSX/TypeScript get converted to plain JavaScript the browser understands
  • Multiple files get grouped ("bundled") into a few optimized files
  • Code gets "translated" (transpiled) to more compatible JS versions
  • Images, CSS and fonts go through automatic optimization

Tools like Vite, Webpack, or Next.js's built-in build system do this work. You write readable code organized across several files; the build tool delivers a compact, compatible, fast-to-load version to the browser. This happens every time you run commands like npm run build or npm run dev.

Where every piece of the "modern stack" fits

With the client/server model and the concept of build tools clear, the map for the next lessons looks like this:

Track map
  • React (lessons 4–5) — a library for building the interface that runs on the client, organized into components.
  • Next.js (lessons 6–8) — a framework built on top of React that decides where each part of your code runs (client or server) and handles the build automatically.
  • Vercel / Netlify (lessons 9–10) — platforms that host the build output and run your server functions without you having to manage a machine.
  • SQL / databases (lessons 11–14) — where the data actually lives, accessed by code running on the server.
  • Supabase (lesson 15) — a ready-made package of database + authentication + storage, so you don't have to assemble every backend piece by hand.
  • Figma / Framer (lessons 17–20) — design tools that connect to code through tokens, components, and (in Framer's case) even direct publishing.

Practical example: the same page in three stages

To make this stick, imagine a simple page that shows "Today it's X degrees". Here's how it would exist under both models:

1. Server sends ready HTML (classic model)

<!-- The server already calculated the temperature and returns this -->
<html>
  <body>
    <p>Today it's 24°C</p>
  </body>
</html>

The browser does nothing but display it. If the temperature changes, the whole page needs to reload to see the new value.

2. Client fetches data and builds the screen (modern model with React)

function Weather() {
  const [temperature, setTemperature] = useState(null);

  useEffect(() => {
    fetch("/api/weather")
      .then(res => res.json())
      .then(data => setTemperature(data.temp));
  }, []);

  return <p>Today it's {temperature ?? "..."}°C</p>;
}

Here, the server only returns raw data ({"temp": 24}) through an API, and it's the JavaScript running in the user's browser that decides how to display it. The advantage: this same function can update the temperature every minute without reloading the page, and the same API endpoint can feed both the website and a mobile app.

3. The build tool's role in between

The code from step 2 uses useState, useEffect, and a syntax (JSX) that mixes HTML with JavaScript. No browser understands this directly. Before it reaches the user, a build tool transforms this code into something like this:

function Weather(){var e=useState(null),t=e[0],temperature=e[0],setTemperature=e[1];
return useEffect(function(){fetch("/api/weather").then(function(r){return r.json()})
.then(function(d){setTemperature(d.temp)})},[]),React.createElement("p",null,
"Today it's ",temperature??"...","°C")}

Compact, without unnecessary whitespace, and using only JavaScript syntax any browser understands. You never write this by hand — that's exactly the repetitive work Vite, Webpack, and Next.js's build system automate.

Pros and cons of both models

Server sends ready HTML
  • Simpler to understand and debug
  • Great for SEO (crawlers read the HTML directly)
  • Works even with JavaScript disabled
  • Every interaction may require reloading the page
  • Less fluid experience in interactive apps
Client builds with JS (React & co)
  • Fluid interfaces, no full page reloads
  • Same API can feed web, mobile, other systems
  • More JavaScript for the browser to download and run
  • SEO needs extra care (solved by Next.js, lessons 7-8)

Neither one is "correct" — they're tools for different problems. In practice, what you'll see in the next lessons is that frameworks like Next.js exist precisely to combine both models in the same application, choosing case by case where each piece of the page should be assembled.

For the next lesson: now that you know where client, server, and build tools fit in, Lesson 02 will detail exactly what runs on each side — and why that split is the most important architectural decision of any project.
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.

Lição 01 · Semana 1

Como a web funciona hoje: cliente, servidor, build tools e onde cada peça do "stack moderno" entra

Antes de aprender React, Next.js, Supabase ou qualquer outra ferramenta, você precisa ter um mapa mental claro de quem faz o quê quando você acessa um site. Sem esse mapa, cada ferramenta nova vira um nome solto sem lugar para encaixar.

O modelo básico: cliente e servidor

Toda a web roda sobre uma ideia simples: existe uma máquina que pede algo (o cliente) e uma máquina que responde (o servidor). Quando você digita um endereço no navegador, isso acontece:

Navegador (cliente)
→
Requisição HTTP
→
Servidor
→
Resposta (HTML/JSON/etc)
→
Navegador renderiza

O cliente é, na grande maioria dos casos, o navegador — mas também pode ser um app mobile, outro servidor, ou um script fazendo uma chamada de API. O servidor é qualquer máquina configurada para escutar requisições e devolver uma resposta. Isso pode ser um servidor físico numa sala fria em algum lugar, ou — o que é bem mais comum hoje — uma função que roda por alguns milissegundos numa nuvem e depois "desliga".

Esse par cliente/servidor é a fundação de tudo. React, Next.js, Vercel, Supabase — todas essas ferramentas existem para tornar esse ciclo de pedido-e-resposta mais rápido, mais organizado ou mais barato de manter. Nenhuma delas substitui esse modelo; todas vivem dentro dele.

O que o servidor de fato guarda e faz

Um servidor web moderno geralmente cuida de três responsabilidades:

  1. Lógica de negócio — regras que decidem o que pode ou não acontecer (ex: "um usuário não pode comprar mais itens do que existem em estoque").
  2. Acesso a dados — ler e escrever num banco de dados (isso é o que SQL faz, tema que a Lição 11 vai destrinchar).
  3. Entrega de conteúdo — devolver HTML já pronto, ou dados em JSON para o cliente montar a tela.

É essa terceira responsabilidade — como o conteúdo é entregue — que separa a web "clássica" da web que você vai estudar nas próximas lições.

Web clássica: servidor manda HTML pronto

No modelo mais antigo (e ainda extremamente comum), o servidor monta a página HTML completa e a envia pronta para o navegador. O navegador só precisa exibir. Isso é o que WordPress, PHP puro ou aplicações Django/Rails fazem por padrão.

Web moderna: cliente monta a página com JavaScript

A partir dos anos 2010, ganhou força um modelo diferente: o servidor manda um HTML quase vazio + um monte de JavaScript, e é esse JavaScript, rodando no navegador do usuário, que monta a interface, busca dados via API e atualiza a tela sem precisar recarregar a página inteira. Esse é o modelo que React popularizou, e é a razão de existir de praticamente tudo que você vai estudar nessa trilha.

Ponto-chave: "frontend" e "backend" não são tecnologias — são lugares onde o código roda. Frontend roda no dispositivo do usuário (navegador). Backend roda numa máquina que você controla. A confusão que a maioria dos iniciantes tem é achar que certas linguagens são "de frontend" ou "de backend" — na verdade, hoje, JavaScript roda confortavelmente nos dois lados.

Build tools: por que seu código precisa ser "processado" antes de rodar

Aqui entra uma peça que confunde muita gente: se o navegador já entende HTML, CSS e JavaScript nativamente, por que quase nenhum projeto moderno escreve código "cru" que vai direto pro navegador?

A resposta é que, hoje, o código que você escreve raramente é o código que o navegador recebe. No meio do caminho existe uma etapa chamada build (compilação/empacotamento), feita por ferramentas de build. Elas resolvem problemas práticos:

Sem build tool
  • Você escreve JSX (a sintaxe do React) e o navegador não entende isso nativamente
  • Cada arquivo JS é um request HTTP separado — lento com muitos arquivos
  • Código moderno (ES2023) pode não rodar em navegadores mais antigos
  • CSS e imagens não são otimizados automaticamente
Com build tool
  • JSX/TypeScript são convertidos para JavaScript puro que o navegador entende
  • Múltiplos arquivos são agrupados ("bundle") em poucos arquivos otimizados
  • Código é "traduzido" (transpilado) para versões de JS mais compatíveis
  • Imagens, CSS e fontes passam por otimização automática

Ferramentas como Vite, Webpack ou o build interno do Next.js fazem esse trabalho. Você escreve código legível e organizado em vários arquivos; a build tool entrega ao navegador uma versão compacta, compatível e rápida de carregar. Isso acontece toda vez que você roda comandos como npm run build ou npm run dev.

Onde cada peça do "stack moderno" entra

Com o modelo cliente/servidor e o conceito de build tools claros, o mapa das próximas lições fica assim:

Mapa da trilha
  • React (lições 4–5) — biblioteca para construir a interface que roda no cliente, organizada em componentes.
  • Next.js (lições 6–8) — um framework construído em cima do React que decide onde cada parte do seu código roda (cliente ou servidor) e cuida do build automaticamente.
  • Vercel / Netlify (lições 9–10) — plataformas que hospedam o resultado do build e rodam suas funções de servidor sem você precisar administrar uma máquina.
  • SQL / bancos de dados (lições 11–14) — onde os dados realmente vivem, acessados pelo código que roda no servidor.
  • Supabase (lição 15) — um pacote pronto de banco de dados + autenticação + storage, para não montar cada peça do backend na mão.
  • Figma / Framer (lições 17–20) — ferramentas de design que se conectam ao código através de tokens, componentes e (no caso do Framer) até publicação direta.

Exemplo prático: os três estágios de uma mesma página

Para fixar a ideia, imagine uma página simples que mostra "Hoje são X graus". Veja como ela existiria nos dois modelos:

1. Servidor manda HTML pronto (modelo clássico)

<!-- O servidor já calculou a temperatura e devolve isso -->
<html>
  <body>
    <p>Hoje são 24°C</p>
  </body>
</html>

O navegador não faz nada além de exibir. Se a temperatura mudar, é preciso recarregar a página inteira para ver o novo valor.

2. Cliente busca dados e monta a tela (modelo moderno com React)

function Clima() {
  const [temperatura, setTemperatura] = useState(null);

  useEffect(() => {
    fetch("/api/clima")
      .then(res => res.json())
      .then(data => setTemperatura(data.temp));
  }, []);

  return <p>Hoje são {temperatura ?? "..."}°C</p>;
}

Aqui, o servidor só devolve dados brutos ({"temp": 24}) através de uma API, e é o JavaScript rodando no navegador do usuário que decide como exibir isso. A vantagem: essa mesma função pode atualizar a temperatura a cada minuto sem recarregar a página, e o mesmo endpoint de API pode alimentar tanto o site quanto um app mobile.

3. O papel do build tool nesse meio

O código do passo 2 usa useState, useEffect e uma sintaxe (JSX) que mistura HTML com JavaScript. Nenhum navegador entende isso diretamente. Antes de chegar ao usuário, uma build tool transforma esse código em algo assim:

function Clima(){var e=useState(null),t=e[0],temperatura=e[0],setTemperatura=e[1];
return useEffect(function(){fetch("/api/clima").then(function(r){return r.json()})
.then(function(d){setTemperatura(d.temp)})},[]),React.createElement("p",null,
"Hoje são ",temperatura??"...","°C")}

Compacto, sem espaços desnecessários, e usando apenas sintaxe de JavaScript que qualquer navegador entende. Você nunca escreve isso à mão — é exatamente esse trabalho repetitivo que Vite, Webpack e o build do Next.js automatizam.

Prós e contras dos dois modelos

Servidor manda HTML pronto
  • Mais simples de entender e depurar
  • Ótimo para SEO (buscadores leem o HTML direto)
  • Funciona mesmo com JavaScript desativado
  • Cada interação pode exigir recarregar a página
  • Experiência menos fluida em apps interativos
Cliente monta com JS (React e cia)
  • Interfaces fluidas, sem recarregar a página inteira
  • Mesma API pode alimentar web, mobile, outros sistemas
  • Mais JavaScript para o navegador baixar e executar
  • SEO exige cuidado extra (resolvido por Next.js, lição 7-8)

Nenhum dos dois é "certo" — são ferramentas para problemas diferentes. Na prática, o que você vai ver nas próximas lições é que frameworks como Next.js existem justamente para combinar os dois modelos na mesma aplicação, escolhendo caso a caso onde cada pedaço da página deve ser montado.

Para a próxima lição: agora que você sabe onde cliente, servidor e build tools entram, a Lição 02 vai detalhar o que especificamente roda em cada lado — e por que essa divisão é a decisão arquitetural mais importante de qualquer projeto.
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.