Diving Into Server Islands

Muy bien. Hola a todos. Es bueno estar aquí en Londres. De hecho, hoy no está lloviendo, así que estoy muy feliz. ¿Quién soy yo? Bueno, Nathaniel ya me presentó. Soy Elion. Soy el Responsable de Relaciones con Desarrolladores actualmente en React Bricks. Así que si quieres hablar sobre CMSs, puedes encontrarme. Además, trabajo como freelance por mi cuenta. Soy mantenedor de Astron. Solía trabajar en el equipo central durante aproximadamente un año, centrándome en la experiencia del desarrollador y la documentación y todo eso. Trabajo con el equipo de BGS, que es un equipo que organiza conferencias en Bélgica, París, y pronto estará en África también. Así que si quieres estar allí, puedes también venir a hablar conmigo o si quieres postularte como orador o lo que sea, puedo darte algunos consejos.

Genial. Por supuesto, no estás aquí por mí. Estás aquí por el contenido de Astro y para sumergirte en server islands, y lo haremos seguro. Pero, por supuesto, primero hablemos un poco sobre Astro ya que es un poco necesario entender de dónde venimos y cómo surgieron los server islands porque es algo importante.

Así que Astro, cuando hablo de Astro y típicamente como lo hace el equipo central, hablamos de él como el framework web para el desarrollo orientado al contenido, no contenido primero, que solíamos decir, pero es desarrollo orientado al contenido porque es mucho, mucho, mucho más, especialmente ahora. Tiene algunos giros, sin embargo. Así que piénsalo como un framework comparable a Next o Nuxt, un meta framework, pero tiene algunas peculiaridades a las que probablemente no estés acostumbrado.

Así que son componentes de un solo archivo, justo como tendrías con algo como Vue o incluso Svelte. Tus scripts están en la parte superior. Puedes usar TypeScript. Puedes usar JavaScript como lo harías normalmente. Y todo lo que está debajo es solo JSX como esperarías que se comporte. Es increíble. No usamos class name. Usamos class ya que somos fieles a la especificación de HTML. Pero lo extraño de Astro es que por defecto, no envía ni un kilobyte de JavaScript al usuario final. Profundizaremos en esto. Explicaré este concepto de una manera más visual.

Así que imagina esta página, es una página teórica de nuestra página de inicio o sitio web que estamos construyendo. Todos estos componentes en un meta framework típico, depende, por supuesto, de cuál, requiere JavaScript para renderizar todos esos componentes. Y en realidad no tiene mucho sentido porque por ejemplo, ese pie de página allí, tiene múltiples enlaces, lo que sea. Todo eso es contenido estático. Entonces, ¿por qué estamos realmente requiriendo que el navegador envíe JavaScript, tenga JavaScript, para volver a renderizar todo eso? Eso no necesariamente tiene sentido. Así que por defecto, Astro toma todo eso y lo compila solo en HTML y CSS, que es el predeterminado del navegador. Y debido a eso, es increíble para sitios web orientados al contenido. Su indexabilidad. Por ejemplo, tu SEO por defecto será increíble. Tu accesibilidad, si mantienes un seguimiento de tus áreas y etiquetas alt y lo que sea, está allí por defecto. Así que te damos una buena herramienta para comenzar a construir tu aplicación. Y por eso digo que es ideal para el desarrollo de sitios web orientados al contenido, lo que sea.

Ahora, por supuesto, estamos hablando de HTML. Es un poco raro. No estamos en los años 80 más. Queremos que nuestro sitio web sea interactivo. Como, ¿qué pasa si necesito interactividad? ¿Qué pasa si necesito un botón? Como, quiero un botón en mi menú móvil para hacer algo. Bueno, por supuesto, hemos pensado en ti. Y por supuesto, hay una manera de usar JavaScript en tu sitio web. Se llama directivas de cliente. Y con las directivas de cliente, podrás controlar cómo tu sitio web se vuelve interactivo y cuándo esos componentes envían JavaScript al navegador. Así que es súper interesante. Y tenemos un par de ellas. Te daré las principales. Client load, por ejemplo, siempre enviará JavaScript a un botón, a cualquier componente que sea. Client idle siempre esperará a que el hilo principal del navegador esté libre, luego comenzará a cargarse. Así que eso es ideal para islas de contenido de menor prioridad, um, islas de interactividad, lo que sea. Client media, eso es ideal para ese botón del que estaba hablando. Imagina que tienes ese botón en tu página, pero no lo estás viendo porque es una pantalla ancha. No necesitas ese botón móvil. Bueno, este tomará una consulta de medios y solo ejecutará el JavaScript siempre que se cumplan los requisitos de esa consulta de medios. Eso es realmente genial. Y por supuesto, está client only, que puedes usar, por ejemplo, si no quieres tener un compilador en absoluto y solo enviar todo el JavaScript que estás escribiendo, um, lo cual no es un caso de uso ideal, pero a veces es necesario cuando estás trabajando con 3D o algo así.

