Astro é um retorno aos fundamentos da web

"Astro é o melhor framework para desenvolvedores"

• Astro é um novo framework web otimizado para sites centrados em conteúdo, oferecendo por padrão uma política de Zero JavaScript, excelente desempenho e uma experiência de desenvolvimento simples
• Com uma abordagem única chamada Island Architecture, aplica JavaScript apenas onde é necessário, enquanto o restante é entregue como HTML estático rápido
• Sites feitos com Astro apresentam tempos de carregamento mais de 40% melhores do que abordagens tradicionais baseadas em React, trazendo ganhos práticos em SEO, experiência do usuário e taxa de conversão
• Diferente de outros frameworks, a lógica de dados e os componentes de frontend são claramente separados, e ele pode ser combinado com vários frameworks como React e Vue
• Porém, em casos que exigem SPA, gerenciamento de estado complexo ou roteamento em larga escala, frameworks tradicionais como Next.js podem ser mais adequados

---

O que é Astro

• Astro é um framework web que surgiu em 2021 e, ao contrário dos frameworks JS tradicionais voltados a apps complexos, foi projetado com foco em sites centrados em conteúdo
• Sua filosofia central é "conteúdo em primeiro lugar, servidor em primeiro lugar, Zero JavaScript por padrão", e sua tooling também se destaca por ser intuitiva e fácil de usar

Island Architecture

• Astro introduz o conceito de "Island Architecture", aplicando JavaScript apenas a partes necessárias da página, em vez da página inteira
• Em páginas como posts de blog, em que a maior parte é texto, tudo é renderizado apenas em HTML, e somente áreas que precisam de interação, como comentários ou carrosséis, carregam JS
• Isso faz com que as páginas sejam extremamente rápidas e leves

Desempenho e efeitos práticos

• Sites baseados em Astro registram carregamento mais de 40% mais rápido do que frameworks React tradicionais
• Essa melhora de desempenho se converte em resultados de negócio, como ranking em mecanismos de busca, satisfação do usuário e taxa de conversão
• Em dispositivos lentos e redes de baixa velocidade, a diferença de velocidade é ainda mais perceptível

Experiência do desenvolvedor (Developer Experience)

• O setup do projeto é simples, e um assistente amigável chamado “Houston” orienta o processo
• Componentes Astro permitem lógica executada apenas em build time (por exemplo, busca de dados e chamadas de API)
• Sem precisar se preocupar com gerenciamento de estado complexo, ciclo de vida ou hooks, é possível usar JS no cliente apenas quando necessário

Compatibilidade com vários frameworks

• É possível misturar livremente frameworks principais como React e Vue com Astro
• Exemplo: painel administrativo em React, visualização de dados em Vue e o restante em Astro

Recursos práticos que realmente funcionam

• É possível importar Markdown diretamente como se fosse um componente
• Suporte a pipeline de build moderno, incluindo TypeScript, Sass, otimização de imagens e hot module replacement
• É possível escolher entre site estático / SSR / renderização híbrida, aplicando a melhor opção de forma flexível conforme o projeto

Onde Astro brilha

• Sites de marketing, blogs, catálogos de e-commerce e portfólios centrados em conteúdo apresentam desempenho excelente
• É ideal em ambientes que não exigem gerenciamento complexo de estado no cliente

Trade-offs

• Em projetos onde SPA, roteamento complexo ou compartilhamento de estado entre componentes são importantes, outros frameworks como Next.js podem ser mais adequados
• O ecossistema ainda é menor, e o roteamento baseado em arquivos pode parecer limitado em projetos grandes

Como começar rapidamente

• npm create astro@latest my-site
• Se necessário, adicione frameworks com npx astro add react
• Adicione páginas em src/pages/ e componentes em src/components/, e então comece o desenvolvimento

O significado do Astro

• Em um momento em que frameworks JS estão cada vez mais complexos, Astro representa um retorno aos fundamentos da web (experiências rápidas, acessíveis e centradas em conteúdo), sem abrir mão da praticidade no desenvolvimento
• Sua filosofia de design — "sites rápidos por padrão, interatividade só onde for necessária, liberdade para usar o framework que você quiser" — agrada aos desenvolvedores
• De blogs a e-commerce, Astro é altamente recomendável para projetos centrados em conteúdo

