Pular para o conteúdo
Gustavo Tutorial

Frameworks

Esta trilha não é sobre trocar de ferramenta: é sobre enxergar o mesmo problema resolvido de outras formas e saber julgar cada uma.

Revisão já conversamos sobre isso Novo ainda não vimos 4 partes · 13 tópicos

Nenhum tópico com esse filtro.

PARTE 1

Outras formas de construir

O que você não usa hoje — e por isso mesmo vale entender. Aqui o objetivo não é trocar de ferramenta: é enxergar o mesmo problema resolvido de três jeitos e saber julgar cada um.

O mesmo card em três abordagens

Novo

Um card de drink, com nome, ingredientes e um selo de “sem álcool”. Mesmo resultado visual, três caminhos.

1. HTML puro — o seu jeito

vanilla
<article class="card">
  <h3 class="card__nome">Pantanal</h3>
  <p class="card__ingredientes">maracujá · hortelã · tônica</p>
  <span class="card__selo">sem álcool</span>
</article>

<style>
  .card { padding: 20px; border: 1px solid #ddd; border-radius: 6px; }
  .card__nome { font-size: 20px; margin: 0 0 6px; }
  .card__selo { font-size: 11px; text-transform: uppercase; color: #7A1C30; }
</style>

Para dez drinks, você repete o bloco dez vezes — ou gera com map() a partir de um array, como vimos na Parte 5.

2. React — componente com propriedades

react
function Card({ nome, ingredientes, semAlcool }) {
  return (
    <article className="card">
      <h3 className="card__nome">{nome}</h3>
      <p className="card__ingredientes">{ingredientes.join(' · ')}</p>
      {semAlcool && <span className="card__selo">sem álcool</span>}
    </article>
  );
}

// usando com uma lista
<div className="carta">
  {drinks.map(d => <Card key={d.nome} {...d} />)}
</div>

O card virou uma função que recebe dados. O {semAlcool && ...} é a forma do React de dizer “só mostre se for verdadeiro”. O key é obrigatório em listas — é como o React identifica cada item quando algo muda.

3. Tailwind — estilo direto na marcação

tailwind
<article class="p-5 border border-gray-300 rounded-md">
  <h3 class="text-xl mb-1.5">Pantanal</h3>
  <p class="text-gray-600">maracujá · hortelã · tônica</p>
  <span class="text-xs uppercase text-red-900">sem álcool</span>
</article>

Não existe arquivo de CSS: cada classe é uma propriedade. Rápido de escrever, e a marcação fica longa.

CritérioVanillaReactTailwind
Precisa de buildNãoSimSim (ou CDN, limitado)
Repetir 10 vezesGera com mapTrivialIgual ao vanilla
Mudar o estilo de todosUma regra CSSUma regra CSSEditar cada elemento
Ler o HTML depoisLimpoMisturado com lógicaPoluído de classes
Abre sem servidorSimNãoNão
Envelhece bemMuitoExige manutençãoExige manutenção
O que essa comparação deve deixar claro: nenhuma das três é melhor em abstrato. O React ganha quando existem muitos componentes com estado mudando; o Tailwind ganha quando várias pessoas mexem no mesmo projeto e ninguém quer brigar por nome de classe; o vanilla ganha quando o projeto é pequeno, precisa durar e não deve depender de nada.

Pensar em componentes

Novo

Esta é a ideia que vale levar de volta para o HTML puro, mesmo sem nunca usar framework. Componente é uma unidade fechada: aparência, comportamento e dados no mesmo lugar, sem depender de onde foi colocada.

nomeando como componente (BEM)
/* bloco */          .card { }
/* elemento */       .card__titulo { }
                     .card__selo { }
/* modificador */    .card--destaque { }
                     .card--sem-foto { }

Essa convenção — chamada BEM — resolve dois problemas de uma vez: o nome diz a que componente a regra pertence, e a especificidade fica sempre baixa e igual, então nada briga com nada.

Web Components — componentes de verdade, sem framework

O navegador permite criar suas próprias tags. Não é comum em landing page, mas é a resposta nativa ao problema que o React resolve.

javascript
class BotaoZap extends HTMLElement {
  connectedCallback() {
    const numero = this.getAttribute('numero');
    const texto  = this.getAttribute('texto') || 'Falar no WhatsApp';
    this.innerHTML =
      `<a class="botao" target="_blank" rel="noopener"
          href="https://wa.me/${numero}">${texto}</a>`;
  }
}
customElements.define('botao-zap', BotaoZap);
usando
<botao-zap numero="5567999999999" texto="Pedir orçamento"></botao-zap>
A lição transferível: mesmo sem Web Components, organize seu CSS por componente e não por página. Um bloco /* === CARD === */ com tudo sobre o card junto é a versão simples dessa ideia — e é o que torna o copiar-e-colar entre projetos confiável.

Começando um projeto com Vite

Novo

Se um dia você quiser experimentar React ou trabalhar com arquivos separados e build, o caminho de entrada hoje é o Vite. Vale fazer uma vez só para ver como é.

terminal
npm create vite@latest meu-projeto
# escolha "Vanilla" para JS puro, ou "React"

cd meu-projeto
npm install
npm run dev      # servidor local, recarrega ao salvar
npm run build    # gera a pasta dist/ pronta para publicar
Pasta / arquivoO que é
index.htmlA página. Aqui ele fica na raiz, não escondido
src/Seu código-fonte
public/Arquivos copiados sem processamento (favicon, imagens)
dist/O resultado do build — é isso que vai pro servidor
node_modules/Dependências baixadas. Nunca vai pro Git
O que muda no seu dia: você deixa de abrir o arquivo e passa a rodar um comando. Em troca ganha recarga automática, imports entre arquivos e minificação no build. Para landing page única, é troca ruim; para um projeto com muitas telas, é troca óbvia.

Tailwind na prática

Novo CSS

Vale entender porque é o que você mais vai encontrar em vaga, tutorial e projeto de terceiro. A ideia: em vez de nomear componentes, você compõe a partir de classes de uma propriedade cada.

a lógica das classes
p-4          padding: 1rem
px-6         padding esquerda e direita: 1.5rem
mt-2         margin-top: 0.5rem
text-xl      font-size: 1.25rem
font-bold    font-weight: 700
flex         display: flex
gap-4        gap: 1rem
md:flex-row  vira linha a partir do breakpoint médio
hover:bg-red-900   muda o fundo no hover

Os prefixos são a parte inteligente: md:, hover:, dark:, focus: aplicam a classe só naquela condição — sem escrever media query nem pseudo-classe.

Ganha emPerde em
Velocidade de escritaHTML fica longo e difícil de ler
Nunca inventar nome de classeMudar todos os botões exige editar cada um
Consistência forçada por uma escalaExige build para funcionar bem
CSS final pequeno (remove o não usado)Curva até decorar as abreviações
Não use a versão CDN em produção. Ela compila no navegador do visitante, o que é lento e pesado. A CDN serve para testar e aprender; num projeto real, Tailwind precisa do build que remove as classes não usadas.
O que dá para roubar sem adotar: a escala de espaçamento. Tailwind usa múltiplos de 4px, e obrigar-se a isso — 4, 8, 12, 16, 24, 32, 48 — elimina aquele espaçamento de 13px que só existe porque ficou parecendo certo na hora. Dá para fazer isso com variáveis CSS no seu arquivo único.
PARTE 2

Geradores de site estático

O formato que faltava entre HTML puro e framework. Provavelmente o próximo passo natural de quem entrega arquivo único hoje.

O problema que eles resolvem

Novo

Um cliente pede quinze páginas. Em HTML puro, o menu é copiado quinze vezes. Quando ele quiser trocar um item, são quinze arquivos para editar — e basta esquecer um para o site ficar inconsistente.

A saída óbvia parece ser React ou Next. Mas React resolve um problema diferente: manter tela e dados em sincronia enquanto a pessoa interage. Num site que não muda depois de carregado, isso é peso sem contrapartida.

Gerador de site estático resolve exatamente o problema que existe: você escreve pedaços reutilizáveis, ele monta as páginas finais, e o que vai pro ar é HTML pronto. Mesmo resultado do seu arquivo único — rápido, sem framework no navegador, indexável — só que sem a cópia manual.

o espectro completo
HTML puro        → 1 a 5 páginas, conteúdo fixo, zero build
                   (o que você faz hoje)

Gerador estático → 5 a 500 páginas, conteúdo repetitivo,
                   ainda sem framework no navegador

Framework (SPA)  → estado complexo, dados mudando em tempo real,
                   área logada

Framework + SSR  → tudo acima, com conteúdo dinâmico
                   e SEO importante

Astro

Novo

É o que faz mais sentido para quem vem do HTML puro, porque a sintaxe é quase HTML. Cada arquivo é uma página; cada componente é um pedaço de marcação com um bloco de código no topo.

um componente
---
// tudo entre os traços roda na hora de gerar, não no navegador
const { nome, ingredientes, semAlcool } = Astro.props;
---

<article class="card">
  <h3>{nome}</h3>
  <p>{ingredientes.join(' · ')}</p>
  {semAlcool && <span class="card__selo">sem álcool</span>}
</article>

<style>
  /* este CSS vale só para este componente */
  .card { padding: 20px; border: 1px solid var(--linha); }
</style>
usando
---
import Card from '../components/Card.astro';
import { drinks } from '../dados/drinks.js';
---

<div class="carta">
  {drinks.map(d => <Card {...d} />)}
</div>
CaracterísticaO que significa na prática
Zero JavaScript por padrãoO site final é HTML e CSS. Nada roda no navegador a menos que você peça
Sintaxe próxima do HTMLA curva de aprendizado é curta para quem já escreve HTML
CSS por componenteAcaba o medo de nome de classe colidindo
Rotas por arquivosrc/pages/contato.astro vira /contato
Ilhas de interatividadeDá para usar React só num componente específico, se precisar
Conteúdo em MarkdownBlog e artigos viram arquivos de texto, sem CMS
O que muda no seu dia: você passa a rodar npm run dev em vez de abrir o arquivo, e npm run build gera a pasta que sobe pro servidor. Em troca, o menu existe em um lugar só.

Eleventy, Hugo e os demais

Novo
GeradorPerfilBom quando
AstroModerno, componentes, ecossistema grandeSite com componentes e alguma interatividade
EleventyMinimalista, flexível, quase sem opiniãoVocê quer controle total do HTML final
HugoEscrito em Go, absurdamente rápidoMilhares de páginas; build em segundos
Next.js / NuxtFramework completo que também gera estáticoJá usa React ou Vue e quer as duas coisas

Para o tipo de projeto que você faz, a escolha real é entre Astro e Eleventy. Astro se você quer componentes e uma estrutura mais guiada; Eleventy se você quer que o HTML final seja exatamente o que você escreveu, sem camada nenhuma.

O que você perde ao adotar qualquer um deles: a entrega deixa de ser um arquivo que abre com dois cliques. Passa a exigir Node instalado, npm install e um comando de build. Para landing page única, isso é perda líquida. A partir de cinco páginas com partes repetidas, o ganho supera.
PARTE 3

Interatividade sem framework

Para quando o JavaScript puro começa a ficar repetitivo, mas React seria exagero. Duas ferramentas que funcionam via CDN, sem build.

Alpine.js

NovoJS

Reatividade escrita em atributos, direto no HTML. Cerca de 15KB, via CDN, sem etapa de build — cabe no seu formato de entrega.

menu, contador e aba com zero JavaScript escrito
<script defer src="https://cdn.jsdelivr.net/npm/alpinejs@3/dist/cdn.min.js"></script>

<!-- menu que abre e fecha -->
<div x-data="{ aberto: false }">
  <button @click="aberto = !aberto" :aria-expanded="aberto">Menu</button>
  <nav x-show="aberto" @click.outside="aberto = false">
    <a href="#sobre">Sobre</a>
  </nav>
</div>

<!-- FAQ em acordeão -->
<div x-data="{ atual: null }">
  <template x-for="(p, i) in perguntas">
    <div>
      <button @click="atual = atual === i ? null : i" x-text="p.titulo"></button>
      <p x-show="atual === i" x-text="p.resposta"></p>
    </div>
  </template>
</div>

A vantagem sobre JavaScript puro aparece quando há vários estados na mesma página: menu aberto, aba selecionada, filtro ativo, modal visível. Em JS puro isso vira um monte de classList.toggle espalhado; no Alpine, o estado fica declarado ao lado do elemento.

A troca: o HTML fica mais poluído e o site passa a depender de uma biblioteca externa. Se o CDN cair ou a pessoa estiver sem JavaScript, nada funciona — o que reforça a regra de sempre ter um caminho alternativo para o essencial.

htmx

NovoJS

Filosofia diferente: em vez de trazer dados e montar a tela no navegador, o servidor devolve HTML pronto e o htmx troca o pedaço da página.

html
<button hx-post="/contato"
        hx-target="#resposta"
        hx-swap="innerHTML">
  Enviar
</button>

<div id="resposta"></div>
<!-- o servidor responde com HTML; o htmx coloca ali dentro -->

Faz sentido quando existe servidor do outro lado — PHP, Python, Node. Para site estático, quase não se aplica. Vale conhecer porque é uma corrente forte hoje entre quem acha que o front-end ficou complexo demais, e porque combina com a lógica de serverless da trilha de Back-end.

Qual usar, e quando não usar nenhum

Novo
SituaçãoEscolha
Um menu e um formulárioJavaScript puro. Não instale nada
Vários estados independentes na mesma páginaAlpine
Página que conversa com servidor sem recarregarhtmx
Interface com muitos componentes e estado compartilhadoAí sim, framework
Um critério honesto: conte quantas vezes você escreveu classList.toggle no projeto. Até umas cinco, JavaScript puro está bom. Acima disso, o código começa a ficar difícil de seguir, e uma ferramenta que declara estado passa a compensar.
PARTE 4

Construtores visuais e o resto do mercado

O que seus concorrentes usam, o que os clientes já ouviram falar, e como se posicionar sem competir em preço.

WordPress, Webflow, Framer, Wix

Novo
FerramentaO que éForçaFraqueza
WordPressCMS com tema e plugin; move uma fatia enorme da webCliente edita sozinho; ecossistema gigante; barato de achar quem mexeLento se malcuidado; exige atualização constante; alvo comum de invasão
WebflowEditor visual que gera código de verdadeResultado limpo; CMS embutido; bom para designerMensalidade; sair de lá depois é trabalhoso
FramerVem do design, virou publicador de sitesAnimação nativa e boa; muito rápido para landing pageMensalidade; menos controle fino
Wix / SquarespaceConstrutor para o dono do negócio montar sozinhoBarato; ninguém precisa de vocêResultado genérico; performance fraca; pouco controle
Por que conhecer: é com isso que você compete no orçamento do cliente. Quando ele diz "meu sobrinho faz no Wix por 300 reais", você precisa saber exatamente o que ele ganha e o que perde — senão a conversa vira briga de preço, que você perde.

Como se posicionar — e quando indicar o concorrente

Novo

Competir com construtor visual em preço é perder. O que você vende é diferente, e vale nomear a diferença.

O que você entrega que eles não entregam

  • Estratégia. A arquitetura de seções derivada das objeções reais do cliente. Template não faz isso.
  • Performance de verdade. Página que carrega em um segundo no celular, sem os quilos de script que vêm de fábrica.
  • Sem mensalidade de plataforma. O arquivo é dele e roda em qualquer lugar.
  • Nada de genérico. Um site que não parece com mais dez mil.
  • Uma pessoa responsável. Com nome, que atende quando quebra.

Quando indicar outro caminho é a resposta certa

Se o cliente vai publicar conteúdo toda semana, se ele quer um catálogo com centenas de produtos, se ele precisa de loja com pagamento e estoque, ou se o orçamento simplesmente não comporta trabalho sob medida — dizer isso na cara é melhor que aceitar e entregar mal.

Isso costuma render mais, não menos. Cliente que recebe uma recomendação honesta contra o seu próprio faturamento lembra de você — e indica. E você fica com os projetos em que seu trabalho realmente faz diferença, em vez de manutenção de WordPress por preço baixo.

Servidor tradicional e HTML de e-mail

Novo

Renderização no servidor à moda antiga

PHP com Laravel, templates de Django, Rails. Não são modernos, mas movem uma parte enorme da web brasileira — e é o que você vai encontrar se pegar manutenção de site existente. O modelo é simples e ainda válido: o servidor monta o HTML e manda pronto. É, no fundo, a mesma ideia do gerador estático, só que na hora do pedido em vez de na hora do build.

HTML de e-mail

Um mundo à parte, e vale saber que existe antes de aceitar o trabalho achando que é como fazer uma página.

Na webNo e-mail
Flexbox e GridTabelas aninhadas, como em 2005
CSS em arquivo ou <style>CSS inline em cada elemento
Fontes do GoogleFontes do sistema, com sorte
JavaScriptNenhum
Testar em três navegadoresTestar em dezenas de clientes de e-mail
Se um cliente pedir newsletter, o caminho sensato quase nunca é escrever HTML de e-mail à mão: é usar o editor da própria ferramenta de envio, que já resolveu a compatibilidade. Cobrar por isso como se fosse uma página é subestimar o trabalho — e fazer à mão sem experiência é entrar num buraco.