Una introducción a Astro Framework: ventajas y desventajas

Contenido

• Introducción

• Características

• Representación del lado del servidor

  1. Carga inicial
  2. Empezar Hidratación
  3. Finalizar Hidratación

• Rendimiento y experiencia de usuario (UX)

• Hidratación Parcial

• Tragamonedas

• inconvenientes

• Conclusión

Introducción

Astro es un nuevo marco que adopta un enfoque diferente para desafiar los patrones de representación existentes utilizados por muchos otros marcos (Gatsby, Next.js y Remix.run, por nombrar algunos).

Aunque el marco aún está en versión beta, las características que ofrece el equipo son bastante impresionantes hasta el momento. Aporta muchas ideas nuevas que creo que vale la pena analizar.

Puedo sentir que el equipo realmente trató de unir la experiencia del desarrollador (DX) y el rendimiento al aprovechar su propio compilador Astro .

En este artículo, discutiremos las características clave que ofrece Astro, luego profundizaremos en algunas de ellas en detalle.

Luego, pasaremos a la representación del lado del servidor (SSR) desde un nivel fundamental para formar una base para nuestra discusión sobre los conceptos presentados por Astro. Luego, pase a discutir cómo Astro hace las cosas de manera diferente.

Finalmente, veremos algunos de sus inconvenientes y para qué tipo de aplicación es más aplicable en este momento.

Características

• Características listas para usar
  • Plantillas (a través de "ranuras")
  • Diseños de página
  • Soporte de rebajas
  • Bloques de código
  • Buscar
  • Convención de enrutamiento del sistema de archivos (similar a Next.js)
  • Componente astronómico ( .Astro )
• Admite múltiples marcos (Vue.js, React.js, Svelte, Solid.js, etc.)
• Opt-in optimización de la interactividad
  • A través de las directivas de hidratación ( client:* - proporcionado por el compilador de Astro)
• Paginación
• RSS Feed

Representación del lado del servidor

El caso de uso para la representación del lado del servidor es mejorar el SEO para el rastreo del motor de búsqueda.

Esto se debe a que las aplicaciones de una sola página, o los sitios que solo se ejecutan en el lado del cliente, tienen dificultades para que los motores de búsqueda indexen sus datos, como metaetiquetas y otros detalles de gráficos abiertos.

Como resultado, sin el HTML generado que contiene estos detalles, tiene un gran impacto en la clasificación del sitio web cuando los usuarios buscan en Google.

Entonces, la representación del lado del servidor fue una solución a este problema. El proceso es así: se entrega un archivo HTML (junto con CSS y js) al usuario en la solicitud inicial, luego la aplicación del lado del cliente "hidratará" los elementos DOM.

Finalmente, una vez realizados todos los pasos anteriores, estará listo para observar las interacciones del usuario (es decir, los clics).

Echemos un vistazo a una visualización de este proceso para comprenderlo mejor.

1. Carga inicial (HTML, js, CSS)

Carga de la página inicial donde el usuario solo ve la página en blanco.

2. Comienza la hidratación

Aquí es donde el Javascript comienza a adjuntar los detectores de eventos DOM (es decir, Click, KeyPress).

En este punto, el CSS también debería estar cargado y disponible.

3. Finaliza la hidratación

Finalmente, habrá un tiempo entre el inicio y el final de la hidratación. Si está utilizando React (<18), entonces este proceso ocurre de una vez y está "bloqueando". Es decir, hidratará toda la aplicación. Entonces, solo cuando esté hecho, los usuarios podrán interactuar con él.

Para aplicaciones críticas para el rendimiento, esto puede marcar la diferencia, especialmente en dispositivos de gama baja y cuando se utiliza una conexión de red lenta (es decir, 3G).

Rendimiento y experiencia de usuario (UX)

Mirando los pasos anteriores de otra manera, se parece a lo siguiente en una línea de tiempo:

Como puede ver, hay un pequeño período entre First Content Paint (FCP) y Time to Interactive (TTI) en el que la aplicación cliente pasa por la fase de hidratación.

Esto afecta el rendimiento; a medida que su paquete se haga más grande, la solicitud tardará más en cargarse para hidratar su sitio/aplicación del lado del cliente.

Además, el rendimiento no es lo único que se ve afectado, la UX también se ve afectada. Cuanto más tarde el proceso de hidratación, más tiempo tardarán los usuarios en poder interactuar con su sitio web o aplicación web.

