Astro es un regreso a los fundamentos de la web

 (websmith.studio)
17 puntos por GN⁺ 2025-07-10 | 1 comentarios | Compartir por WhatsApp

"Astro es el mejor framework para desarrolladores"

  • Astro es un nuevo tipo de framework web optimizado para sitios centrados en contenido, y ofrece por defecto una política de Zero JavaScript, gran rendimiento y una experiencia de desarrollo sencilla
  • Con un enfoque único llamado Island Architecture, aplica JavaScript solo donde hace falta, mientras que el resto se maneja como HTML estático y rápido
  • Los sitios hechos con Astro muestran velocidades de carga más de un 40% más rápidas que las basadas en React tradicional, lo que aporta beneficios reales en SEO, experiencia de usuario y tasa de conversión
  • A diferencia de otros frameworks, separa claramente la lógica de datos y los componentes de frontend, y además puede mezclarse con frameworks como React y Vue
  • Eso sí, si se necesita SPA, manejo de estado complejo o routing a gran escala, frameworks tradicionales como Next.js pueden ser más adecuados

Qué es Astro

  • Astro es un framework web que apareció en 2021 y, a diferencia de los frameworks JS existentes pensados para apps complejas, fue diseñado con enfoque en sitios centrados en contenido
  • Su filosofía base es "contenido primero, servidor primero y Zero JavaScript por defecto", y una de sus fortalezas es que su tooling también es intuitivo y fácil de usar

Island Architecture

  • Astro introduce el concepto de "Island Architecture", con el que aplica JavaScript solo a ciertas partes necesarias en lugar de a toda la página
  • En páginas como una entrada de blog, donde casi todo es texto, se renderiza únicamente en HTML, y solo se carga JS en partes que requieren interacción, como comentarios o carruseles
  • Gracias a esto, la página es muy rápida y ligera

Rendimiento y efectos reales

  • Los sitios basados en Astro registran cargas más de un 40% más rápidas que los frameworks React tradicionales
  • Estas mejoras de rendimiento se traducen en resultados de negocio como mejor ranking en buscadores, mayor satisfacción del usuario y mejor conversión
  • En dispositivos lentos o redes de baja velocidad, la diferencia de velocidad se percibe todavía más

Experiencia de desarrollo (Developer Experience)

  • La configuración del proyecto es simple, y un amable asistente de configuración llamado “Houston” guía el proceso
  • Los componentes de Astro permiten lógica que se ejecuta solo en build time (por ejemplo, obtención de datos o llamadas a API)
  • Sin tener que preocuparse por manejo de estado complejo, lifecycle o hooks, es posible usar JS del lado del cliente solo cuando hace falta

Compatibilidad con distintos frameworks

  • Frameworks principales como React y Vue pueden combinarse libremente con Astro
  • Por ejemplo: un panel de administración en React, visualización de datos en Vue y el resto del sitio en Astro

Funciones prácticas que sí “funcionan”

  • Se puede importar Markdown directamente y usarlo como si fuera un componente
  • Soporta pipelines de build modernos como TypeScript, Sass, optimización de imágenes y hot module replacement
  • También permite elegir entre sitio estático / SSR / renderizado híbrido, con flexibilidad para adaptarse al tipo de proyecto

Dónde destaca Astro

  • Ofrece un rendimiento sobresaliente en sitios centrados en contenido como sitios de marketing, blogs, catálogos de e-commerce y portafolios
  • Es ideal en entornos donde no se necesita manejo complejo de estado del cliente

Trade-offs

  • En proyectos donde son importantes las SPA, el routing complejo o el estado compartido entre componentes, otros frameworks como Next.js pueden ser una mejor opción
  • Su ecosistema todavía es pequeño, y el routing basado en archivos puede sentirse limitado en proyectos grandes

Cómo empezar rápido

  • npm create astro@latest my-site
  • Si hace falta, agregar un framework con npx astro add react
  • Añadir páginas en src/pages/ y componentes en src/components/ para empezar a desarrollar

