Novedades en Astro

Tengo algunas cosas emocionantes para compartir, algunos anuncios, algunas cosas geniales detrás de escena. Pero no importa en qué pila tecnológica trabajes, habrá algo relevante e interesante para ti. Hay muchas cosas futuras geniales que tienen un gran impacto más allá de Astro. Así que estoy emocionado de comenzar con esto.

Sabes, cuando trabajamos en Astro, tenemos la idea de un par de primitivas de diseño que nos gusta tener en cuenta mientras diseñamos el framework. Y una de las que me importa mucho es esta idea de impulsar el marco web. Impulsar la web hacia adelante con un marco web. No estamos construyendo solo otro marco web, estamos tratando de desafiar a la industria, diferentes estados de cosas, diferentes formas de hacer las cosas que creemos que están desactualizadas o merecen ser desafiadas.

Queremos dar a los desarrolladores más opciones sobre cómo construyen cosas. Por ejemplo, cuando creamos Astro, una de las primeras cosas en las que nos fijamos fue en el estado del rendimiento en la web. Y los marcos de JavaScript en particular, prometen una pila tecnológica completa de JavaScript. Servidor, cliente, unificado, un lenguaje, perfecto. Y todos tienen sus Hello Worlds, sus blogs, sus sitios de muestra que se ven bien y tienen un buen rendimiento.

Pero cuando llegas al mundo real del rendimiento, deja mucho que desear. Estas herramientas prometían mucho, pero al final del día, enviaban mucho JavaScript. Y eso hacía que fuera muy difícil para un desarrollador trabajar en esos marcos y también tener un sitio rápido. Así que, si miras aquí arriba, nadie aquí arriba tiene un porcentaje mayor al 50 por ciento, ¿verdad? La mayoría de los sitios no son rápidos. Son lentos según esta definición de Core Web Vitals. Y esto es en toda la red. Esto es 10 millones de sitios medidos por Google, HTTP Archive.

Así que, promesa de poder y todas estas grandes cosas que proporciona la web. Pero luego la experiencia del usuario, carga de página lenta, interacción lenta, un rendimiento realmente deficiente en general. Así que esto era algo que queríamos desafiar. Esta idea de que podrías tener una pila tecnológica unificada, JavaScript en todas partes, pero no significaba enviar JavaScript, todo a cliente. No significaba SBA. No significaba aplicaciones grandes. Y esto es para lo que nació Astro para resolver y creo que los datos hablan por sí mismos. Es nuestro mayor logro hasta ahora, impulsar esta narrativa, esta idea de que no necesitas tanto JavaScript. Puedes tener un sitio rápido y DevTools que amas. Puedes seguir usando React o Vue o Svelte. Mantén todo, pero ten un framework web que optimice tu sitio a un nivel mucho más alto.

Así que esta era la arquitectura de islas. Esta es la gran idea que impulsamos, esta idea de no pensar en tu sitio como una aplicación. Piensa en él como una página de HTML estático. Y esas partes interactivas que necesitas, son los componentes hidratados en tu página. Los vamos a aislar, hidratar en paralelo, pero son pequeñas islas de interactividad en todo tu sitio. No es una gran aplicación. Entonces, ese componente de encabezado, ese componente de diseño, esas cosas que son estáticas, en realidad no necesitas enviar ese JavaScript.

Simplemente envía el HTML, deja que el navegador se encargue del resto. Entonces, esto fue súper, súper poderoso. Lo seguimos con las colecciones de contenido. Esta fue la idea de contenido incorporado en la plataforma, incorporado en el framework como un primitivo. Los constructores de sitios estáticos han estado haciendo esto desde siempre. Gatsby lo había hecho. Pero queríamos ofrecer una visión moderna de esto utilizando TypeScript, validación de front matter, esquema, todo optimizado para una experiencia de desarrollo moderna donde obtienes tipos de forma predeterminada. Obtienes tipos automatizados. No tienes que definirlos todos tú mismo.