Esto puede ser frustrante para los usuarios que hacen clic en un elemento de la página mientras aún se está hidratando y no hace nada en absoluto.

Hidratación Parcial

Entonces, ¿cómo resuelve exactamente Astro este problema?

Lo hace a través de la hidratación parcial. Como mencioné en la sección de funciones, los sitios web creados con Astro son estáticos de forma predeterminada. Lo que significa que no se servirá ningún JS, y todos los JS se eliminarán durante el proceso.

⚠️ Nota: cuando decimos que "no se sirve JS", nos referimos a JS de nuestra aplicación y no a los paquetes de JS principales de Astro. Esto es necesario para cosas como diferir la carga y la hidratación de los componentes (cuando corresponda).

Es posible que se pregunte: "Ok, si se elimina JS de nuestra aplicación, ¿cómo se obtienen los eventos de clic en los botones?" ¡Gran pregunta!

Astro proporciona directivas que le permiten especificar explícitamente qué componente le gustaría hidratar y cuándo.

Además, Astro sigue la "Arquitectura de la isla" que tiene el beneficio de:

1. Permitir que los componentes se carguen independientemente unos de otros
2. Permitir que los componentes se rendericen de forma aislada

Proceso de hidratación (hidratación parcial/selectiva)

En este ejemplo, mientras que el resto de la página es estático, los componentes <Nav /> y <Button /> se hidratan durante la carga.

Beneficios

El beneficio de esto es el siguiente:

1. Sirviendo menos JS al cliente (paquete JS más pequeño)
2. "Islas" independientes para cargar e hidratar el componente de forma aislada en lugar de toda la aplicación

Ejemplo de esto:

Según los casos de uso, también puede usar client:visible , que carga e hidrata el componente solo cuando está visible. Hay algunas otras directivas; no dude en consultar la documentación.

Si solo quiere asegurarse de que su componente se hidrate durante la carga, entonces agregaría la siguiente directiva:

 <Nav client:load /> <Button client:load />

Para mí, con Astro, realmente puedes encontrar un buen equilibrio entre la velocidad que obtienes de HTML y el dinamismo de Javascript.

Es muy fácil optimizar el código a través de la directiva proporcionada. El compilador maneja todo el trabajo pesado. No es necesario escribir código adicional para manejar esto. ¡Eso es un gran problema!

📝 Referencia útil:

• Astro - Componentes interactivos de hidratación
• Astro - Arquitectura de la isla
• Astro - Hidratación Parcial
• Jason Miller - concepto de arquitectura de la isla

Tragamonedas

Otra característica que encontré interesante fueron las máquinas tragamonedas de Astro. Esto proporciona un primitivo más poderoso en comparación con los elementos secundarios y children de prop .

Sentí que la ranura era más similar a otras bibliotecas de plantillas como (Rails) erb , donde puede definir dónde van children diferentes componentes secundarios dentro del componente de diseño y dejar que el motor de plantillas haga el trabajo de representarlo en el lugar correcto.

Ejemplo

 // Card.tsx import * as React from 'react'; import { CardHeading, CardWrapper, } from '~/components'; interface CardProps {}; const Card: React.FC<CardProps> = (props) => { return ( <CardWrapper> <CardHeading> <slot name="card-heading"> </CardHeading> <CardImageWrapper> <slot name="card-image"> </CardImageWrapper> <CardFooter> <slot name="card-footer"> </CardFooter> </CardWrapper> ); }; // App.tsx import { Card, Footer } from '~/components'; import * as React from 'react'; interface AppProps {}; const App: React.FC<AppProps> = (props) => { return ( <Card> <div slot="card-heading"> <h2>Suzy</h2> </div> <div slot="card-image"> <img src="/images/cat-suzy.png" slot="card-image"> </div> <Footer slot="card-footer" /> </Card> ); };

Componente astronómico

Astro proporciona su propio componente que es muy similar a svelte (si lo ha usado antes).

Todo (HTML, js, CSS) está en un archivo y usa la extensión .Astro .

💡 Nota: dentro del componente Astro es donde puede importar y renderizar los diferentes componentes ( .vue , .tsx , .jsx , svelte )

Ejemplo

 --- const title = "this is my title"; --- <h1 class="title">{title}</h1> <style> .title { color: grey; } </style>

