Outra reescrita do site | xavd.id

Desde a sua criação em março de 2013, meu site (anteriormente conhecido como davidbrownman.com) passou por algumas revisões importantes. Era hora de outro.

Sua primeira versão era um único arquivo HTML com um pouco de CSS escrito por meu amigo Evan Hahn. Ele tinha um pequeno toque de cor (fora da marca Michigan) ao passar o mouse sobre os botões:

Em pouco tempo, adicionei jQuery para tornar os botões arrastáveis, o que parecia uma mágica absoluta na época.

No início de 2014, lancei um site redesenhado construído com Middleman, um gerador de sites estáticos baseado em Ruby. Isso me permitiu usar as habilidades de Haml e Sass que adquiri em meu último estágio. Também pedi a ajuda de um amigo para me ajudar com um web design com aparência profissional. Você ainda pode ver essa versão do site na máquina wayback.

Havia um blog neste momento, mas as postagens reais estavam no tumblr. Eles foram espelhados no site durante a etapa de construção. Eles não mudariam para redução até 2016, sobre o qual escrevi na época.

Isso funcionou bem durante anos, mas em 2020 não consegui mais construir meu site. Eu me afastei do ecossistema Ruby e não consegui depurar o problema. Em vez de gastar ainda mais tempo consertando a instalação do Ruby, era hora de reescrever.

Decidi portar o site para Gatsby, um gerador baseado em JavaScript que era popular na época. Eu estava fazendo muito mais JS na época, então me sentia mais confortável com essas ferramentas. Como um bônus adicional, ele usou JSX e React para gerar marcação, com a qual eu estava bastante familiarizado. Também redesenhei o site novamente, adotando um visual inspirado em Tron (e mais uma vez estilizado com Sass):

O próprio Gatsby era uma tecnologia interessante. Adorei a rapidez com que o site resultante pareceu, graças à maneira como ele pré-carregou as páginas em que você clicou em um link. Ele também lidou bem com as imagens, reduzindo-as durante a etapa de construção para maximizar a velocidade dos usuários.

Mas também foi complicado. Por exemplo, você tinha que usar GraphQL para recuperar dados (como postagens de blog) ao escrever páginas, uma tecnologia pela qual nunca fui fã. E um site cheio de recursos precisava de muitos plug-ins, aumentando drasticamente a área de superfície do código que precisava de manutenção.

Em fevereiro de 2023, a Netlify adquiriu Gatsby. Se você observar atentamente o gráfico de commit de Gatsby, poderá identificar quando isso aconteceu:

Embora seja possível que projetos de software estejam “completos”, Gatsby não estava. A web é um lugar em constante evolução e você realmente deseja construir algo que evolua com ela. A escrita estava na parede para a longevidade da biblioteca e era apenas uma questão de tempo até que seguisse o caminho da minha instalação do Middleman.

Naquele mês de outubro, decidi criar um blog dedicado ao Advent of Code. Depois de procurar geradores de sites estáticos, decidi potencializá-lo usando Astro, outro gerador de sites estáticos baseado em JS, mas com foco em ferramentas modernas, configuração mínima e geração de HTML simples.

E uau! As coisas simplesmente funcionaram, os plug-ins estavam disponíveis, mas longe de serem necessários, e estava em desenvolvimento ativo. Foi fácil transformar markdown em belos modelos de páginas com temas e componentes personalizados. Eles realmente acertaram em cheio na ergonomia de todas as operações importantes, proporcionando experiência de desenvolvedor incomparável e suporte TypeScript.

Uma semana depois, eu usaria o Astro novamente para um projeto muito maior: construir meu site de avaliações. Mais uma vez, foi uma delícia de usar, permitindo-me iterar rapidamente e focar nas coisas que me interessam, sem lutar contra o framework. Continuei a manter esses dois sites por anos sem incidentes, apenas felicidade produtiva.

Nesse ínterim, meu site pessoal ainda foi escrito com Gatsby. Para seu crédito, tudo funcionou perfeitamente nos anos seguintes, mesmo sem as atualizações de Gatsby. Mas eu definitivamente evitava adicionar recursos ao site porque considerava a base de código em modo de manutenção.