Así que si luego tomamos esa página teórica de la que estaba hablando antes y ponemos esas directivas de cliente, como por ejemplo, tal vez en el encabezado, porque tenemos ese botón móvil allí, obtenemos una página que es realmente interactiva, pero aún así, um, está optimizada en términos de rendimiento porque todo lo demás, todos esos otros componentes siguen siendo solo HTML. Y eso es lo que llamamos, uh, infraestructura de islas o arquitectura de islas. Y hablaremos de islas de servidor en un momento porque estas son islas de cliente. Estas son islas que provienen del usuario en su máquina. Um, es una tecnología bastante interesante. Um, y lo genial de Astra es que en realidad es independiente del framework. Así que puedes usar cualquier framework que quieras porque todo es JavaScript. Así que realmente no importa. Um, eso es bastante genial.

Y debido a eso, Astra es un framework muy rápido, rápido en general. Por supuesto, esto es un poco de gráficos sesgados, pero todos los gráficos lo son. Así que, um, está bien. Hablemos de las cosas nuevas en Astra, porque esto ha estado ahí desde los primeros días de Astra, Astra 1, Astra 2 y 3, incluso antes de la 1, esto era como la cosa ideal. Pero ahora hemos lanzado cosas nuevas y las islas de servidor siendo una de ellas.

Um, las islas de servidor son una arquitectura bastante asombrosa porque toma la misma idea de la interactividad del cliente, pero la pone en el servidor. Así que, uh, en Next.js tienes algo llamado pre pre renderizado parcial, renderizado parcial previo. Ese es el. Um, es básicamente la misma idea o la misma respuesta, pero ejecutada de una manera diferente. Y vamos a, vamos a entrar en eso. Y también, por supuesto, el X Y es mucho mejor. Um, pero eso no es difícil de arreglar en Next.js.

Así que, um, piénsalo como un componente de Astra renderizado normalmente. Te mostraré el código en minutos. Um, es un componente de Astra renderizado del lado del servidor normal, um, pero retrasa el renderizado, um, hasta que todo el contenido está disponible. Así que obtiene bases de datos, obtiene lo que necesites. Tu página aún se renderizará, pero esperará por ese pequeño bloque de contenido dinámico que viene del servidor. Y luego lo mostrará. ¿Y cómo funciona eso? Bueno, tenemos algo llamado server defer. Um, en realidad está llegando a PHP ahora. Bueno, específicamente a Laravel. También están usando un server defer ahora. Así que imagina que tenemos un avatar. Es un ejemplo muy tonto. Lo sé. Y te mostraré uno mejor en un segundo. Y lo diferiremos al servidor porque podríamos necesitar obtener algunas cookies o tal vez alguna autenticación para asegurarnos de que realmente está cargando el usuario correcto o lo que sea. Así que estamos cargando desde el servidor, um, el avatar. Así que lo que podemos hacer aquí, y por eso he elegido este ejemplo, en realidad te muestra que en una isla de servidor, aún tienes acceso a las cookies. Aún tienes acceso a la sesión.

de servidor, todavía tienes acceso a las cookies. Todavía tienes acceso a la sesión. Tienes acceso a la autenticación porque todo eso está en el servidor, pero aún así, vamos a pasar eso al cliente de una manera muy eficiente. ¿Y cómo hacemos eso? Así que básicamente así es como obtenemos el avatar. Entonces tenemos un get avatar o lo que sea, get user avatar, ahí lo ves desde la sesión. Bien. Eso tiene sentido. Ahora, ¿cómo pasamos eso a nuestro cliente? Bueno, obtenemos el avatar. Queremos un fallback.