Y por último, Bruce mencionó esto. Esta es una de mis características favoritas que ha surgido de la plataforma web en el último tiempo, posiblemente. Esta idea de transiciones de Vue. Entonces, si no has visto esto, parecerá magia. Voy a hablar de ello en un segundo. Esta idea de dejar que el navegador maneje una experiencia similar a una aplicación de navegación de página en página. Así que se siente como una aplicación, se siente como magia, pero al final del día, el navegador en realidad se transforma, se desliza, se desvanece, mientras navegas de una página a otra. Es realmente genial. Y en realidad nos asociamos con el equipo de Chrome para construir esta API en Astro. Así que no es solo algo que admitimos. Es en realidad una API que te exponemos, para que puedas controlar esto en tu sitio con un par de líneas de directivas que puedes simplemente esparcir. Así que, sin JavaScript, navegación similar a una aplicación en la web. Realmente, realmente genial. Y esa fue una gran característica que lanzamos el año pasado.

Muy bien. Futuro. Nuevo año. ¿En qué vamos a trabajar? ¿AI? ¿Estamos trabajando en cripto? No, estamos trabajando en el metaverso. Esto es lo más importante... No, solo estoy bromeando. Esto es algo que nadie está haciendo ya.

Pero me encanta esa imagen. No, quiero hablar sobre nuestra visión para el futuro. Quiero hablar sobre las tres cosas en las que estamos trabajando este año que van a impulsar la web hacia adelante. Y realmente, nuevamente, esto no es solo nuestra visión para Astro. Es nuestra visión para todos los sitios web impulsados por contenido. Entonces, si tu sitio existe para llevar contenido al usuario, ya sabes, un blog, un sitio de marketing para tu empresa, un sitio de e-commerce, si tu objetivo principal es llevar eso al usuario rápidamente, permitiéndoles tener una gran experiencia, convertir, no rebotar, todas esas cosas, entonces Astro es un framework web diseñado específicamente para ese caso de uso. Si necesitas un panel de control grande y pesado o una aplicación grande y pesada, hay otros frameworks diseñados para eso. Estamos realmente enfocados en el sitio impulsado por contenido, y queremos impulsar ideas que creemos que todos los sitios impulsados por contenido deberían explorar.

Entonces, tres nuevas características, todas basadas en las mismas cosas que hemos estado explorando en los últimos cuatro años. Islas, contenido y transiciones de vista. Así que, vamos a sumergirnos en ello. Tenemos tres cosas geniales para compartir, tres demos geniales, tres anuncios geniales. Hemos estado haciendo una semana de lanzamiento en Twitter, así que una de estas cosas ni siquiera se ha lanzado todavía, totalmente nueva. Todos ustedes lo han visto por primera vez, así que cosas muy emocionantes.

Comenzaremos con las transiciones de vista. Nuevamente, esto se siente como magia si nunca lo has visto. Estás viendo Spotify aquí y piensas, OK, gran aplicación JavaScript, aplicación de escritorio pesada. Esto es realmente pesado, ¿verdad? Pero la realidad es que esto es un clon de Spotify. No construimos Spotify, lo prometo. Construido con Astro, aprovechando las transiciones de vista. Entonces, esta no es una biblioteca de JavaScript que alimenta todo esto. En realidad, no hay JavaScript escrito por el usuario o por el desarrollador. El navegador se encarga de transformar, desvanecer y hacer la transición de una página a otra. Todo lo que el desarrollador hace es básicamente decirle al navegador qué va dónde, cuál es el antes, cuál es el después, y el navegador se va a transformar del antes al después por ti. Si no has visto esto, es una de las cosas más geniales, porque toma esta característica que era de JavaScript, una característica de SPA, y ahora es algo que cualquier sitio web puede usar. Es totalmente HTML, totalmente CSS, no se necesita JavaScript. Alivia el trabajo de los autores de frameworks, alivia el trabajo del desarrollador. El navegador se encarga del trabajo pesado aquí. Es realmente, realmente genial. Entonces, API nativa del navegador.

Estás agregando estas directivas para nombrar y desvanecer las transiciones. Y una de las cosas geniales que hicimos fue básicamente construir esto para el futuro. Pero nos damos cuenta de que las especificaciones tardan un tiempo en llegar, ¿verdad? Un navegador lo admite. El otro no. Un navegador lo envió incorrectamente, y ahora tendrás que admitir eso para siempre. Una de las cosas geniales que hicimos fue construir esto de tal manera que vamos a abstraer todos los detalles de implementación a nivel de navegador. Solo tendrás que preocuparte por estas directivas de transición, y eso te dará compatibilidad hacia atrás. En realidad, funciona en navegadores que ni siquiera admiten esto como un primitivo todavía. Y también te brinda compatibilidad hacia adelante. Básicamente, a medida que los navegadores comienzan a adoptar, puedes hacer un cambio de una línea o lo que necesites hacer, pero nos encargaremos de esa migración a la nueva función para que tu code se mantenga exactamente igual.

