O que aconteceu no front-end enquanto você não estava olhando

kciter1 · 2026-07-20T02:12:58+09:00

Um artigo voltado a desenvolvedores que deixaram o front-end por volta de 2008, explicando as mudanças dos últimos 20 anos A tese geral é que toda ferramenta é um tecido cicatricial formado sobre um problema real (uma ferida), e que as soluções de cada camada criaram os problemas da camada seguinte, acumulando-se ao longo do tempo Ao longo do texto, um único é usado como amostra para acompanhar como os botões mudaram em cada época Layer I — jQuery (2006–2010) Começou da necessidade de alterar apenas partes da página sem recarregá-la inteira O jQuery eliminou diferenças entre navegadores e popularizou AJAX, mas criou o problema de os dados existirem tanto em variáveis JS quanto na tela, obrigando o desenvolvedor a sincronizá-los manualmente Essa manipulação manual do DOM é o “pecado original” que todas as camadas posteriores tentaram resolver Layer II — frameworks (2010–2015) UI declarativa: em vez de descrever o procedimento para atualizar a tela, descreve-se como a tela deve aparecer de acordo com os dados, e o framework cuida da atualização O React liderou a era com componentes + JSX + Virtual DOM, seguido por Vue/Angular/Svelte/Solid Hoje, todos os frameworks estão convergindo para o conceito de signals, que rastreia dependências e atualiza apenas o necessário Também existe uma vertente que retorna ao modelo de enviar HTML pelo servidor, como htmx, Alpine.js e Hotwire Layer III — build (2012–2018) Como o JS não tinha um sistema de módulos, CommonJS e ES Modules competiram; para compatibilidade com navegadores antigos, tornaram-se necessários o transpile com Babel e o empacotamento com webpack O build passou a incluir minificação, tree-shaking, divisão de código e geração de sourcemaps O preço foi o surgimento do node_modules, com até projetos starter vazios instalando cerca de 250 mil arquivos Layer IV — disputa de tooling (2018–2024) Foi a era em que builds lentos e configurações complexas do webpack foram resolvidos com reescritas em Go/Rust O esbuild (Go) tornou o bundling 10–100 vezes mais rápido, e o SWC (Rust) substituiu o Babel O Vite se consolidou como ferramenta padrão; o bundler de produção está sendo substituído pelo Rolldown, baseado em Rust, e a stack relacionada está sendo unificada sob a VoidZero (adquirida recentemente pela Cloudflare) Gerenciadores de pacotes como pnpm e Bun também seguem a mesma tendência Layer V — o retorno da renderização no servidor (2014–2026) Em SPAs, o servidor envia apenas uma div vazia, o que causava uma tela em branco no carregamento inicial e também fazia a página parecer vazia para mecanismos de busca A solução foi voltar a renderizar HTML no servidor, um retorno ao modelo de 2008 Surgiram SSR (renderização a cada requisição), SSG (pré-renderização no build) e ISR (SSG com atualização automática), conduzidos por meta-frameworks como Next.js, Astro, SvelteKit e Nuxt O custo de hydration, que “reativa” no navegador o HTML vindo do servidor, tornou-se o novo problema; Islands (Astro), Resumability (Qwik) e React Server Components surgiram como formas de reduzir a hydration Layer VI — ferramentas de engenharia (2015–2026) O TypeScript trouxe estabilidade para refatorações por meio de um sistema de tipos e se tornou o padrão de fato O Tailwind passou a liderar a estilização com classes utilitárias, enquanto o CSS nativo também evoluiu com nesting, variáveis, container queries e outros recursos, reduzindo a necessidade de tooling antigo O shadcn/ui consolidou a abordagem de copiar e possuir o código-fonte em vez de instalar componentes, e TanStack Query, Zustand, Zod, Vitest e Playwright compõem o vocabulário básico dos apps de 2026 Layer VII — deploy (2015–2026) Em vez de subir arquivos por FTP, conecta-se um repositório Git ao Vercel/Netlify/Cloudflare; a cada push, build e deploy são feitos automaticamente, e cada PR ganha uma URL de preview ao vivo Consolidaram-se os conceitos de funções serverless e edge, em que o código roda em centenas de data centers próximos dos usuários Layer VIII — IA (2023–2026) Ao descrever em linguagem natural para v0, Lovable ou Bolt, é gerado um front-end funcional, enquanto Cursor, Claude Code e Copilot escrevem código no lugar do desenvolvedor Engenheiros de backend/sistemas também passaram a conseguir criar front-ends em um dia, tornando mais difusas as fronteiras entre áreas da engenharia Ainda assim, o código gerado pressupõe conhecimento das oito camadas acima, e o objetivo do texto é preencher essa lacuna Bedrock — conclusão A direção da linha de frente em 2026 é renderizar HTML no servidor, enviar quase nenhum JS e aproveitar a plataforma web O texto conclui que, após desenhar um grande círculo ao longo de 20 anos, a indústria voltou a um ponto parecido com os arquivos que eram enviados por FTP

