Se você acompanha canais de desenvolvimento no Youtube, provavelmente, já esbarrou com alguma chamada (em alguns casos meio exagerada) sobre o Astro, esse barulho todo começou depois que foi lançada a versão 1.0 do Astro, teoricamente estável.
Depois de ver tantas chamadas (mesmo antes de ver os vídeos), a curiosidade me obrigou a pesquisar o que era. e ao chegar no site do Astro dou de cara com isso:
Quem me conhece sabe que o Next JS foi o framework que me fez abraçar definitivamente Javascript como linguagem de programação (sempre achei o React puro um problema sério para criação de sites e fui responsável por alguns projetos grandes deixarem de usar o React por causa de vários problemas que o React tem).
O NextJs resolvia vários desses problemas que não me deixavam nem pensar em considerar o React como uma alternativa viável para meus projetos.
E chegando no site do Astro vejo essa imagem prometendo todas as vantagens do Next, com um desempenho absurdamente maior, promete um desempenho de HTML puro, isso seria algo incrível, a facilidade de desenvolvimento do em framework Javascript com desempenho de página HTML estática, onde eu assino?
O que é o Astro?
O Astro é um gerador de sites estáticos, é difícil chamá-lo de framework, ele seria mais um meta-framework, uma vez que uma das funcionalidades alardeadas é o Bring your own Framework, ou seja, traga seu próprio framework.
É isso mesmo, você pode continuar usando seus componentes React para construir o site com o Astro.
Mas a maior funcionalidade e o que faz o Astro estar tão hypado é, justamente, a geração de de sites estáticos, os sites quando são implementados são puramente HTML e CSS, com Javascript somente onde você disser para o framework colocar Javascript, isso é chamado de Astro Island, ou seja, ilhas de elementos com Javascript cercados de HTML puro por todos os lados.
Esse conceito é bem interessante e manda para o bundle de produção muito pouco ou nenhum Javascript, o que gera o desempenho impressionante dos sites gerados pelo Astro.
O Astro é tão performático, mesmo?
Para poder confirmar o desempenho do Astro e apaziguar o desespero de testar todos os frameworks do mundo (essa é uma doença que adquiri depois de abraçar o Javascript, sempre fui meio resistente a usar frameworks quando usava prioritariamente PHP ou outras linguagens tradicionais de backend, mas parece que quanto mais se usa o JAMStack, mais a frameworkite ataca), converti esse site de Next Js + WordPress para Astro + WordPress.
Ao invés de pegar um projeto pronto no github ou um projeto de exemplo, resolvi usar este site como laboratório. Dei uma estudada no Astro e vi alguns tutoriais de conversão do Next para Astro e cheguei a conclusão que daria para aproveitar uns 90% – 95% do código que já tinha pronto, uma vez que você pode usar código React no Astro com o comando:
npx astro add reactAlias, olhe os guias de integração, tem muita coisa legal lá.
Mas eu queria fazer do jeito Astro de fazer, então resolvi começar do zero, peguei um tema gratuito com uma temática Web3 e NFTs e fui refazer o site todo. A única coisa que reaproveitei foram as funções para trazer os posts do WordPress usando o Graph QL, pois isso não faria diferença nenhuma para o resultado final.
E o resultado final foi esse:
Sim, a diferença é assustadora, isso considerando que o layout atual é bem mais pesado que o anterior.
De onde vem tanta diferença de desempenho?
A resposta é simples: Javascript no cliente.
O Next JS gera páginas estáticas ou geradas no servidor, com base nos dados vindos do WordPress (estou escrevendo este artigo no WordPress, agora). Essa página com todo o markup (HTML e CSS) gerados no servidor é depois servida pela Vercel de maneira muito otimizada, o que já deixa com uma performance excelente.
Mas existe uma “pegadinha”, o Next JS carrega junto com a página todo o Javascript necessário para o React Hydration que consiste, de maneira extremamente resumida, em “re-montar” a página com dados novos, depois que ela é aberta pelo navegador com possíveis dados novos e é o que faz o React e outros frameworks reativos serem tão populares e amados por desenvolvedores.
Todo esse javascript tem um custo e, em alguns casos, bem altos, no caso desse blog, a quantidade de Javascript do bundle chegava a ser maior que todos os dados necessários para exibir a página (incluindo as imagens), ou seja, para páginas com quase nenhuma necessidade de mudar uma vez que estavam montadas no servidor, carregava um caminhão de código para remontar a página.
Ao passar para o Astro, resolvi que montaria toda a página no momento do build e não haveria mais nenhuma alteração depois, portanto, não deixei passar quase nenhum Javascript para lado do cliente. Vou adicionar mais coisas com o tempo o que deve derrubar um pouco este score, mas a diferença da quantidade de dados carregadas é assutadora.
Vale a pena migrar do Next JS para o Astro JS e usar ele para tudo?
A resposta simples é: não, mas em muitos projetos isso fará uma diferença gigantesca.
Mas como assim, com essa vantagem toda de desempenho não vou migrar tudo para Astro?
Na verdade a resposta é razoavelmente simples e se deve a:
- O Next é um framework full stack, ao contrário do que muita gente acha ele não é só um framework para frontend, pois vem com todas as ferramentas para criação de aplicações backend e aplicações fullstack. Por exemplo, o backend para a nova aplicação da CoinShopp, estou desenvolvendo todo com o Next, será o Next que vai fazer todo o meio campo entre banco de dados, APIs e blockchain que são necessários para a nova versão da aplicação da CoinShopp.
- SSR: Apesar de existir a opção de fazer isso no Astro, o Next está mais maduro nessa área, fazer um novo build todas as vezes que existe um conteúdo novo pode ser um grande problema para sites que a produção de conteúdo é muito grande e no caso do Astro, SSR é tudo ou nada (ou o site todo é SSR ou todo estático). A funcionalidade do Next de permitir SSR e SSG coexistirem é uma das coisas mais incríveis do mesmo. Por exemplo, no Pinkfire, onde o volume de criação de conteúdo é muito alto e o volume de conteúdo já existente, não dá para abrir mão do uso de SSR e SSG nas mesmas rotas ou o site ia passar o tempo todo fazendo rebuild.
- Maturidade no geral, o Astro ainda é uma criança entre os frameworks, acabou de sair a versão 1.0 e tem muita coisa que pode dar errada, muitas bibliotecas que gosto de usar que não simplesmente funcionam como no caso do Next, etc…
- Escalabilidade, o Astro, atualmente, é espetacular para sites pequenos, mas não consigo imaginar em um site com dezenas de milhares de páginas e que o volume de criação de conteúdo seja muito alta, vamos ver se futuramente ele permitirá mesclar SSR com SSG, o que resolveria grande parte desse problema de escalabilidade.
Onde o Astro brilha?
Mesmo com esses detalhes, estou apaixonado pelo Astro e, definitivamente, fará parte das implementações futuras de sites meus ou de clientes. Em alguns casos ele, simplesmente, faz muito mais sentido que outros frameworks. e quais são esses casos:
- Sites prioritariamente estáticos ou que a produção de conteúdo é pequena. Esse blog, por exemplo, devo fazer uma média de um post por semana, se muito, então o custo de build não é nada.
- Landing pages, a criação de uma página, por mais complexa que seja, é bem fácil de fazer no Astro, se não tiver a necessidade de muitos dados externos, então, é praticamente escrever HTML + CSS puros.
- Sites institucionais que linkam para apps mais completas, a nova versão da CoinShopp, por exemplo, o site institucional pretendo fazer em Astro, usando MDX (que o Astro tem suporte nativo) e o Backend, Store e App, vão ficar em Next.
- Sites que a maior parte das regras de negócio fiquem fora do próprio site (sites com integração com a blockchain, sites que consumam APIs etc…)
Quais as maiores vantagens do Astro?
Nem só de desempenho vive um desenvolvedor, então listei algumas das principais vantagens que achei até agora no Astro:
Traga seu próprio framework
Curva de aprendizado bem próxima de zero, você consegue continuar desenvolvendo as aplicações da maneira que já está acostumado e é mais produtivo.
Mais que isso, o Astro permite misturar frameworks, quer usar na mesma página componentes React e Vue? Sem problemas, só instalar os dois adaptadores e usar, funciona que é uma beleza.
Suporte nativo a MDX
Isso é lindo, a página de política de privacidade, nem me dei ao trabalho de puxar do WordPress, simplesmente criei usando Markdown copiando o conteúdo da página original do WP. Inclusive estou pensando, seriamente em passar esse site todo para MDX, usando um CMS baseado em Markdown, como o Netlify CMS, por exemplo, o gerenciamento e a manutenção do site fica extremamente simples.
Daria até para gerenciar o site só com o github, usando o VS Code para editar os arquivos.
Funcionalidades de requisição de dados
A simplicidade que o Astro criou para pegar dados é assustadora, o código todo da home desse site é:
---
import Layout from '../layouts/Layout.astro';
import PostsList from '@layouts/PostsList.astro';
import Hero from '@layouts/Hero.astro';
import { getsPostsList } from 'src/helpers/getPosts';
import projetos from '@data/projetos.json';
import ProjectsList from '@layouts/ProjectsList.astro';
const postsList = await getsPostsList();
const projectsList = projetos.slice(0, 6);
---
<Layout
title="Bruno Alves | Desenvolvedor Fullstack | Marketing Online"
description="Curioso e autodidata estou envolvido com tecnologia desde que me connheço por gente"
>
<Hero bt2={{ hide: true }} />
<PostsList posts={postsList} />
<ProjectsList projetos={projectsList} />
</Layout>Sim, top level await, nada de ficar criando malabarismos com funções assíncronas, para poder dar fetch.
Aquela primeira parte entre as duas linhas de --- é onde colocamos o código todo para usar no resto do template que é muito, mas muito similar ao JSX.
Há e dá pra fazer fetch dentro de componentes, o que é lindo.
Uso com javascript client side
Isso é algo bem chato no Next, quando usamos javascript client side, existe uma chance muito grande de ter problemas de hidratação, onde a página gerada no cliente tem markup diferente da gerada pelo servidor, o que costuma dar vários erros.
Como o Astro gera as páginas como arquivos estáticcos, não temos esse problema, basta usar a função set:html para inserir o JS que quiser no lado cliente e ter zero problemas.
Por exemplo, para inserir o Google Tag Manager no Next, preciso usar um pacote específico para isso ou usar useEffect para não ter problemas de hidratação ou problemas de funcionamento do GTM.
No Astro bastou criar um componente GTM.astro com o seguinte código:
---
const gtmCode = `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-MGLHXSL');
`;
---
<!-- Google Tag Manager -->
<script set:html={gtmCode}></script>
<!-- End Google Tag Manager -->Coloquei esse componente no Layout.astro e pronto, nenhum erro, seja de hidratação, seja do GTM
Então o Astro vale esse hype todo?
Na verdade, sim. Em geral novos frameworks geram um enorme hype, graças a frameworkite e logo são esquecidos ou ficam relegados a utilidades de nicho e quase todo mundo volta para os frameworks mais maduros e robustos.
No caso do Astro ele resolve um problema que já era resolvido por outros frameworks (como Gatsby, Hugo, e tantos outros), mas fez isso de maneira muito bem feita, com uma estrutura muito parecida com o Next e com uma curva de aprendizado muito pequena para quem já está acostumado com outros frameworks javascript mais conhecidos.
Como eu disse, passou a ser uma ferramenta a ser considerada em todos os novos projetos, onde não preciso de todo poder de fogo do Next JS.