Tal vez un cambio de configuración, tal vez uno o dos cambios de línea, pero la mayoría de tu sitio, estas API que hemos diseñado hoy, funcionarán en el futuro. Para hacer esto, tuvimos que volvemos un poco extraños, un poco extravagantes. Tuvimos que inyectar un enrutador JavaScript, básicamente. La forma en que los navegadores implementaron esto fue de manera incremental. Básicamente, van a proporcionar primero una API de JavaScript, y luego una API de HTML y CSS más adelante. Y así tuvimos que conectarnos a ese JavaScript. Básicamente, tuvimos que tomar el control de la navegación de tu sitio web, lo cual, si sabes algo sobre Astro, es como la única cosa que juramos que nunca haríamos, y aquí estábamos enviando un enrutador, enviando el comportamiento de la aplicación JavaScript para alimentar esto. Su objetivo principal es deshacerse del JavaScript y permitir que el navegador haga este trabajo por ti. Pero hicimos una apuesta. Básicamente dijimos, está bien, lo tomaremos como un atajo. Esto nos ayudará a superar esta fase de compatibilidad hacia atrás, y a medida que los navegadores adopten esto, los desarrolladores podrán eliminar esto, podremos eliminar esto, y eventualmente todo desaparecerá en la plataforma. Un día, el JavaScript no será necesario. Podemos eliminar esto como solución temporal. Y esto es lo emocionante. Literalmente esta semana, no podríamos haberlo planeado mejor, total coincidencia. Esta semana, Chrome y Microsoft Edge admiten el soporte para esta API HTML final, brindándote transiciones de vista sin JavaScript, sin necesidad de JavaScript. Estás haciendo clic en un enlace como lo has estado haciendo durante décadas, y el navegador se encarga de esa transición por ti. Cero JavaScript, todo CSS. Realmente, realmente poderoso e integrado en Astro.

Así que Chrome, Edge, más navegadores en camino, es una característica realmente genial. Eso es todo lo que necesitas. Agregas eso a tu página, y le estás diciendo a Chrome que has optado por esta nueva función. Así que esto debe estar al principio y al final, al inicio y al final, sin importar de dónde vengas o a dónde vayas. Pero el navegador lo detecta en ambos extremos. Dice que has optado por ello, y lo mostrará con un fundido predeterminado. Puedes, nuevamente, transformar y hacer transiciones como desees, pero esto es todo lo que necesitas para habilitar esta función en tu sitio.

Nuevamente, hoy. Está disponible hoy en estos navegadores. Si utilizaste nuestra compatibilidad hacia atrás, teníamos este componente de transición de vista que inyectaba ese enrutador, tomando el control del navegador. Ahora eso puede desaparecer por completo. Nuevamente, elimínalo, agrega la etiqueta de estilo, y listo. Y nuevamente, parece la misma demostración, porque ese es el punto. Es la misma demostración, pero en realidad es una grabación totalmente diferente hecha un año después utilizando este poder real en el navegador. Disponible en Chrome, disponible en Edge. Se siente como magia. Es similar a una aplicación. Pero nuevamente, todo lo que estás haciendo es esparcir un poco de CSS en tu página. El navegador se encarga del resto. Se siente como una aplicación. Pero no lo es. Es solo HTML. Realmente, realmente genial. Puedes migrar cuando estés listo. Está disponible ahora. Puedes usar la compatibilidad hacia atrás ahora. O simplemente estar atento. Esto estará disponible en más navegadores. A medida que los navegadores se actualicen y adopten, más usuarios tendrán esta funcionalidad. Es una característica realmente genial que incorporamos en Astro hace un año, y ahora estamos cosechando los frutos.

Está ahí. Está disponible. Es una de las cosas más geniales que está sucediendo en la web en este momento. Así que echa un vistazo a esto. Se llaman Transiciones de Vista. Acaban de lanzarse en Chrome. Safari, creo, acaba de anunciar el acceso a la API de JavaScript. Así que nuevamente, esa compatibilidad hacia atrás, podemos encargarnos de eso por ti. Esto llegará a la web, y es realmente, realmente poderoso.