Así que si estabas viendo la charla anterior, viste suspense y el fallback. Es lo mismo, pero en realidad funciona de manera mucho más eficiente porque lo que sucede aquí, um, tenemos un slot de fallback donde ponemos un avatar genérico, y luego, una vez que se carga, lo pasaremos. Ahora, ¿cómo se ve eso en un ejemplo del mundo real? Imagino algo como, um, no sé, Airbnb. Entonces, ¿qué sucede aquí? Se recargará. Um, puedes ver allí en la parte superior, el, el, los solo nueve habitaciones restantes, eso podría ser una API. Eso podría ser una consulta de base de datos, tal vez una muy lenta porque necesita recorrer todas las habitaciones, lo que sea, o tal vez una oferta especial para ti. Um, todo eso. Entonces, lo que sucede allí es que en realidad comenzará a cargar el fallback genérico, um, un estado de carga, si quieres.

Y luego obtiene eso, sabe, tengo que obtener mi cliente. Simplemente envía la llamada y luego transmitirá el HTML directamente a tu front end sin que tu usuario realmente note lo que está sucediendo detrás de la pantalla. Piensa en ello casi como HTMX a demanda dentro de Astro sin todo el lío para ti como desarrollador, porque la DX todavía está muy presente. Por ejemplo, la parte inferior también. Por ejemplo, una cosa que realmente puedes hacer con esto, que es súper interesante. Puedes, um, hay una Battery API en Chrome. ¿Quién la ha usado alguna vez? Nadie. Exactamente. Imagina que quieres reservar una habitación y te queda un 5% en tu teléfono. Puedes notificar a tu servidor, Hey, este tipo todavía tiene un 5% en su teléfono. Tal vez deberíamos, um, detener las animaciones y ese es un muy buen caso de uso, pero lo que puedes hacer también es, Oh, en 10 minutos, esta oferta expira.

Tengo que hacer esto. Tengo que hacer eso. Lo compraré ahora. Así que para propósitos de comercio electrónico, es un pequeño truco desagradable, pero puedes hacerlo. Um, tengo una charla sobre eso por separado también.

Um, pero eso es para otra ocasión. Um, pero una de las grandes cosas sobre las server islands y la content layer API, la content layer API es algo nuevo también. Um, es que en realidad te permite cargar datos de una manera nativa. Um, no sé si alguna vez has oído hablar de las content collections, que era básicamente una forma de trabajar con y ofrecer con Markdown. Um, lo abrimos para que básicamente sea cualquier tipo de contenido, no solo Markdown. Así que cómo funciona, esto es uno muy simple. Esto te dará una colección con todos los países, pero los países en realidad vienen de una API y solo se obtiene, se obtiene una vez cuando construyes el sitio web. Y luego para el resto, tienes una lista de países. Pero la cosa es que es consultable. No es solo, um, solo una lista normal o algo es consultable.

Y eso es bastante asombroso porque empezamos a ver a la gente subirse a esta nueva loader API. Por ejemplo, esto es Cloudinary, soy un gran fan de Cloudinary. Lo uso para mi propio sitio web también. Es bastante asombroso. Imagina que puedes simplemente obtener todo tu contenido de Cloudinary, así de simple. Solo defines la colección, que es el CLD assets loader, que es el loader de activos de Cloudinary. Quiero cuatro imágenes y tienen que venir de sample slash food. Y ahora de repente puedes, de una manera nativa, una manera nativa de Astro, puedes consultar esa colección, usar esa colección y mostrar esas imágenes de una manera nativa, muy optimizada.

Um, eso es realmente muy, muy poderoso. Um, y esto fue en realidad uno de los primeros donde puedes hacer mucho más porque es tecnología de código abierto y en Astro somos grandes fans del código abierto. Como en una semana, empezamos a ver cosas aparecer como el Notion loader. Ahora puedes usar tu Notion como un CMS, por ejemplo, para tu sitio web de Astro sin tener que ir a la GraphQL API que tienen, o la REST API, que es enorme y muy difícil de trabajar. Pueden hacerlo así de fácil. O por ejemplo, um, quieres consumir, no sé por qué lo harías. Como, um, ¿cómo se llama de nuevo? Um, RSS feeds.