Esta é minha casa na web e quero estar animado para trabalhar nela. Eu poderia ter continuado adiando, mas já era o suficiente. No espírito de terminando o que comeceiembarquei em uma reescrita usando, você adivinhou, Astro.

Meu principal objetivo, ao contrário das reescritas anteriores, era enviar um substituto imediato. Este é o seu próprio tipo de desafio, já que fazer com que uma coisa nova funcione exatamente como uma coisa antiga em todas as estruturas requer alguns ajustes. E, como acontece com todos os meus sites, quero que eles tenham o máximo de desconto possível. Operações simples (como postagens de blog ou novas páginas) não devem exigir configuração depois de configuradas. As coleções de conteúdo do Astro me permitem definir um esquema para o frontmatter do Markdown, garantindo que cada página tenha todas as propriedades que o resto do site espera. Isso ajuda a evitar surpresas na produção.

Estruturalmente, seria muito parecido david.reviews. Existem algumas páginas estáticas (home, contato, projetos) e uma grande pilha de páginas geradas (postagens de blog, postagens por tag, etc), quase todas escritas em Markdown. A semelhança significava que eu poderia me afastar de mim mesmo e evitar reinventar a roda quando precisasse lembrar exatamente como fiz um recurso funcionar.

Para começar, li os documentos do Astro que descrevem exatamente essa migração.

A primeira grande tarefa foi renderizar o site usando o Astro, por mais quebrados que fossem os detalhes. Passei um bom tempo descobrindo a quantidade mínima de trabalho que precisava para conseguir algo trabalhando novamente.

Isso se transformou em um problema de coloração de função, já que sempre que um layout atingia um componente JSX (que eu havia definido em .js arquivos; não tenho certeza de como isso funcionou), ele travaria. Então comecei a converter todos esses componentes para nativos .astro arquivos, começando com itens relacionados ao layout (que apareceram e travaram em todas as páginas).

A próxima edição foram meus ícones Font Awesome. Eles eram a moda em 2014, quando comecei a usá-los, e eram bastante padrão em 2020, quando os instalei no React, mas (na minha opinião) desde então, eles foram suplantados por pacotes de ícones mais simples que fornecem SVGs de bolsa. Então arranquei tudo isso e troquei para ícones do Lucide. Foi preciso um pouco de esforço para estilizá-los da mesma maneira, mas não foi algo que algumas propriedades de estilo comuns não pudessem consertar.

O último grande obstáculo foi renderizar componentes personalizados em meu conteúdo Markdown. A integração MDX do Astro é boa, mas algumas das configurações mais detalhadas podem estar um pouco subdocumentadas. Felizmente, eu já havia resolvido basicamente esse mesmo problema antes, quando adicionei artigos ao meu site de revisão.

A chave é renderizar sua redução com um mapa de componentes. Certas chaves podem ser usadas para substituir tags HTML integradas. O restante é disponibilizado nesse MDX sem importações adicionais, o que ajuda a manter as postagens do blog limpas:

// RenderedMarkdown.astro
import { render } from "astro:content";
import Link from "./Link.astro";
import InlineCode from "./InlineCode.astro";
import YoutubeEmbed from "./YoutubeEmbed.astro";
  renderable: Parameterstypeof render>(0);
const { renderable } = Astro.props;
const { Content } = await render(renderable);
    // these will be used in place of the generic
    // any other components here can be used in all mdx without imports
    // also add these in eslintrc

Este arquivo tem uma pequena camada extra de abstração porque tenho várias coleções de conteúdo baseadas em markdown. Este componente me permite registrar todos os componentes extras em um único lugar.

Embora o objetivo principal fosse que tudo correspondesse exatamente ao site antigo, fiz algumas pequenas correções. Meu favorito é um padrão que também usei no site de revisão: um auxiliar para carregar todos os posts em desenvolvimento, mas apenas os publicados em uma compilação de produção.