Bien, hablemos del contenido rápidamente. Si has utilizado Astro antes, sabrás que tenemos este primitivo de contenido, esta idea de colecciones. Así que colocas tus archivos de markdown en tu repositorio, los colocas en la estructura de carpetas correcta, y nosotros haremos todo este trabajo por ti para obtenerlos, cargarlos, analizarlos, validar su esquema, y darte esta API de TypeScript que conoce los nombres de tus colecciones. Conoce los IDs y los slugs que estás intentando obtener. Conoce la estructura de tus datos, ¿verdad? ¿Qué tipo de front matter tienes? Esto no será un error en tiempo de ejecución. Si alguien ha tenido alguna vez, como, el undefined no es una propiedad porque uno de tus miles de archivos de markdown tenía algún error tipográfico o de front matter, te estamos dando la validación. Estamos haciendo todo eso por ti a nivel del framework. Así que esta es una API realmente genial. Un par de limitaciones. Construimos esto para contenido local, así que nuestras propias Docs nos inspiraron mucho en esto, pero también los constructores de sitios estáticos, ellos han estado haciendo esto durante años, hacen blogs, blogs personales de desarrollo, contenido. Contenido local, súper poderoso, no se escala a contenido remoto. Tiene que ser markdown o algún tipo de archivo personalizado, pero tiene que estar en tu repositorio, lo más importante. Y tiene que estar en una estructura de carpetas rígida específica. Así que gran parte del poder que tenemos ahora mismo es que si lo estructuras de esta manera, podemos inferir muchas cosas y brindarte una experiencia realmente genial. Cuando comienzas a agregar internacionalización, cuando comienzas a querer organizar eso tú mismo, esas estructuras de carpetas pueden volverse un poco complicadas. Rígidas a propósito, pero a medida que te escalas, comienzas a alcanzar los límites a medida que creces. Y por último, a medida que comienzas a alcanzar los límites de eso a medida que creces, también estás lidiando con el hecho de que básicamente almacenamos todo esto en memoria. Así que te sorprendería, esto funciona bastante bien para sitios grandes, sitios estáticos, pero cuando pasas a serverless, la idea de cargar todo tu contenido en memoria solo para servir una página, es bastante brutal en serverless, en los tiempos de renderizado de SSR. Así que Netlify, Vercel, quien sea a quien estés implementando, realmente puede tener algunos problemas de escalabilidad.

Pero el contenido, este no es un problema nuevo en la web, tenemos CMS, tenemos data remota. Deberíamos poder resolver esto a nivel astral. Entonces, una de las cosas que estamos explorando este año, un RFC temprano pero aún algo en lo que estamos trabajando activamente, es la idea de una capa de contenido más poderosa. Básicamente, las partes buenas de Gatsby. ¿Podemos obtener esta idea de una capa de contenido unificada que no se trata solo de Markdown, sino que se trata realmente de donde vive tu data, remota, local, juntarlo todo en una capa de data unificada en la que luego puedas construir de manera confiable, consistente, y con APIs bien documentadas. Así que soportar las mismas cosas. La compatibilidad hacia atrás es muy importante. Esta idea de, si solo quieres usar una carpeta de Markdown, genial. O MDX, fantástico. Te daremos ayudantes para trabajar con eso. Si tal vez quieres contenido local, pero quieres salir de esta estructura de carpetas rígida, quieres que todas tus entradas estén en un archivo de data único, como un gran arreglo JSON, genial, también puedes hacer eso. Si quieres escribir algo totalmente personalizado, por lo que quieres proporcionar solo un arreglo de data en línea, quieres hacer una llamada fetch a alguna API remota, eso es increíble, también puedes hacerlo. Lo que quieras hacer, cargadores personalizados.

Y lo que más nos entusiasma es esta idea de hacerlo modular. Entonces, puedes escribir tu propio cargador personalizado, puedes empaquetarlo y enviarlo a NPM. Ahora, cualquier cosa puede ser modular, cualquiera puede consumir eso. Puedes tener tu CMS como Storyblok. Puedes tener Instagram, Twitter, cualquier cosa de la que quieras cargar contenido, juntándolo todo de manera componible, en una única capa de contenido unificada. Así que hay mucho más en esta API, esto es solo una pequeña muestra de lo que creo que es lo más emocionante al respecto. Es modular, remoto, local, sin importar cómo sea tu data, puedes integrarlo en esta capa de contenido.