💡 Nota: ¡ El CSS en el componente astro está limitado al componente de forma predeterminada!

📝 Referencia útil:

• Astro - Estilismo

Obtención de datos

Dentro del bloque de secuencias de comandos de Astro, se admiten sintaxis comunes como await/async , typescript y fetch .

Obtener los datos es simple como lo que se destaca a continuación:

 --- interface PokemonResult { name: string; url: string; } interface PokemonResponse { count: number; next: string; previous: number | null; result: PokemonResult[]; } const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const data: PokemonResponse = await response.json(); const result: PokemonResult = data?.result ?? []; --- <ul> {(result) => <li>{result}</li>} </ul> <style></style>

📝 Referencia útil:

• Astro - Obtención de datos

Variables de entorno

Astro ofrece variables de entorno a través de archivos .env* . La convención que utiliza es muy similar a otros marcos.

Hay dos categorías de variables de entorno.

1. Público (en el lado del cliente): disponible en tiempo de ejecución, esto se puede definir a través del prefijo PULIC_*
2. Privado (en el servidor/compilación): disponible en el momento de la compilación, este es el valor predeterminado

⚠️ Todas las variables de entorno son privadas a menos que se definan explícitamente con el prefijo PUBLIC_

Uso

Archivo .env:

 UNSPLASH_API_KEY=xxxxxx

archivo astronómico:

 --- const requestUrl = 'https://api.unsplash.com/search/photos?page=1&per_page=15&query=surfing'; const response = await fetch(requestUrl, { headers: { 'Authorization': `Client-ID ${import.meta.env.UNSPLASH_API_KEY}` } }); const data = await response.json(); const results = data?.results || []; const images = results.map(images => images.urls); --- <section class="image-section"> <ul> {images.map((imageSizes) => ( <li class="image-container"> <img src={imageSizes.small} /> </li> ))} </ul> </section> <style></style>

📝 Referencia útil:

• Astro - Variables de entorno
• Astro - Obtención de datos

inconvenientes

El único inconveniente de Astro en esta etapa actual es que sus casos de uso se sienten un poco limitados.

Muchas de las funciones listas para usar, como bloques de código y rebajas, parecen estar muy enfocadas en la creación de blogs de desarrolladores. Estoy seguro de que esto es temporal solo para obtener la adopción de los desarrolladores, y luego se expandirá a otros casos de uso más adelante.

En cuanto a la compatibilidad con múltiples marcos, no se ha mencionado la compatibilidad con el enrutamiento y la gestión del estado ni parece que haya una solución potencial.

Esto es comprensible ya que el marco aún está en versión beta. Sin embargo, estoy emocionado de ver lo que el equipo ha planeado para los próximos lanzamientos.

Desafortunadamente, a pesar de lo impresionante que es hasta ahora, dudo en construir una aplicación grande con esto todavía debido a la falta de herramientas y ecosistema.

Sin embargo, eso no significa que no debas saltar y probarlo. La documentación es clara y fácil de entender.

Sigo creyendo que Astro introduce muchos conceptos nuevos e interesantes que se pueden aplicar independientemente de si está usando Astro o no.

Conclusión

En resumen, Astro es un proyecto que tiene una visión única de la creación de sitios web rápidos. Aporta muchas ideas nuevas que creo que probablemente polinizarán a otros marcos, lo cual es algo muy común.

Además, noté que hay un enfoque real en DX dentro de las funciones proporcionadas, lo cual realmente aprecio.

Comenzamos una discusión sobre los fundamentos para comprender mejor la representación del lado del servidor (SSR). luego lo desglosó aún más para comprender qué hace exactamente Astro de manera diferente que lo hace mejor y cómo eso afecta tanto el rendimiento como la experiencia de usuario.

Astro le permite encontrar un punto óptimo entre lo estático (con HTML) y el dinamismo (de js) al desarrollar sus sitios web. Lo hace mediante la superposición de técnicas avanzadas, como estática primero con hidratación selectiva/parcial, donde nuestras páginas se consideran como "islas" aisladas que se cargan e hidratan de forma independiente.

Inténtalo y velo por tu cuenta. Astro proporciona muchas aplicaciones de muestra en su repositorio de ejemplo , ¡lo cual es un excelente punto de partida para la experimentación!