Puedes simplemente cargarlos, reutilizarlos, repropósito ellos. Tal vez tengas un, un sitio web donde te guste desplazarte por artículos o lo que sea. {{^}}Puedes hacerlo con una colección muy simple. Um, APIs, um, como Stripe, Stripe. No sé si alguna vez has trabajado con él. Es un dolor de cabeza trabajar con él. Sí. Así que aquí puedes hacerlo muy fácilmente porque simplemente obtienes todos tus productos y de repente está en una colección y la colección es consultable. Así que es súper fácil trabajar con, um, o más fácil de trabajar que con la API predeterminada de Stripe, pero eso tal vez sea su problema. Um, pero sí, genial.

Um, ¿qué pasa si quieres usar un CMS y sí, te estaba contando sobre eso antes. Como que es muy difícil usar APIs RESTful y bla, bla, bla. No, todo está en una colección allí listo para que lo uses. Realmente me encanta.

Um, lo siguiente en lo que trabajamos es Astro Actions. Um, las acciones del servidor probablemente te dirán algo. Es también la misma idea, pero ejecutada de manera diferente y mejor, pero esa es mi opinión. Por supuesto, um, Astro Actions te permite reducir, um, la cantidad de APIs expuestas públicamente. Porque si haces una API slash cualquier entrada de formulario, um, si tienes, puedes hacer un par de cosas para asegurar la API, pero ¿qué pasa si simplemente nunca la expones en primer lugar? Solo se permite para uso interno, uh, sin tener que ser pública. Bueno, puedes hacerlo con Astro Actions. Es bastante genial.

Um, porque puedes construir funciones seguras de tipo, uh, que tú, um, que llamas desde el cliente y las ejecutas en el servidor y luego pasas el resultado. Así que uno de estos casos es validar los datos del formulario. Um, Astro es HTML primero. Así que voy a mostrar una solución HTML. Imagina que tienes ese formulario. Así que tienes el nombre, correo electrónico, los términos del nombre. Así que ahora sabes en el servidor, si simplemente lo envías por defecto, te dará datos del formulario, uh, con luego, um, un array de correo electrónico y términos y lo que sea el valor es. Bueno, lo que podemos hacer para validar eso, simplemente iremos aquí. Usamos Zalt para eso.

Así que construyes un esquema Zalt. Dices, Hey, acepto el formulario. Así que sabe que esto es va a ser datos de formulario. Y luego simplemente haces, Hey, te voy a dar un objeto, que tiene un email, que debería ser un email, um, los términos, que deberían ser un Booleano. Y automáticamente para ti ya validará esos datos y luego ejecutará el manejador. Si todo es válido, lo cual es bastante poderoso, pero una de las cosas más impresionantes sobre esto es que sigue siendo tu aplicación y tienes la flexibilidad total de trabajar con ella.

Por ejemplo, lo que puedes hacer es Jack, una etiqueta de script simple. No estás usando ningún framework aquí. Solo JavaScript. Simplemente importas acciones. Importas la navegación, que es nuestra navegación del cliente, y luego simplemente envías el formulario en el listener de eventos. Y luego en la parte inferior, los datos del formulario son nuevos datos de formulario. Así que tienes los datos del formulario, luego esperas acciones. En este caso, una suscripción al boletín. Es así de fácil trabajar con ello. Y es bastante poderoso. Puedo hacerlo. Imagina, uh, formularios de registro y todo. No tienes que luchar más. Es súper, súper fácil de implementar.

Tenemos que hablar sobre AstraDB porque, um, AstraDB durante el último año ha sido un poco de cosa. Um, así que AstraDB es esta API de primera parte. Um, solía venir con algo llamado Astro, uh, Astro, um, ¿cómo se llamaba nuestra solución de base de datos otra vez? Lo olvidé. Um, mira cuánto me importa. Um, base de datos Astro. Um, ahora está abierta para cualquier lib SQL, um, que es un sabor de un SQLite. Usamos Tersa principalmente, pero cómo funciona es realmente bastante poderoso. Um, ¿cuántos de ustedes han trabajado con Drizzle? Oh, ninguno. Es un ORM. Es un ORM y la base de datos Astro realmente expone ese ORM y te dice cómo usarlo.

un ORM y la base de datos Astro realmente expone ese ORM y te dice cómo usarlo. Y es súper nativo. Es de primera parte. Así que en este caso, solo tienes database slash config dot TS, que es solo un archivo TypeScript. Y luego simplemente haces const comment, defines tu tabla, le das las columnas que tiene la tabla, uh, y luego la pasas a las tablas. Y ahora de repente tienes un código para su base de datos gestionado para ti.