Um artigo voltado a desenvolvedores que deixaram o front-end por volta de 2008, explicando as mudanças dos últimos 20 anos
A tese geral é que toda ferramenta é um tecido cicatricial formado sobre um problema real (uma ferida), e que as soluções de cada camada criaram os problemas da camada seguinte, acumulando-se ao longo do tempo
Ao longo do texto, um único <button> é usado como amostra para acompanhar como os botões mudaram em cada época

Layer I — jQuery (2006–2010)
- Começou da necessidade de alterar apenas partes da página sem recarregá-la inteira
- O jQuery eliminou diferenças entre navegadores e popularizou AJAX, mas criou o problema de os dados existirem tanto em variáveis JS quanto na tela, obrigando o desenvolvedor a sincronizá-los manualmente
- Essa manipulação manual do DOM é o “pecado original” que todas as camadas posteriores tentaram resolver
Layer II — frameworks (2010–2015)
- UI declarativa: em vez de descrever o procedimento para atualizar a tela, descreve-se como a tela deve aparecer de acordo com os dados, e o framework cuida da atualização
- O React liderou a era com componentes + JSX + Virtual DOM, seguido por Vue/Angular/Svelte/Solid
- Hoje, todos os frameworks estão convergindo para o conceito de signals, que rastreia dependências e atualiza apenas o necessário
- Também existe uma vertente que retorna ao modelo de enviar HTML pelo servidor, como htmx, Alpine.js e Hotwire
Layer III — build (2012–2018)
- Como o JS não tinha um sistema de módulos, CommonJS e ES Modules competiram; para compatibilidade com navegadores antigos, tornaram-se necessários o transpile com Babel e o empacotamento com webpack
- O build passou a incluir minificação, tree-shaking, divisão de código e geração de sourcemaps
- O preço foi o surgimento do node_modules, com até projetos starter vazios instalando cerca de 250 mil arquivos
Layer IV — disputa de tooling (2018–2024)
- Foi a era em que builds lentos e configurações complexas do webpack foram resolvidos com reescritas em Go/Rust
- O esbuild (Go) tornou o bundling 10–100 vezes mais rápido, e o SWC (Rust) substituiu o Babel
- O Vite se consolidou como ferramenta padrão; o bundler de produção está sendo substituído pelo Rolldown, baseado em Rust, e a stack relacionada está sendo unificada sob a VoidZero (adquirida recentemente pela Cloudflare)
- Gerenciadores de pacotes como pnpm e Bun também seguem a mesma tendência
Layer V — o retorno da renderização no servidor (2014–2026)
- Em SPAs, o servidor envia apenas uma div vazia, o que causava uma tela em branco no carregamento inicial e também fazia a página parecer vazia para mecanismos de busca
- A solução foi voltar a renderizar HTML no servidor, um retorno ao modelo de 2008
- Surgiram SSR (renderização a cada requisição), SSG (pré-renderização no build) e ISR (SSG com atualização automática), conduzidos por meta-frameworks como Next.js, Astro, SvelteKit e Nuxt
- O custo de hydration, que “reativa” no navegador o HTML vindo do servidor, tornou-se o novo problema; Islands (Astro), Resumability (Qwik) e React Server Components surgiram como formas de reduzir a hydration
Layer VI — ferramentas de engenharia (2015–2026)
- O TypeScript trouxe estabilidade para refatorações por meio de um sistema de tipos e se tornou o padrão de fato
- O Tailwind passou a liderar a estilização com classes utilitárias, enquanto o CSS nativo também evoluiu com nesting, variáveis, container queries e outros recursos, reduzindo a necessidade de tooling antigo
- O shadcn/ui consolidou a abordagem de copiar e possuir o código-fonte em vez de instalar componentes, e TanStack Query, Zustand, Zod, Vitest e Playwright compõem o vocabulário básico dos apps de 2026
Layer VII — deploy (2015–2026)
- Em vez de subir arquivos por FTP, conecta-se um repositório Git ao Vercel/Netlify/Cloudflare; a cada push, build e deploy são feitos automaticamente, e cada PR ganha uma URL de preview ao vivo
- Consolidaram-se os conceitos de funções serverless e edge, em que o código roda em centenas de data centers próximos dos usuários
Layer VIII — IA (2023–2026)
- Ao descrever em linguagem natural para v0, Lovable ou Bolt, é gerado um front-end funcional, enquanto Cursor, Claude Code e Copilot escrevem código no lugar do desenvolvedor
- Engenheiros de backend/sistemas também passaram a conseguir criar front-ends em um dia, tornando mais difusas as fronteiras entre áreas da engenharia
- Ainda assim, o código gerado pressupõe conhecimento das oito camadas acima, e o objetivo do texto é preencher essa lacuna
Bedrock — conclusão
- A direção da linha de frente em 2026 é renderizar HTML no servidor, enviar quase nenhum JS e aproveitar a plataforma web
- O texto conclui que, após desenhar um grande círculo ao longo de 20 anos, a indústria voltou a um ponto parecido com os arquivos que eram enviados por FTP

O que aconteceu no front-end enquanto você não estava olhando

Leituras relacionadas

4 comentários