Bem-vindo ao dpw 2026!

Depois de muitos anos, o blog finalmente ganhou uma versão completamente nova: dpw2026!

Não foi um simples redesign ou uma troca de tema, foi uma reconstrução do zero, repensando cada parte, da stack ao sistema de conteúdo, da arquitetura de estilos à experiência de leitura.

A seguir, veja as decisões técnicas por trás da nova versão do blog, a stack escolhida e os motivos que guiaram cada escolha.

Por que reconstruir do zero?

A versão anterior do blog, rodando em WordPress, já havia cumprido seu papel; o cenário do desenvolvimento web evoluiu bastante, e ainda mais com o surgimento de novas tecnologias e tendências.

Queríamos algo que fosse:

• Rápido de verdade, não só “rápido para um blog”
• Simples de manter, sem dependências pesadas ou abstrações desnecessárias
• Agradável de escrever, com suporte a componentes no meio do conteúdo
• Portável, caso, no futuro, queiramos trocar de stack/plataforma

Aliás, o último ponto foi o motivo de demorarmos tanto a ter uma nova versão; o WordPress é uma excelente plataforma, mas, com certeza, dá uma travada na portabilidade.

Um dos maiores trabalhos para esta nova versão foi lidar (e fazer muitas correções) com as exportações de conteúdo do WP. E olha que usamos ferramentas de terceiros e bastante ajuda de IA.

A stack do dpw 2026

Vamos ao que interessa. Aqui está a stack principal do dpw2026.

Astro: o coração

O Astro é um framework focado em sites orientados a conteúdo. Exatamente o caso de um blog.

Ele entrega HTML totalmente estático, por padrão, com zero JavaScript no cliente (a menos que se opte explicitamente por usar).

Alguns pontos que fazem o Astro brilhar:

• Output 100% estático: o blog é gerado em build time, sem servidor, sem runtime, sem custo de infraestrutura
• Roteamento baseado em arquivos: a estrutura de pastas é a estrutura de URLs (simples e previsível)
• Content Collections: sistema tipado para gerenciar os posts do blog com validação de schema via Zod
• Suporte nativo a componentes: Astro tem um esquema de componentização próprio, usando componentes .astro com estilo/comportamento encapsulado, sem precisar de React, Svelte ou qualquer framework de UI no bundle final (embora ele dê suporte a todos estes).

MDX: Markdown turbinado

Os posts são escritos em MDX, que é basicamente Markdown com superpoderes: a possibilidade de usar componentes diretamente no conteúdo.

Isso significa que, no meio de um artigo, podemos usar:

• Um vídeo do YouTube com <YouTube hash="..." />
• Uma dica destacada com <Tip type="idea">...</Tip>
• Um embed do CodePen com <Codepen slug="..." />
• E outros mais

Tudo isso sem gambiarras com shortcodes ou HTML cru no Markdown.

O MDX torna o conteúdo flexível sem sacrificar a legibilidade do arquivo fonte.

Expressive Code: blocos de código bonitos e funcionais

Para um blog que, frequentemente, mostra códigos no artigos, fazer isso através de uma bela apresentação é essencial.

O Expressive Code cuida disso com:

• Syntax highlighting com temas diversos
• Números de linha opcionais
• Títulos de arquivo nos blocos de código
• Diff highlighting, marcação de linhas e mais

O resultado são blocos de código que não apenas ficam bonitos, mas são realmente úteis para quem está lendo.

Por exemplo, um bloco de código comum fica assim:

1
.c-header {
2
  align-items: center;
3
  background-color: var(--color-surface);
4
  display: flex;
5
  justify-content: space-between;
6
  padding: 1rem 2rem;
7
}

E quando queremos mostrar alterações no código, o diff highlighting entra em ação:

.c-component {
  background-color: var(--color-primary);
  padding: 1rem;
  padding-block: 1rem;
  padding-inline: 2rem;
}

Bem mais claro do que descrever as mudanças por texto ou repetir blocos de código quase inteiros.

Claude Code: o cérebro

O Claude Code foi o copiloto durante toda a construção do blog — e, neste caso, “copiloto” é um eufemismo; ele foi mais um co-desenvolvedor do que uma simples ferramenta de autocomplete.

Um dos maiores destaques fica para a migração do conteúdo do WordPress. Exportações de WP produzem códigos estranhos e caótico, cheio de shortcodes legados (e malformados), formatações inconsistentes e estruturas que não se traduzem diretamente para MDX.

O Cláudio ajudou a limpar, reorganizar e converter esse conteúdo de forma estruturada, economizando horas de trabalho manual.

Todos sabemos das incríveis — e também assustadoras — mudanças que a IA está trazendo para o mercado de trabalho…