Um, súper fácil. Y luego cómo usarlo mientras simplemente haces import database y esa cosa común es esperar database dot select, que es como una forma muy fácil de trabajar con tus datos que vienen de este Drizzle de contenido. Tal vez quieras unir un autor de ese comentario y luego simplemente podemos mapear sobre él como normalmente harías. Um, Astro studio, eso era nuestra cosa de base de datos. Bueno, ya no existe. Y si quieres saber cómo y por qué, bueno, puedes leer eso allí. Pero en buenas noticias, eso es lo que te estaba diciendo.

Se ha abierto para cualquier base de datos lib SQL ahora y solo tienes que pasar a variables. Um, lo genial de esto es cuando imagino Astro DB no solo como cualquier lib SQL, sino imagina que podrías usar my SQL o podrías usar Neon por ahí, que es Postgres. Así que puedes usar cualquier base de datos. Idealmente, esa sería la solución. Todavía estamos trabajando en ello. Um, y con suerte será posible el próximo año, lo que sea. Por supuesto, eso no es todo. Um, no sé cuántos de ustedes conocen Starlight, Starlight es nuestra documentación. Es, bueno, generador de documentación slash generador de sitios web. Es básicamente como DocuStar es, pero DocuStar está, por supuesto, construido en React y todo.

Um, está construido en, um, en Astro. Y lo grandioso de esto es que puedes usar todos estos potentes componentes de Astro como la base de datos, tal vez en tu documentación, o tal vez algo como, um, una client Island, porque necesitas eso, lo que sea que puedas hacer en Starlight. Um, lo genial es que también añadimos renderización bajo demanda allí. ¿Y por qué es eso útil? Imagina que tienes ciertas páginas en tu documentación que quieres poner detrás de autenticación, pero no todo y aún obtener una salida estática. Bueno, entonces esto es lo que estás buscando. Tal vez quieras manejar documentación desde una API. Um, puedes hacer eso con renderización bajo demanda.

Y es súper fácil de añadir, um, solo una línea de código. Lo genial también es que con la nueva versión, que es 0.28, creo, um, añadimos mejor localización. Um, es súper genial cómo puedes realmente hacer esto porque como localities, el componente de traducción, y luego puedes decir, Hey, necesito inyectar esta variable. Así que cuenta 99. Y luego, de repente, en diferentes traducciones, puedes tener el 99 aún siendo la variable, pero traducida de manera diferente. Um, es bastante genial. Estoy realmente contento con eso.

Ha tomado mucha inspiración de Laravel, pero la cosa es que si la gente viene a hablar conmigo, típicamente sobre Astro, me preguntan, Hey, ¿qué sigue, hacia dónde se dirige Astro? ¿Qué van a hacer? Así que tenemos que hablar un poco sobre Astro 5.0. Um, Astro 5.0 en realidad ya está ahí fuera en beta desde, um, lo que sea, desde creo que el 17 de septiembre, en algún lugar de mis diapositivas. Um, pero voy a contarte un poco sobre cómo y por qué se rompe y dónde se rompe, porque esa es información importante para ti si quieres usar Astro. Uh, las dependencias cambian.

Esa es la primera cosa. Si haces una actualización importante, quieres romper dependencias porque ahí es donde realmente puedes hacerlo. Ahora estamos requiriendo node 17.1, um, bueno, 18.17.1, que anteriormente era 18.14 o algo así. Así que no debería romper mucho, pero principalmente, um, Vite 6.0 beta es lo principal. Y por qué todavía está en beta es, bueno, Astro 5 beta, quiero decir, es porque Vite todavía está en beta. Una vez que Vite lance una versión estable, Astro 5.0 seguirá como estable también. Así que ya puedes usarlo allí. Uh, o ya puedes usar Astro 5.0 beta hoy, pero podría ser un poco, um, dependiente de Vite.

Genial. Modos de renderizado. Um, como te estaba diciendo, tenemos el estático, el híbrido y luego el de servidor. Bueno, ahora estamos eliminando el completamente estático porque ya no es necesario ya que el híbrido es el predeterminado. Um, así que puedes usar todo estático por defecto y solo una página para ser una ruta de servidor. Es bastante genial. Um, así que por defecto y solo cómo cambias eso es solo una línea de código que, cambias. Eso es todo. La colección de contenido es de lo que te estaba hablando antes. La solución de markdown cambió para ser completamente API de capa de contenido. Pero por supuesto, la ruta de migración es fácil porque solo tienes que cambiar una línea para ser un cargador en lugar de predeterminado, el glob de contenido, um, lo cual es genial.