[GN⁺]

Comentários do Hacker News

• Os frameworks web tradicionais sempre “hidratavam” a página inteira com JavaScript; por exemplo, mesmo que um post simples de blog tivesse só um único widget interativo, tudo era tratado com JavaScript. Já o Astro usa HTML estático por padrão e faz apenas as partes necessárias funcionarem como “ilhas de JavaScript”. Antigamente, essa abordagem era chamada de “progressive enhancement” ou simplesmente de “página web”, e esse era o padrão na criação de sites. Depois surgiram as SPAs e o uso de progressive enhancement foi diminuindo. Agora chamam isso de “ilhas de JavaScript”, mas no fim é só um retorno ao jeito antigo. Eu gostaria de recomendar o conceito de progressive enhancement para desenvolvedores web iniciantes interessados nisso.

  • Muitas vezes alguém ouve a descrição das funcionalidades de uma ferramenta nova e acha por engano que é a mesma coisa que já existia antes. Mas o verdadeiro valor do Astro está em conseguir integrar diferentes frameworks JavaScript e fazer com que apenas subárvores específicas do HTML sejam tratadas separadamente. Nesse processo, o estado inicial é renderizado como string e hidratado no cliente com dados previamente carregados. Isso brilha quando você quer usar frameworks como React/Svelte/Solid/Vue apenas em partes da página e pré-carregar os dados no servidor. Ainda assim, isso não é “progressive enhancement”. O HTML antes da hidratação não precisa funcionar corretamente. Por exemplo, um <form> não precisa funcionar sem JavaScript. São justamente esses detalhes que você percebe quando aborda o tema com curiosidade em vez de cinismo.

  • Concordo totalmente. O Astro é uma ferramenta incrível, mas a parte mais difícil foi entender todos os termos criados por desenvolvedores contratados depois de 2010 para explicar como a web funciona.

  • Não é um conceito novo, mas o jeito atual parece muito mais refinado. Antigamente eu fazia web interativa com PHP e jQuery, antes da era React e das SPAs. Pensando agora, arquiteturalmente o jeito antigo era mais elegante, mas naquela época depuração e DX eram realmente ruins. Não tenho nenhuma vontade de voltar ao tempo em que eu passava horas depurando frontend em PHP. SPAs ainda têm utilidade em dashboards complexos e apps interativos. O Astro melhora muito a DX porque permite gerenciar código de servidor e cliente em um só lugar, com separação clara, sem precisar ficar fazendo parse em PHP para passar dados ao JS.

  • Lembro da época em que chamávamos isso de AJAX. Parece que a conversa perdeu completamente o rumo.

  • Acho que os frameworks web iniciais realmente acertavam em cheio na abordagem de sites sem estado e renderização no servidor.

• Pessoalmente, recomendo muito o Astro. No começo eu via como uma “ferramenta que só adiciona includes a html e css”, mas depois de usar na renovação do meu site pessoal e do site da Matrix Conference, foi um prazer usar sem complicação nenhuma.
  Principais vantagens do Astro:

  • continua centrado em html e css
  • depois do build, js não é necessário por padrão
  • dá para adicionar js seletivamente só onde há interatividade
  • o recurso de content collections é bem organizado
  • a otimização de velocidade é extremamente boa, e os mantenedores sabem muito bem o que estão fazendo
  • há uma Devbar para desenvolvimento que mostra visualmente onde o site pode ficar mais rápido (por exemplo, lazy load de imagens na parte inferior da tela)
  • o minificador de CSS faz inline de parte do CSS para reduzir queries extras
  • o componente de imagem define automaticamente atributos de width/height para evitar content layout shift e também fornece imagens responsivas

  • Se o Astro é centrado em html e css e só adiciona js quando necessário, então criar .html, .css e .js direto no diretório e publicar daria a mesma experiência. Na verdade, isso não seria até mais rápido, sem overhead no tempo de desenvolvimento nem bloat desnecessário? Além disso, não lembro de inline de CSS ter sido um grande problema real de performance. Em experiência com centenas de sites, CSS quase nunca foi gargalo; na prática, o problema era a rede.

  • Meu único incômodo foi que, à medida que o roteamento ficava mais complexo, o nível de abstração aumentava rápido demais e acabava gerando mais confusão. Como complexidade sempre traz atrito, no fim escolhi outra abordagem.

  • Se você precisa de “função de include para html e css”, basta ativar server-side includes em um servidor web comum como o nginx. É uma solução estável há mais de 20 anos e quase não exige manutenção. Também não traz riscos extras de segurança como um template engine. Dá para evitar redundância e fazer includes puros sem se preocupar com vulnerabilidades de backend.

  • Depois de 20 anos trabalhando só com dados/backend, voltei por causa de um projeto frontend. Sofri com React, mas migrar para Astro+Svelte foi um enorme sucesso. Como é centrado em HTML/CSS, a estrutura do código é previsível e limpa, e mesmo quando entreguei o frontend para um desenvolvedor experiente em React, ele se adaptou quase imediatamente.