Eu costumava ter um draft: true propriedade frontmatter para impedir que postagens apareçam na lista de blogs e nos feeds RSS. Mas lembrar de adicionar essa linha e respeitá-la em todos os lugares em que interagi com o conteúdo do blog foi complicado. Publiquei acidentalmente (ou deixei de publicar) postagens mais de algumas vezes. Então peguei outra página do site de avaliação e desliguei tudo do datePublished propriedade. Se estiver faltando, a postagem deve ser um rascunho!

E para garantir que a lista seja consistente em todo o site, eu uso um auxiliar em vez do Astro getCollection('blog') diretamente:

import { type CollectionEntry, getCollection } from "astro:content";
export const sortableDateValue = (d?: string): number =>
  (d ? new Date(d) : new Date()).valueOf();
// https://docs.astro.build/en/guides/environment-variables/#default-environment-variables
export const isProdBuild = import.meta.env.PROD;
// https://docs.astro.build/en/guides/content-collections/#filtering-collection-queries
// everything in dev, published only in prod
export const getPublishedPosts = async (): Promise
  ArrayCollectionEntry"blog"> & { permalink: string }>
    await getCollection("blog", ({ data: { datePublished } }) =>
      isProdBuild ? datePublished : true,
      sortableDateValue(b.data.datePublished) -
      sortableDateValue(a.data.datePublished),

Agora, em qualquer lugar onde eu interaja com o conteúdo do blog, eu uso getPublishedPosts() e sempre fornece a lista exata e correta, independentemente do ambiente.

---

No geral, o projeto levou cerca de um mês do início ao fim. Teria sido mais rápido, mas tive tempo limitado para trabalhar nisso (por razões que se tornarão óbvias em breve).

O PR se fundiu em 20 de dezembro e, após algumas pequenas correções, funcionou perfeitamente. A maioria das páginas de conteúdo não precisou de nenhuma edição além da atualização de suas importações e consegui reutilizar quase todo o meu CSS.

O código está em muito bom estado, exceto uma coisa: tudo está ainda estilizado com Sass. Funciona bem, mas seu escopo global e anos de pequenos ajustes dificultaram sua manutenção eficaz. E em 2025, muitos dos recursos do Sass agora estão disponíveis nativamente em CSS moderno, então preciso muito menos dele do que quando o escrevi em 2020. Além disso, o Astro abrange todos os estilos no nível do componente, então os estilos globais são uma espécie de antipadrão em primeiro lugar.

Em algum momento aqui, irei migrar tudo para o Tailwind. Eu sei, eu sei, é outra estrutura. Mas é simples, rápido e se adapta à maneira como penso em estilizar as coisas. Também não sinto que esteja muito abstraído do CSS, já que estou usando esse conhecimento para escrever as classes do Tailwind em primeiro lugar. E eu adoro como é fácil estilizar as coisas condicionalmente. No Sass, você precisa de:

  @media (min-width: 1124px) {

Enquanto estiver no Tailwind, é tão simples quanto w-full lg:w-3/4. Os estilos específicos do modo escuro são igualmente fáceis, não exigindo que eu me lembre (ou sejamos realistas, encontre, copie e cole) @media (prefers-color-scheme: dark). O Tailwind me permite fazer o que sei, mas de maneira mais fácil e rápida.

Além disso, minhas notas de rodapé não estão mais funcionando. Não tenho certeza de qual é a diferença, mas meus estilos não estavam funcionando. Eu gostei deles estarem em linha, mas eu estava pronto para encerrar esse projeto e não valia a pena atrasá-lo.

Por último, não há garantia de que o Astro dure para sempre. Um dia eles poderão fechar a loja e eu voltarei ao ponto de partida. Provavelmente também será pior do que antes, já que muitos desses .astro os arquivos usam ferramentas específicas da estrutura que não são especialmente portáteis. Caramba, todo o arquivo usa um analisador personalizado. Será uma grande dor de cabeça mudar.

Mas até esse dia chegar, estou extremamente feliz com o Astro e seu ecossistema. Estou ansioso por muitos anos felizes.

---

editar (janeiro de 2026): Acabou de ser anunciado que o Astro foi adquirido pela Cloudflare, então meu timing foi impecável. Esperamos que esta aquisição corra melhor que a anterior! Caso contrário, verei você em alguns anos.