Estamos eliminando un par de cosas que, que podrían ser realmente importantes. Um, estamos eliminando la integración de lit de primera parte porque no mucha gente la está usando y el mantenimiento es muy difícil. Um, pero, por supuesto, lit es solo componentes web. Así que aún puedes importar el script y todavía está allí. Um, el renderizado híbrido está siendo eliminado. El servicio de imágenes Squoosh se elimina. Estamos cambiando a sharp. Sharp está realmente más mantenido y es un poco mejor. Um, no debería ser un problema. Por supuesto, todas las banderas experimentales se eliminan porque ahora son características estables, o al menos la mayoría de ellas lo son. Así que si hay más cambios importantes, los publicaremos en el sitio web. Por supuesto, todo está en la documentación. También tenemos una guía completa de actualización.

Así que si estás buscando un cinco que sea realmente bueno. Um, ha estado disponible desde el 17 de septiembre, lo que significa que ya tuvimos algunas iteraciones. Actualmente estamos en la beta cinco. Creo que todo está funcionando genial. Es genial. Así que estoy realmente feliz. Um, puedes simplemente actualizar con un solo comando, que es npx.srgs slash upgrade para todo. Si quieres la beta, solo agrega beta al final y eso funcionará. Genial.

Creo que eso es principalmente para mí. Tal vez si quieres mantenerte actualizado sobre Astro o yo, puedes encontrarme en todas las redes sociales con add Aelion code, donde tuiteo mucho sobre desarrollo web en general, pero también Astro.build, que es la página principal de Astro, donde hay un par de cosas, como por ejemplo, temas, si quieres empezar desde, no empezar desde cero, lo que sea. Astro.build slash chat es donde está nuestra comunidad. Es un servidor de Discord. Tenemos más de 30k miembros, pero se siente así. Es muy divertido. Um, es pequeño y puedes acercarte a todos los miembros del equipo central allí también. Genial.

Gracias. Soy Aelion y tal vez nos veamos la próxima vez. Muchas gracias, Aelion.

Vamos a pasar a algunas de las preguntas. Sí. Una de las primeras decía, ¿de qué deberían estar conscientes los desarrolladores de componentes de React para asegurar que sus componentes se ejecuten en Astro? Um, por ejemplo, ¿hay una capa de React o una capa de Astro para un sistema de diseño o algo así? Por supuesto, lo genial de usar algo como React, en muchos casos, como la gente usa React en Astro, es que todo está allí. Quiero decir, las dependencias que tienes en React también pueden tener, bueno, ejecutarse en Astro. No hay una distinción real allí porque todavía estás, bueno, depende si estás usando un cliente o no. Um, puedes simplemente usar los mismos componentes, como por ejemplo, React 3 Fiber. Mucha gente usa eso.

Es totalmente compatible con Astro, siempre y cuando sea compatible con React, es compatible con Astro. Increíble. Ahora, no tenemos, oh, acaba de llegar una pregunta. Solo necesitaba presionar actualizar. Uh, y la siguiente es por qué elegir, está bien. Siempre tenemos gente que pregunta, um, tal vez uno es mejor que el otro, pero luego cuando hablamos de lo que es único en Astro, que haría que alguien elija Astro. Sí, exactamente. Creo que el enfoque es muy diferente. Um, next es como, es un marco completo. Es, es increíble en lo que es. Um, podría ser un poco más pesado, pero tienen un diseño opt-out. Me gusta llamarlo, mientras que te entregan todas las características, tienes acceso a todas las características. Bueno, Astro hace lo contrario. Comienzas con la capa base, que es HTML, y luego agregas un poco de complejidad en tus componentes. Y luego tal vez al final agregas el servicio de imágenes o tal vez luego la base de datos, todo es un diseño opt-in, lo cual es un poco más fácil para mí, como para incorporar a otros desarrolladores, por ejemplo, porque es muy claro. Um, también me gusta mucho la experiencia de desarrollo de Astro. Es muy buena, como en capacidad de actualización, mantenibilidad. Realmente lo disfruto.