• Ver a expressão “framework tradicional” sendo usada para se referir a frameworks de SPA/Virtual DOM me faz sentir o choque geracional. Backbone e jQuery eram os verdadeiros frameworks web tradicionais, e eram justamente eles que funcionavam como o post descreve.

  • Acho que “tradicional” no fim depende de quando você nasceu. Para mim, a internet tradicional é modem 56k, fóruns vbulletin, mods de GTA:VC, IRC etc. Para uma geração mais antiga, seria BBS; para uma mais jovem, Discord seria a internet “tradicional”. Na política existe algo parecido: todo mundo tende a achar que a época boa foi quando era jovem.

  • Lembro do Backbone como algo voltado a SPA pura, buscando MVC no cliente.

• Tenho curiosidade sobre por que frameworks SSR como Astro e NextJS não suportam páginas estáticas com rotas dinâmicas como o SvelteKit. Por exemplo, uma página como /todos/[todoId] não pode entrar diretamente em um static bundle no NextJS. Já no SvelteKit isso funciona com 404.html; na prática é um 404, mas funciona perfeitamente em ambientes como Cloudflare ou webviews mobile. Esse recurso é especialmente útil ao empacotar para webviews mobile.

  • Concordo em parte, mas esse design também tem desvantagens. Se você der hard reload em uma URL como /todos/123 em uma SPA, o servidor vai tentar pedir o arquivo correspondente. Se ele não existir, recebe 404. Então a página 404 precisa refazer o carregamento e tratar tudo com roteamento no cliente, e isso exige configuração do servidor HTTP, como no nginx. Ou seja, não funciona com arquivos estáticos puros. Além disso, pelo spec HTTP, o cache do navegador nunca armazena respostas 404. Então em hard reload ou acesso por favorito, nunca dá para usar cache. Se essa configuração for pesada demais, talvez seja melhor usar query parameters e tratar como /todo?id=123.

  • Posso ter entendido errado, mas já implementei rotas/páginas dinâmicas até em static build do Next e do Astro. Ao usar CMS como contentful ou storyblok, deixávamos o editor criar livremente rotas e componentes, e cobriamos tudo com o padrão [...slug]. Usávamos a função getStaticPaths para pré-gerar todas as páginas. Se você ativar as opções de ISR/ISP, páginas desconhecidas no build time também podem ser pré-renderizadas dinamicamente. No Next isso se chama dynamic routes; no Astro, dynamic pages.
    Referência: Next dynamic routes, Astro dynamic pages

  • Talvez eu tenha entendido errado, mas a função getStaticPaths do Astro parece oferecer exatamente o que você quer.
    Referência

  • Eu também gosto de deploy estático, então, só como referência: o NextJS também suporta geração de parâmetros estáticos.

  • Não tenho certeza se entendi completamente o Astro ou os vários frameworks, mas talvez valha a pena olhar se as server islands do Astro são parecidas com o que você procura.