El significado de Astro

  • En un momento en que los frameworks JS se vuelven cada vez más complejos, Astro representa un regreso a los fundamentos de la web (una experiencia centrada en contenido, rápida y accesible) sin sacrificar la comodidad de desarrollo
  • Su filosofía de diseño —“sitios rápidos por defecto, interactividad solo donde se necesita y libertad para usar el framework que quieras”— resulta muy atractiva para los desarrolladores
  • Desde blogs hasta e-commerce, Astro es una recomendación sólida para proyectos centrados en contenido

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-10
Comentarios de Hacker News

  • Los frameworks web tradicionales siempre “hidrataban” toda la página con JavaScript; por ejemplo, aunque una entrada simple de blog tuviera solo un widget interactivo, todo se manejaba con JavaScript. En cambio, Astro usa HTML estático por defecto y solo hace que las partes necesarias funcionen como “islas de JavaScript”. Antes a esto se le llamaba “progressive enhancement” o simplemente “página web”, y era el estándar para crear sitios web. Luego llegaron las SPA y el progressive enhancement se fue usando cada vez menos. Ahora lo llaman “islas de JavaScript”, pero al final es volver a la forma anterior. A los nuevos desarrolladores web que tengan interés les recomendaría el concepto de progressive enhancement

    • Muchas veces alguien escucha la descripción de una herramienta nueva y cree por error que es lo mismo que ya se hacía antes. Pero el verdadero valor de Astro está en que se integra con distintos frameworks de JavaScript y permite que solo subárboles parciales del HTML sean manejados por cada uno; en ese proceso, el estado inicial se renderiza como cadena y se hidrata del lado del cliente con datos obtenidos por adelantado. Tiene valor cuando quieres usar frameworks como React/Svelte/Solid/Vue solo en partes de la página y cargar datos previamente desde el servidor. Dicho eso, este enfoque no es “progressive enhancement”. El HTML previo a la hidratación no necesita funcionar correctamente; por ejemplo, un <form> no tiene por qué funcionar sin JavaScript. Son justo esos detalles los que uno descubre si se acerca con curiosidad en vez de con cinismo

    • Totalmente de acuerdo, Astro es una gran herramienta, pero lo más difícil fue entender toda la terminología que inventaron los desarrolladores contratados después de 2010 para explicar cómo funciona la web

    • No es una idea nueva, pero el enfoque actual se siente mucho más refinado. Antes hacía web interactiva con PHP y jQuery, en la época previa a React y las SPA. Viéndolo ahora, arquitectónicamente el enfoque antiguo era más elegante, pero en ese entonces el debugging y la DX eran realmente malos. No quisiera volver a pasar tiempo depurando frontend con PHP. Las SPA siguen teniendo utilidad en dashboards complejos o apps interactivas. Astro te permite manejar el código del servidor y del cliente en un mismo lugar, con una separación clara, así que ya no hace falta parsear datos en PHP para pasarlos a JS, y eso mejora muchísimo la DX

    • Me acuerdo de cuando esto se llamaba AJAX. Siento que se perdió por completo el hilo

    • Creo que los primeros frameworks web sí acertaban de verdad en cómo abordar sitios sin estado y renderizado del servidor

  • Personalmente recomiendo Astro con entusiasmo. Al principio lo veía como una “herramienta que solo añade includes a html y css”, pero cuando lo usé para mi sitio personal y para renovar el sitio de Matrix Conference, fue realmente agradable porque pude usarlo sin complicaciones
    Ventajas principales de Astro:

    • Sigue centrado en html y css
    • Después del build, js no es necesario por defecto
    • Puedes añadir js de forma selectiva solo donde haya interactividad
    • La función de colecciones de contenido está bien diseñada
    • La optimización de velocidad está extremadamente bien lograda, y los maintainers saben muy bien cómo hacerlo
    • Tiene un Devbar para desarrollo que muestra visualmente dónde el sitio puede ser más rápido (por ejemplo, lazy load de imágenes bajo el pliegue)
    • El minificador de CSS inserta parte del CSS inline para reducir consultas adicionales
    • El componente de imágenes configura automáticamente atributos width/height para evitar content layout shift y también ofrece imágenes responsivas

    • Si Astro está centrado en html y css y solo agrega js cuando hace falta, entonces la experiencia sería la misma si uno crea y despliega directamente archivos .html, .css y .js en un directorio. Incluso me pregunto si eso no sería más rápido, sin overhead en tiempo de desarrollo ni bloat innecesario. Además, que el CSS vaya inline nunca ha sido realmente un gran problema de rendimiento; por experiencia con cientos de sitios, casi nunca el CSS era el cuello de botella, en la práctica el problema era la red

    • Lo único que me decepcionó un poco es que, a medida que el routing se vuelve más complejo, la abstracción aumenta muy rápido y termina siendo más confusa. Como la complejidad siempre trae fricción, al final elegí otro enfoque

    • Si lo que necesitas son “includes en html y css”, puedes simplemente habilitar server-side includes en un servidor web común como nginx. Es una solución estable desde hace más de 20 años y casi no requiere mantenimiento. Tampoco añade riesgos de seguridad extra como un motor de templates; permite evitar redundancia y hacer includes puros sin preocuparte por vulnerabilidades de backend

    • Después de 20 años haciendo solo datos/backend, volví por un proyecto frontend y, tras sufrir con React, cambiar a Astro+Svelte fue realmente un éxito. Como está centrado en HTML/CSS, la estructura del código es predecible y limpia, y cuando pasé el frontend a desarrolladores con experiencia en React, se adaptaron casi de inmediato

  • Ver que se use “frameworks tradicionales” para referirse a frameworks de SPA/Virtual DOM me hace sentir la diferencia generacional. Backbone, jQuery y similares eran los verdaderos frameworks web tradicionales, y justo ellos funcionaban como describe la entrada

    • Creo que lo “tradicional” al final depende de cuándo naciste. Para mí, el internet tradicional es el módem de 56k, los foros vbulletin, mods de GTA:VC, IRC, etc.; para una generación más vieja serían los BBS, y para una más joven, Discord sería el internet “tradicional”. En política pasa algo parecido: todos tienden a pensar que la época en la que eran jóvenes era la mejor

    • Recuerdo que Backbone apuntaba a MVC del lado del cliente para SPA puras

  • Me pregunto por qué frameworks SSR como Astro, NextJS y otros no soportan páginas estáticas con rutas dinámicas como lo hace SvelteKit. Por ejemplo, una página como /todos/[todoId] en NextJS ni siquiera puede entrar en un static bundle. En cambio, SvelteKit usa 404.html y, aunque técnicamente sea un 404, funciona perfectamente en entornos como Cloudflare o webviews móviles. Esa capacidad es especialmente útil al empaquetar para webviews móviles

    • Estoy parcialmente de acuerdo, pero este diseño también tiene desventajas. Si haces hard reload de una URL como /todos/123 en una SPA, el navegador le pide al servidor el archivo real correspondiente, y si no existe, recibe un 404. Entonces la página 404 tiene que volver a cargar datos y procesarlos mediante client routing, y para eso hace falta configuración del servidor HTTP, como nginx. O sea, no es posible solo con archivos estáticos puros. Además, según la especificación HTTP, la caché del navegador nunca almacena respuestas 404, así que en hard reload o al abrir marcadores jamás puedes aprovechar caché. Si esa configuración te resulta pesada, creo que a veces es mejor usar query parameters y manejarlo como /todo?id=123

    • Puede que yo lo haya entendido mal, pero sí he implementado routing/páginas dinámicas en builds estáticos de Next o Astro. Cuando usé contentful o storyblok como CMS, dejé que los editores crearan rutas y componentes libremente, y cubrí todas las rutas con el patrón [...slug]. Aproveché la función getStaticPaths para pregenerar todas las páginas. Si activas las opciones ISR/ISP, también se prerenderizan dinámicamente páginas que no se conocían en build time. En Next se llama dynamic routes, y en Astro dynamic pages
      Referencia: Next dynamic routes, Astro dynamic pages

    • Tal vez entendí mal, pero la función getStaticPaths de Astro parece soportar justamente lo que quieres
      Referencia

    • A mí también me gustan los despliegues estáticos, así que lo menciono como referencia: NextJS también soporta generate static params

    • No es que entienda por completo Astro o todos estos frameworks, pero quizá te convenga revisar si server islands de Astro se parecen a lo que estás buscando

  • Toda la discusión de frontend me parece demasiado confusa. Al final, incluso lo que plantea el artículo se reduce a “¿vamos a usar el navegador como HMI o como runtime de aplicaciones?”. Pero la mayor parte del debate termina en afirmaciones vagas como “se siente fresco” o “carga rápido”. Me parece que la forma en que se promocionan los frameworks, casi como marcas, se parece demasiado a la industria de la moda

    • Justamente la industria de la moda me parece la mejor analogía para explicar las discusiones sobre frameworks frontend. Casi nunca se examinan con rigor técnico afirmaciones como “content-driven” o “server-first”

    • No entiendo cómo se puede decir que “carga rápido” es una ilusión; es un factor realmente importante

  • Hace poco hice el sitio web de una institución médica con Astro, y fue muchísimo más fácil que cuando antes lo hacía con Wordpress. Además, puede alojarse gratis en sitios como Netlify, así que uno no tiene que preocuparse por hackeos. Incluso hice un CMS simple basado en git para que el cliente pudiera editar contenido por su cuenta. Siento que el desarrollo web de verdad ha avanzado muchísimo

    • Me da curiosidad saber si fue un favor para alguien conocido o cómo consigues encargos de sitios web para instituciones médicas

    • Ojo con que Netlify tiene tarifas de ancho de banda más altas que Vercel

  • La mayor ventaja de Astro es que puedes trabajar solo con HTML o Web Components, sin depender de otros frameworks como React o Vue. Aun así, Astro también soporta SSR, ISR, SSG y middleware, igual que Next o Nuxt
    La diferencia está en la arquitectura de islas, que permite implementar micro frontends
    Por ejemplo, aunque distintos equipos dentro de una empresa construyan por separado pagos, carrito o páginas de producto, todo puede integrarse en una sola página. Además, puedes controlar directamente el método de renderizado
    También se puede compartir estado global, así que cada equipo puede asumir responsabilidad completa y desarrollar/desplegar su parte de forma independiente
    Eso sí, esta estructura es una solución que hace falta sobre todo en proyectos grandes. Si cada equipo usa React a su manera, terminas con distintas versiones mezcladas, pero al separarlo arquitectónicamente con Astro, ese problema se resuelve
    Personalmente no estoy seguro de que vaya a cambiar por completo la web; se siente más bien como Next/Nuxt pero sin dependencia obligatoria del framework y con arquitectura de islas añadida. Aun así, recomiendo probarlo
    Si quieres salir de React/Vue, migrar a web-component o reemplazar Next/Nuxt, Astro es recomendable porque te permite hacerlo de forma gradual

  • Para mí, Astro no es perfecto para todos los casos. A veces, si solo necesitas offline rendering, no hay razón para forzar JavaScript.
    La arquitectura de islas también tiene límites, y muchas veces el resultado compilado termina con demasiado contenido inlineado
    Sinceramente, creo que el hype de Astro se debe más a Vite. Vite sí que es excelente

    • Me gustaría preguntar en qué casos “la arquitectura de islas llega a sus límites”

  • Ojalá dejaran de recomendar Next.js como el framework estándar de React. Hace falta más pensamiento crítico en frontend. Remix (React Router v7) o TanStack son alternativas mucho mejores

    • También estoy de acuerdo. Next.js sí tenía potencial, pero siento que se degradó mucho desde que Vercel se involucró. Lo uso desde la v10, y tras pasar por el caos de la v13 hasta la v15, terminé bastante decepcionado. React y Next.js cambian demasiado rápido como para seguirles el ritmo, y siento que hay más cambios por cambiar que cambios realmente necesarios

    • Incluso quisiera que dejáramos de recomendar React en sí como framework por defecto. Para desarrollo frontend, HTML/CSS/JS me parece mucho mejor

    • Creo que Remix/React Router v7 va en la dirección correcta. Sobre todo, si Remix adopta preact y se centra en los estándares web, tal vez volvamos a una forma más sólida de construir sitios web. Eso sí, la transición de Remix a RR7 no fue nada fluida y tuve que reescribir el proyecto

  • Creo que los principios fundamentales de la web siguen vigentes. Desde la perspectiva de quienes usan PHP, Spring, Quarkus o ASP.NET MVC, quizá no se percibe lo difícil que se ha vuelto el desarrollo web basado en frameworks de JS. Siento que, por culpa de una industria tan impulsada por modas, no es fácil volver a lo básico