Um, pero sí, todavía hay algunos casos de uso donde no recomendaría Astro, seguro. No, seguro. Y creo que supongo que este clásico, depende, pero también creo que lo que mencionaste al principio sobre el desarrollo impulsado por contenido, como eso debería ser algo que si quieres pensar en tal vez Astro lo hace. Sí, exactamente. Creo que ese es el punto principal que quiero hacer también. Sí, no, seguro.

Y, y luego el siguiente, uh, ¿tiene Astro un concepto de contexto similar a React? Sí. Um, bueno, sí y no. Um, depende como siempre, por supuesto. Um, no, en el sentido de que, um, tus islas son islas con una razón, como son islas de interactividad que realmente no pueden comunicarse entre sí. Por supuesto que puedes, y hay un par de maneras, como puedes hacer gestión de estado entre ambos, pero realmente no está destinado a ser. Probablemente si estás buscando contexto, o no estás haciendo algo bien en, en Astro, quiero decir, o no deberías estar buscando en Astro para la solución. Pero por supuesto, si realmente quieres, puedes ejecutar un SPA completo dentro de una página de Astro para que sea posible usar el contexto a través de las páginas. Sí. No. Increíble.

Y así esto es un poco, hablamos sobre cómo, qué podría hacerte elegir Astro. Sí. Y luego, ¿cuáles son algunas cosas donde estás como, si quieres construir esto, no recomendaría comenzar con Astro solo para que la gente pueda elegir la herramienta correcta. Sí. Para mí, siempre es como el, es un asunto impulsado por contenido una y otra vez. Como si estás construyendo un sitio web que tiene que ser indexable, que tiene que ser flexible en cierto sentido. Quieres mucha flexibilidad. Como sitios web personales, es una hazaña increíble, como un caso de uso increíble para Astro o blogs, lo que sea, porque la experiencia del autor y todo y la mantenibilidad, pero imagina que estás construyendo dashboards, servicios de autenticación, múltiples APIs, entonces podrías no mirar a Astro porque renderizar todo si estás renderizando todo en una isla de cliente de todos modos, o un gran componente de cliente, lo que sea, entonces probablemente Astro podría no ser el ajuste ideal para ti. No significa que no puedas hacerlo. Solo significa que podrías no aprovechar las potentes características o sitios de Astro. Quiero decir, he tenido el placer de verte hablar sobre Astro y es realmente interesante que esta pregunta específicamente surja y has estado con, has trabajado en el ecosistema de Astro, digamos, por un tiempo. Sí. ¿Qué, la gente ha comenzado a encontrar como Astro para lo que necesitan o todavía es un poco de gente que no está segura de lo que es? Sí. Ha cambiado mucho.

De hecho, cuando comencé en Astro, estaba en la versión 0.14. Ahora estamos lanzando la 5.0, así que ya estamos cuatro versiones principales por delante. La cantidad de características que hemos añadido es increíble. Fue muy rápido. Y la cosa es que cuando empezamos, Astro no era más que realmente un generador de sitios web estáticos. Y solo aconsejaría a la gente usarlo para cosas como blogs o feeds RSS y esas cosas. Sitios web personales en general. Pero ahora puedes construir aplicaciones realmente potentes. Tenemos bases de datos allí. Tenemos optimización de imágenes, todo eso ha cambiado.

Y lo bueno es que con el tiempo nos convertimos en un competidor para otros frameworks y la gente comenzó a comparar Astro con ellos. Y eso es bueno para la visibilidad, pero no necesariamente para el caso de uso, porque Astro realmente no está tratando de competir con ningún framework. Si acaso, intentamos impulsar la web hacia mejores estándares, lo cual también estamos logrando por cierto. Pero, por ejemplo, un buen caso de uso o ejemplo de eso es cuando lanzamos Vue Transitions. De repente, en las tres semanas que lo lanzamos, todos los otros frameworks comenzaron a adoptarlo también. Y ahora lo tenemos como un estándar en Chrome. Así que creo que Astro es un vecino amigable en el espacio web. Vecino amigable. Y con eso, se nos está acabando el tiempo.

Pero si tienes una pregunta, siempre puedes venir y hablar con él. ¿Y dónde puede encontrarte la gente en línea? En Alien Codes, en todas partes, en todas las plataformas. También tengo, creo, si vas a mi sitio web, hay un slash links y luego puedes ver todas mis redes sociales, todo lo que sea. Todos los enlaces que puedas necesitar. Genial. Asegúrate de calificar la charla y darle un aplauso. Gracias.