Principalmente na área de TI, a maioria já se conformou com “junte-se a eles”, então, o jeito é aprender a usar bem as ferramentas, aumentando significativamente a produtividade sem abrir mão do controle sobre o que está sendo construído.

SCSS com arquitetura ITCSS

Para os estilos globais, optamos por usar SCSS organizado seguindo a arquitetura ITCSS (Inverted Triangle CSS).

A ideia é estruturar o CSS em camadas ordenadas por especificidade:

01-settings/   → Variáveis e design tokens
02-tools/      → Mixins e funções
03-generics/   → Resets e normalize
04-elements/   → Estilos base de elementos HTML
05-objects/    → Primitivos de layout
06-layouts/    → Layouts de página
07-components/ → Estilos compartilhados entre componentes
99-utilities/  → Classes utilitárias

Tudo usando CSS Layers (@layer) para controle explícito da Cascata. Isso elimina aquela dor de cabeça clássica de “Por que esse estilo está sendo sobrescrito?!”, conforme explicamos no vídeo:

Na Arquitetura CSS escolhida, estilos específicos de cada componente ficam no <style>, escopado no próprio componente Astro, e ITCSS reservado para o que é genuinamente global.

Pagefind: busca estática sem servidor

A busca no blog é feita com o Pagefind, que indexa o conteúdo em build time e oferece busca no cliente sem depender de nenhum serviço externo.

Custo zero, funcionando offline e rápido, cumprindo muito bem seu papel.

O tipo de solução que combina perfeitamente com um site estático.

TinaCMS: CMS visual com Git

Para gerenciar o conteúdo com mais conforto, foi usado TinaCMS, que funciona como um CMS headless com edição visual, mas armazena tudo direto no repo.

Isso significa que é possível editar posts numa interface amigável, mas os arquivos .mdx continuam sendo a fonte de verdade, versionados no Git como qualquer outro código.

Sitemap e RSS

Recursos clássicos, mas importantes: o blog gera automaticamente um sitemap XML e um feed RSS, garantindo que mecanismos de busca e leitores de feed possam acompanhar o conteúdo sem atrito.

Aliás, assina o feed do blog aí. :)

Funcionalidades que fazem diferença

Além da stack, algumas funcionalidades merecem destaque.

Responsividade

Tamanhos de fonte e espaçamentos com Utopia, um sistema de escala fluida que usa clamp() para interpolar valores entre dois breakpoints definidos.

Em vez de declarar tamanhos fixos por breakpoint com media queries, o Utopia gera uma escala contínua: o valor se altera suavemente conforme o tamanho da viewport.

É uma versão mais sofisticada do quê foi mostrado no artigo sobre clamp().

Table of Contents inteligente

Cada artigo tem um sumário lateral (em “desktop”) que é gerado automaticamente a partir dos headings h2 e h3.

A lógica é simples: se o heading for um h2, ele é adicionado ao sumário; se for um h3, ele é adicionado ao sumário do heading h2 pai.

O destaque do tópico atual também acompanha o scroll, indicando qual seção se está lendo no momento.

Âncoras copiáveis nos headings

Todos os headings do post têm links de âncora que podem ser copiados com um clique (que aparece no hover).

Essa funcionalidade é especialmente útil para compartilhar uma seção específica do artigo.

Decisões de projeto

Algumas escolhas merecem contexto adicional:

Por que não usar Tailwind? Em primeiro lugar, por preferência pessoal. Depois, por já termos familaridade pelo SCSS com ITCSS porque já tenho um workflow bem consolidado e queria total controle sobre a arquitetura de estilos.

Por que Astro e não Next.js, Nuxt, etc.? Para um blog estático, frameworks full stack são overengineering. O Astro foi projetado exatamente para esse caso de uso e não exige carregar um framework de UI inteiro no cliente.

Por que MDX e não Markdown puro? A flexibilidade de poder usar componentes no conteúdo é um diferencial enorme. Embeds de vídeo, callouts, componentes interativos etc. Tudo isso sem comprometer a experiência de escrita.

O que vem por aí

A depender de quando está lendo este artigo, pode ficar a impressão de que o visual ainda está “liso”, quase como o de um whitelabel.

Você não está totalmente errado e, apesar de ter sido feito do absoluto zero, sem quaisquer templates, ele ainda está bem puro.

O blog está no meio de um processo de rebranding, mas não queríamos esperar mais para colocar essa nova versão no ar. Já tinha passado da hora.

E, se você chegou até aqui, obrigado pela leitura e seja bem-vindo ao dpw 2026.

Muito obrigado e a gente se vê pela web!