Una cosa de la que no tengo tiempo para mencionar, pero también muy interesante, mencioné la escala. Usando una base de datos real esta vez, no solo un gran bloque en memoria, sino realmente incrustando SQLite en Astro mismo para alimentar esto nos ayudará a escalar a decenas de miles, cientos de miles, sin importar cuánto contenido tengas. SQLite es una base de datos realmente confiable, y se ejecuta incrustada dentro de Astro, por lo que no hay contenedores Docker para iniciar. Una tecnología realmente genial que estamos explorando aquí. Aún está en la Etapa 1, es un RFC temprano, pero esto es en lo que estamos trabajando activamente este año.

Bien, por último. Esto es algo de lo que aún no hemos hablado mucho, así que todos ustedes lo están viendo por primera vez. ¿Qué estamos haciendo con la arquitectura de islas? ¿Cuál es el siguiente paso allí? Nuevamente, mencioné esta idea de islas de interactividad. Esta es una ilustración muy útil del equipo de Deno, esta idea de HTML estático, islas de interactividad. Esta fue nuestra arquitectura front-end original, optimizada para sitios de contenido, cuando la mayor parte de ese contenido es simplemente, ya sabes, no se trata de aplicaciones de usuario y estados complejos.

Se trata simplemente de llevar contenido al usuario. Esto puede tener un impacto realmente importante en el rendimiento, utilizando todos tus mismos frameworks web favoritos. Solo hidratas lo que necesitas, obtienes HTML estático, es rápido. Eso es lo más importante de la arquitectura de islas.

Pero el rendimiento del front-end, JavaScript versus HTML. Eso es solo una parte del problema. También está el cómo. Entonces, si eso es lo que estás enviando al usuario, cómo lo estás enviando al usuario, también es una gran pregunta de rendimiento. Los desarrolladores hoy en día, están un poco atrapados con este compromiso. Tienes HTML estático, lo pones detrás de un CDN, obtienes almacenamiento en caché global estático, decenas de milisegundos para entregar una página al usuario. ¡Esto era como la promesa original de JAMstack, ¿verdad? La simplicidad, la velocidad, estático, es realmente rápido y simple.

Si alguna vez has implementado un sitio estático en comparación con implementar un servidor grande y pesado, conoces la diferencia. Pero pierdes muchas cosas. Una de ellas es la personalización. Cualquier cosa dinámica, cualquier cosa personalizada para el usuario, en el momento en que comienzas a incrustar eso en tu página, de repente ya no tienes esa página estática. Si tu cara aparece, tu pequeño avatar de usuario en la parte superior derecha, eso no es realmente algo que puedas almacenar en caché para todos. De repente, todos verán tu cara cuando visiten esa página, porque accidentalmente almacenaste en caché contenido personalizado de forma global. Y así obtienes ese problema de tener que elegir entre estas dos opciones, que realmente no son correctas, ¿verdad? Tienes un rendimiento rápido pero simple. Tienes una personalización súper pero pesada y más lenta, ¿verdad? Ahora tienes que acceder a un centro de datos para representar ese contenido porque has omitido la caché.

Esto es algo que nos emociona mucho explorar porque creemos que las islas tienen la respuesta para esto también. Creemos que las islas de servidor son un nuevo concepto que podemos llevar a la arquitectura de islas, el primer cambio que hemos realizado en esto desde la creación de Astro que no solo aborda JavaScript versus HTML, sino que aborda la idea de contenido personalizado dentro de una estructura estática.

La API que queremos lanzar es súper simple. Es solo la idea de, al igual que hidratarías un componente del cliente con una directiva del cliente, queremos darte una directiva del servidor. Esto te dará algo que puedes adjuntar a cualquier tipo de contenido personalizado en tu página y decirle a Astro, este es contenido personalizado, esto viene después, esto no es parte de esa estructura estática que vas a representar. Diferir la representación para más tarde. Básicamente, representamos un sustituto en tu página, algo así como un esqueleto que puede ir con una página completa que no es personalizada, es súper estática. Vamos a inyectar un pequeño script que va a buscar este contenido representado más tarde.