• Sinto que a própria discussão sobre frontend é confusa demais. O que o artigo está dizendo no fim se resume a “vamos usar o navegador como HMI ou como runtime de aplicação?”. Mas a maior parte da discussão fica em afirmações vagas como “é fresco” ou “carrega rápido”. Acho o clima de promoção de frameworks como se fossem marcas muito parecido com a indústria da moda.

  • Eu diria que a própria indústria da moda é a melhor analogia para explicar discussões sobre frameworks frontend. Quase ninguém analisa tecnicamente com rigor afirmações como “content-driven” ou “server-first”.

  • Não entendo dizer que “carrega rápido” é uma ilusão. Isso é um fator realmente importante.

• Recentemente fiz o site de uma instituição médica com Astro, e foi muito mais fácil do que quando eu fazia com Wordpress. Além disso, dá para hospedar de graça em lugares como Netlify, então nem preciso me preocupar com invasões. Também criei um CMS simples baseado em git, para que o cliente possa editar o conteúdo diretamente. Dá para sentir que o desenvolvimento web realmente evoluiu muito.

  • Foi algo que você fez a pedido de algum conhecido? Tenho curiosidade de como você consegue trabalhos para criar sites de instituições médicas.

  • Só cuidado porque a cobrança de banda do Netlify é mais cara que a da Vercel.

• A maior vantagem do Astro é que ele permite trabalhar só com HTML ou Web Components, sem depender de outros frameworks como React ou Vue. Ainda assim, o Astro também suporta SSR, ISR, SSG e middleware, assim como Next e Nuxt.
  O diferencial está na arquitetura de ilhas, que permite implementar micro frontends.
  Por exemplo, mesmo que equipes diferentes dentro de uma empresa façam separadamente checkout, carrinho e página de produto, tudo pode ser integrado em uma única página. Também dá para controlar diretamente a estratégia de renderização e compartilhar estado global, então cada equipe pode desenvolver e publicar sua parte de forma independente com responsabilidade de ponta a ponta.
  Claro, esse tipo de estrutura é uma solução necessária só em projetos grandes. Se cada time usar React de um jeito diferente, versões variadas acabam se misturando; com uma separação arquitetural como a do Astro, esse problema pode ser resolvido.
  Pessoalmente, não tenho certeza se isso vai mudar totalmente a web. Para mim, parece mais Next/Nuxt sem a dependência do framework e com arquitetura de ilhas adicionada. Mesmo assim, recomendo experimentar.
  Se você quer sair de React/Vue e migrar para web-component, ou substituir Next/Nuxt, o Astro é uma boa opção para uma transição gradual.

• Para mim, o Astro não é perfeito em todas as situações. Em alguns casos, quando só preciso de offline rendering, não há motivo para forçar o uso de JavaScript.
  A arquitetura de ilhas também tem limites, e muitas vezes o resultado do build acaba inline demais.
  Sinceramente, acho que muito do hype do Astro vem mais do Vite. O Vite é realmente excelente.

  • Eu gostaria de perguntar em que momento exatamente “a arquitetura de ilhas bate em seus limites”.

• Eu preferiria que Next.js não fosse recomendado como framework padrão de React. O frontend precisa de mais pensamento crítico. Remix (React Router v7) e TanStack são alternativas muito melhores.

  • Também concordo. O Next.js de fato tinha potencial, mas sinto que piorou bastante depois da entrada da Vercel. Uso desde a v10 e, depois de passar pela fase caótica da v13 até a v15, fiquei muito decepcionado. React e Next.js mudam rápido demais para acompanhar, e muitas vezes parece haver mais mudança pela mudança do que mudança realmente necessária.

  • Eu queria até parar de recomendar o próprio React como framework padrão. Para desenvolvimento frontend, HTML/CSS/JS me parece muito melhor.

  • Acho que Remix/React Router v7 está indo na direção certa. Em especial, se o Remix usar preact e se centrar mais em web standards, talvez volte uma forma mais sólida de construir sites. Mas a transição de Remix para RR7 não foi suave, e tive de reescrever o projeto.

• Acho que os princípios fundamentais da web continuam válidos. Para quem desenvolve com PHP, Spring, Quarkus ou ASP.NET MVC, talvez não fique tão claro o quanto o ambiente de desenvolvimento web baseado em frameworks JS se tornou difícil. Por causa desse clima de indústria guiada por moda, sinto que não é fácil voltar ao básico.