Entonces lo vamos a buscar desde un punto final separado, lo representamos de nuevo en la página, y luego lo volvemos a unir para reemplazar ese sustituto en la página. Muy simple. Este es un demo muy simple.

Va a estar en bucle para que puedas verlo varias veces. ¿Ves esa primera respuesta? 20 milisegundos, almacenada en caché globalmente. No importa dónde te encuentres en el mundo, eso proviene de un centro de datos que está cerca de ti, no el que se encuentra en Virginia. Caché global en ese HTML.

Pero luego el contenido personalizado, eso se obtiene por separado. Tan pronto como llega esa página, el script se ejecuta y va a buscar ese contenido personalizado. He agregado un tiempo de retraso bastante absurdo, creo, un poco más de un segundo para ver cómo se ve eso. El navegador está esperando. Lo obtiene. Interrumpe la mayoría del contenido de tu página, y aún así vuelve, hidrata ese contenido personalizado dinámico. Así que esta es nuestra respuesta.

Hemos estado observando al equipo de React durante casi una década trabajando con suspense, y luego componentes del servidor, y luego transmisión, y ahora pre-renderización parcial. Y hemos aprendido mucho de ellos, y también nos han estado preguntando sobre esta función prácticamente desde los inicios de Astro. ¿Cuál es nuestra respuesta? Nuestro objetivo es avanzar hacia ese tipo de estado final, que es lo que estás tratando de hacer es resolver un problema para el usuario. Contenido personalizado, rendimiento estático, ese es el tipo de Santo Grial aquí que estamos tratando de ofrecer. Y creemos que las islas son el primitivo adecuado para eso.

Ya estás pensando en tu página principalmente estática. Estás agregando estas islas de contenido interactivo, y ahora estás agregando islas de contenido personalizado. Así que no tiene que ser JavaScript. Todavía puede ser HTML estático, pero es dinámico. El contenido en sí puede cambiar por hora, por segundo, por minuto, todo lo que necesites. Pero no afecta el rendimiento. Eso es lo más importante. Tu página se convierte en una estructura estática, almacenada en caché globalmente. Esto no es propietario. Funciona en cualquier CDN, por lo que funciona en cualquier lugar donde desees alojar esto. Estamos realmente entusiasmados con esto. Realmente va a, creo, cambiar la fórmula cuando pensamos en estas dos cosas, personalización o rendimiento. Creemos que puedes tener ambas. Entonces, nuevamente, esto es algo muy temprano, temprano, temprano aquí.

Esto es algo en lo que estamos trabajando este año, así que no está a ocho años de distancia, lo prometo. Está llegando. Lo estamos explorando, pero realmente emocionados de enviar más de estas cosas y más experimentos más adelante este año.

Entonces esto es lo que creemos que es el futuro de Astro. Se trata de invertir y promover estos mismos primitivos. Las transiciones de vista sin JavaScript ya están aquí. Esta fue una trampa. Ya está aquí. Puedes usarlo hoy.

Una capa de contenido más poderosa y una isla de servidor personalizada más poderosa, ambas en RFC tempranos, pero aún en camino a principios de este año a medida que desarrollamos y exploramos esto más a fondo.

Entonces esta es nuestra visión para el futuro. Estas son tecnologías y prácticas que creemos que cualquier sitio de contenido debería aprovechar. Solo porque las estemos construyendo en nuestro framework no significa que no puedas explorarlas en cualquier pila tecnológica que uses. Entonces, si estás usando Vite, SvelteKit, Remix, Next, Nuxt, lo que sea que uses, estas son características que deberías explorar sin importar qué. Están impulsando la web hacia adelante, y al final del día, por eso estamos aquí en Astro.

Así que estoy emocionado de explorar estas cosas, emocionado de compartirlas aquí con todos ustedes. Espero que hayan aprendido algo de esto. Muchas gracias por tenerme.

¿Cómo compararías los componentes de Astro con los componentes del servidor de React? Son muy similares. Ambos proyectos surgieron en la web alrededor del mismo tiempo. Esta idea del JavaScript del lado del cliente, tenemos que hacer algo al respecto. React tomó el enfoque de incorporarlo a React, y nosotros tomamos el enfoque de incorporarlo a un framework de nivel inferior. Pero un componente de Astro es esencialmente un componente de servidor. Básicamente no tenemos el concepto de componentes del cliente. En su lugar, decimos que uses React o Svelte o Vue para eso, pero nosotros somos OG, solo componentes del servidor. Hemos estado haciéndolo durante un tiempo.

Entonces, la diferencia esencial es que los de Astro son simplemente mejores. Son más limitados, pero a propósito. Solo se ejecutan en el servidor, y la idea es que eso te impulse a pensar más como una aplicación de servidor. Piensa más como Laravel o Rails. Estás construyendo un HTML al final del día, y luego esas islas de interactividad hacen el trabajo que React está haciendo actualmente para todos.

Entendido. Creo que sé la respuesta a esto, pero no estoy seguro, así que lo preguntaré porque alguien lo preguntó, y quiero asegurarme. ¿Por qué necesitamos una API en Astro para las transiciones de Vue si se podría usar la API del navegador directamente? Esa es una excelente pregunta. Hicimos un par de cosas al respecto. Una de ellas fue que queríamos que fuera compatible hacia atrás, para que no tengas que esperar a los navegadores. Utilizarás esta capa de compatibilidad hacia atrás. Nuestra API se conecta con eso. La segunda es la accesibilidad. Los navegadores tomaron decisiones muy buenas, pero una de las decisiones con las que no estamos de acuerdo es esta idea de que, de forma predeterminada, estas animaciones van a, sin importar lo que le digas, se ejecutarán para todos, y nuestra postura fue que, para las animaciones de página, si tienes sensibilidad al movimiento, estás en un navegador que dice que prefieres un movimiento reducido, deberíamos respetar eso. Hay un par de cosas relacionadas con la accesibilidad y cómo funcionan a nivel inferior, que cualquiera podría hacer por sí mismo, pero creemos que podemos ofrecer una postura más orientada para el caso de uso que es la navegación de una página a otra. No queremos que todos los usuarios tengan que preocuparse por cosas como una API de accesibilidad a nivel inferior si podemos encargarnos de eso por ellos. La tercera es simplemente hacerlo más fácil de usar, así que hay un par de cosas como fade, wipes y slides donde podemos darte una transición con nombre y no tienes que averiguar cuáles son las notas clave, las keyframes, cuáles son las animaciones. Básicamente, se automatiza para ti envuelto en un nombre, y luego puedes distribuirlos tú mismo, puedes hacerlos enchufables. Hay cosas realmente geniales que podemos construir sobre eso de esa manera.

De acuerdo, voy a profundizar un poco en eso porque, como mencioné, realmente me gustan las transiciones de vista y comencé mi vida como consultor de accesibilidad, así que has tocado uno de mis botones. Entonces, si un desarrollador usa los primitivos del navegador, de hecho podrían envolverlo todo en una media query para no mostrar las animaciones si el usuario prefiere un movimiento reducido. Pero tienen que recordarlo, mientras que si usan las API de la capa de Astro, lo recordarás por ellos. Sí. Básicamente, tratamos de usar nuestra influencia como el framework para enviar un conjunto de opiniones, ok, estas son las navegaciones de página. Gran parte de lo que el navegador quería hacer no es tomar una postura de opinión, no todas las animaciones pueden funcionar para la accesibilidad, no todas las preferencias de movimiento reducido, no todas las animaciones desactivadas, porque esa no es realmente la intención, y tú eres el experto aquí, pero la intención es que preferir un movimiento reducido no significa sin movimiento, por lo que el navegador realmente no quería llegar tan lejos como para decir sin movimiento con estas transiciones de vista de página. Pero sabemos que estás haciendo una navegación de página más grande, sabemos que, de forma predeterminada, tiene un poco más de sentido tener esa opinión. Entendido. Como persona de accesibilidad, apruebo mucho las herramientas que ayudan a los desarrolladores a recordar estas cosas. Y nuevamente, si no te gustan nuestros valores predeterminados, simplemente impleméntalo tú mismo. No hay nada en nosotros que te impida usar la API nativa. Somos como el envoltorio auxiliar encima de eso. Hubo otra pregunta, no puedo verla ahora, pero alguien estaba preguntando que Chromium tiene dos niveles diferentes de transiciones de vista. Está la que funciona en un solo documento, y luego está la que funciona entre documentos. Safari hasta ahora solo ha implementado la primera, que son las transiciones de vista dentro del mismo documento.

¿Astro proporcionará un polyfill para el nivel 2 en Safari hasta que Safari lo implemente de forma nativa? Sí. Hasta la semana pasada, nadie había implementado ese nivel 2, y durante el último año, hemos estado enviando ese polyfill como lo mejor que se puede hacer, a menos que estés trabajando con navegadores Canary o beta. Si estás trabajando con un navegador convencional, esa API SPA de nivel 1 en JavaScript fue en lo que nos basamos para aprovechar esto. Así que hacíamos ese trabajo de básicamente enviar un enrutador para que pudieras usar esa API en JavaScript, y lo nuevo a partir de esta semana es la idea de poder, por primera vez, eliminar ese enrutador y aprovechar el nivel 2 completo en Chrome, Edge y cualquier navegador Chromium que quiera actualizarse a la última versión.

Genial. ¿Cuánto tiempo más tenemos? Creo que tenemos horas. Así que algunas preguntas rápidas de personas que preguntan, ¿puedo usar X con Astro, o puedo usar esta cosa con Astro? Primero, Fred, ¿qué CMS recomendarías para usar con Astro? Trabajamos con muchos CMS, Storyblok. Son patrocinadores aquí. Son uno de nuestros patrocinadores. Antiguo patrocinador. Esto suena como una pregunta plantada, pero en realidad es un gran CMS. Han trabajado con nosotros para asegurarse de que el soporte de Storyblok en Astro sea excelente. Han proporcionado un montón de recursos. Realmente les importa el soporte de Astro para Storyblok. Ha sido un placer trabajar con ellos, así que sí, definitivamente son mi elección.

Entendido. Fred, ¿recomendarías usar Astro para algo como un sitio web de intercambio de videos como YouTube? Entonces, encuentro fascinante la dinámica entre contenido y aplicaciones. Como, creo que puedes pensar en cualquier sitio en un espectro desde la izquierda hacia la derecha, y se vuelve realmente complicado cuando intentas pensar, ¿está un sitio de intercambio de videos un sitio de contenido, o es más bien una experiencia dinámica similar a una aplicación? Yo diría que en su mayoría es un sitio de contenido. Se trata de obtener un video. Se trata de obtener contenido, incluso si ese contenido es un video, no HTML, para el usuario lo más rápido posible. Pero a medida que comienzas a pensar en cómo se ve un sitio de videos, hay recomendaciones, hay comentarios, cuanto más y más YouTube, o Twitch, creo que es otro buen ejemplo, comienza a sentirse como una aplicación, más y más eso no es realmente para lo que Astro está diseñado. Si todo en tu página es un componente del cliente, a veces un framework que básicamente envía una aplicación podría ser más adecuado para eso. Entonces, la historia de rendimiento de Astro es excelente, pero en cierto punto, si tienes mucho estado del lado del cliente, ahí es donde empezamos a decir que consideres tus opciones. Hay un montón de excelentes frameworks web. Ese es el equilibrio en el que nos gusta pensar cuántos componentes realmente tienes en la página. Si es todo, es posible que necesites una SPA. Es posible que necesites un framework web diseñado para aplicaciones, no para sitios de contenido. Me parece interesante que hayas dicho eso hay un espectro entre sitio web y aplicación web en lugar de que sean cosas inherentemente diferentes. Personalmente, creo que las transiciones de vista difuminan aún más esa distinción porque ahora puedes tener lo que parece una aplicación de una sola página, pero en realidad son varios documentos HTML, o lo que en los viejos tiempos llamábamos un sitio web. Sí, me encanta ese ejemplo de Spotify porque pienso en Spotify como una aplicación, pero en realidad, ¿cuánta interactividad hay por parte del cliente? Hay hacer clic en las canciones. Hay reproducir la música, pero en realidad no es... Puedes llegar muy lejos, creo, solo con HTML, como puedes ver en ese ejemplo. Entonces, creo que hay un montón de cosas que consideramos como aplicaciones que no son tan interactivas como podrías pensar, y ahí es donde creo que las transiciones de vista van a empujar eso considerablemente. No tienes que enviar algo que tarde segundos en cargarse en tu navegador si puedes simplemente enviar el HTML y hidratarlo después.

Genial. Podría hablar de esto durante horas, pero la luz roja de terror está parpadeando. Así que, gente de JS Nation, por favor, aplaudan a Fred Coolshot. Gracias. Gracias.