Gatsby frente a Next.js para el desarrollo de webs

A primera vista, Gatsby y Next.js pueden parecer prácticamente iguales. Los dos son frameworks basados en React, hacen SSR y SSG y tienen comunidades enormes. Usamos ambas tecnologías a diario, pero creemos que cada una encaja mejor en casos de uso distintos. A menudo nos preguntan por qué elegimos Gatsby en lugar de Next.js para desarrollar webs, y en este artículo lo explicamos en detalle.

Al elegir la tecnología para desarrollar una web, hay que tener en cuenta varios factores:

• Velocidad de desarrollo
• Experiencia editorial
• Mantenibilidad
• Escalabilidad
• Personalización

Así podría quedar una tabla comparativa de funcionalidades entre ambos frameworks. Son casi idénticos, ¿verdad?

Sin embargo, esas pequeñas diferencias pueden tener un impacto enorme en el desarrollo de una web.

Veamos ahora qué necesita tener una web y cómo resuelve cada framework las mismas tareas.

Todo empieza (o acaba) con el favicon

Es un detalle pequeño y sencillo que tienen todas las webs. Pero, para cubrir los distintos casos de uso, sistemas operativos y navegadores, normalmente necesitas más de uno: 16x16, 32x32, 180x180, 512x512, etc. Se agradece no tener que preocuparse de ello.

...y con Gatsby, no tienes que hacerlo

Cambias una sola línea en gatsby-config.js y subes un favicon en png, jpg o svg... y listo. Gatsby genera el conjunto de iconos necesario siguiendo las buenas prácticas y optimiza la imagen sin ningún trabajo adicional.

...pero ¿y con Next.js?

Next.js no propone ninguna forma concreta de hacerlo. Búscalo en Google y verás lo distintas que son las respuestas; por ejemplo, este hilo de Stack Overflow. Todo hay que hacerlo a mano: optimizar la imagen, redimensionarla e insertar las etiquetas adecuadas con la etiqueta <Head>. Como alternativa, puedes usar generadores de favicons como este.

El futuro ya está aquí: optimización de imágenes

Los dos hacen mucha magia: procesan las imágenes con la librería sharp y admiten formatos modernos como webp y avif, lo que se traduce en archivos más ligeros y una web que carga más rápido.

Ambos tienen su propio componente de imagen, next-image y gatsby-image, con una API parecida. Pero hay algunas diferencias.

¿Es bueno next-image?

next-image es solo un componente: la optimización real se hace a través de una ruta de API que recibe parámetros en la query string y devuelve la imagen procesada, por ejemplo, /\_next/image?url=http://example.com/avatar.png&w=32&h=32

Esta arquitectura me gusta porque aporta flexibilidad extra: puedes usar imágenes optimizadas sin necesidad de un componente de React.

Otro detalle importante: next-image te obliga a indicar el ancho y el alto de la imagen, algo que no tienes cuando obtienes los datos de un CMS, salvo que uses layout="fill"; pero entonces tienes que gestionar a mano la lógica del contenedor de la imagen. Así que, para evitar saltos de maquetación, tienes que obtener la imagen del CMS, sacar su ancho y su alto y después, por ejemplo, usar la propiedad CSS aspect-ratio o recurrir al truco del SVG, como hace gatsby-image automáticamente, para mantener las proporciones originales.

¿O es mejor gatsby-image?

gatsby-image no tiene ese endpoint de API y hace la magia por detrás gracias a su capa de datos GraphQL y a distintos plugins de transformación. Todo funciona desde el primer momento, sin configuración adicional. Pero hay algo más que Gatsby hace mejor: la dirección de arte de imágenes. La dirección de arte consiste en definir varios srcsets para distintos tamaños de pantalla, con recortes y encuadres diferentes. El caso típico es un diagrama grande, pongamos en la home, que en móvil quedaría demasiado pequeño si simplemente lo reducimos. La solución es pasar al srcset optimizado para móviles una imagen alternativa con las etiquetas del diagrama más grandes.

La importancia de la integración con el CMS

Para ofrecer la mejor experiencia al cliente, es muy valioso dar a los editores la máxima flexibilidad y contar con una integración sólida con el CMS. En las webs que desarrollamos, cada palabra y cada página se puede editar desde el CMS, igual que cualquier metadato adicional: URL de la página, meta tags, etiquetas og, etc. La mayoría de las veces usamos WordPress headless, pero a veces trabajamos con Contentful, Strapi o Prismic, así que tener una forma flexible y sencilla de obtener datos de distintas plataformas es fundamental.

Gatsby y el poder de los plugins

Con Gatsby, la integración es cuestión de instalar un plugin y añadir las claves de API. No hace falta pelearse con SDKs ni empaparte de la documentación de la API. Todo se obtiene y se añade a una capa GraphQL unificada de Gatsby. Hay tantísimos plugins que encontrarás un source plugin prácticamente para cualquier cosa. ¿El cliente usa una plataforma de selección de personal y quiere mostrar las ofertas de empleo también en su web? Sin problema. ¿Quiere mostrar una lista de repositorios de GitHub con el contador de estrellas? Busca el plugin correspondiente y listo. Los datos se añaden a GraphQL y no tienes que preocuparte por la curva de aprendizaje de cada API.

El enfoque a medida de Next.js

Next.js no tiene un ecosistema de plugins, así que para obtener datos de un CMS tenemos que buscar el SDK, aprender su API, pensar en cómo reutilizar esa integración en distintas páginas de la web y, probablemente, crear wrappers del SDK para los casos más habituales o algún HOC. En webs pequeñas puede ser asumible, pero en las grandes obliga a dedicar tiempo a pensar en la arquitectura global de obtención de datos y en la escalabilidad de la solución.

¿Previsualizar o no previsualizar?

Vale, demos un paso atrás, porque estoy seguro de que mucha gente ni se plantea ofrecer esta funcionalidad a los editores. La previsualización consiste en renderizar bajo demanda una página concreta desde el CMS sin publicarla en producción.

Si usas Gatsby, es compatible con los CMS más populares y funciona sin fricciones. Puedes usar Gatsby Cloud, que crea automáticamente el servidor de previsualización, de modo que solo tienes que apuntar el CMS a la URL correcta, o puedes desplegar una versión autoalojada ejecutando gatsby con GATSBY_ENABLE_REFRESH_ENDPOINT=true. A continuación tienes un ejemplo de cómo funciona con Gatsby y WordPress headless.

Con Next.js, una vez más, la cosa se complica; consulta la documentación oficial. De nuevo, hay que programarlo a mano para cada entidad que quieras previsualizar, definiendo cómo se interpretan los datos que llegan desde el disparador de la previsualización, qué se obtiene después y qué se renderiza. En lugar de los cinco minutos de configuración de Gatsby, tendrás que invertir horas para conseguir algo usable.

Flexibilidad para los editores con la generación programática de páginas

Opciones en Next.js

Para ofrecer una experiencia editorial de primer nivel, los editores deben poder decidir las URLs y las páginas que se muestran en ellas. Rompamos la costumbre y empecemos esta vez por Next.js. Hay varias opciones para conseguirlo, total o parcialmente.

1. Fijar en el código las URLs de las subpáginas dinámicas, p. ej. pages/post/[slug].js. Por ejemplo, en el CMS hay un campo slug para cada post y acordáis que siempre irá bajo /post; después defines getStaticPaths en el componente.

2. Crear un componente comodín en la raíz, pages/[...path].js, y después un componente envoltorio adicional con la lógica que asigna cada URL a un componente concreto. Esto genera bastantes problemas y aumenta mucho la complejidad de la arquitectura.

3. Usar Faust, un framework construido sobre Next.js y ajustado específicamente para integrarse con WordPress. Si miras el código fuente, verás que hace exactamente lo de la opción 2) y lo complejo que resulta. Además, solo sirve para WordPress.

A la manera de Gatsby

Gatsby nació como framework SSG, así que tiene algunos conceptos de arquitectura muy potentes:

1. Un único punto de generación programática de páginas en gatsby-node.js. Imagina que le dices al framework en lenguaje natural: «Obtén todas las páginas del CMS, crea para cada una su página de Gatsby a partir de una plantilla y hazla accesible en la URL definida en el CMS». Así podemos usar plantillas distintas para cada página según los datos del CMS.

2. El concepto de plantillas. Separar las páginas de las plantillas facilita combinar URLs fijas en el código con páginas creadas programáticamente a partir de plantillas.

El resultado es que puedes crear rutas y páginas controladas por completo desde el CMS sin complicarte con una lógica enrevesada en el código.

Queremos Incremental Static Regeneration

La Incremental Static Regeneration (ISR) permite actualizar solo determinadas páginas de forma incremental, en lugar de reconstruirlas todas cada vez que llegan cambios. Técnicamente, los builds incrementales no son lo mismo que la ISR, pero ambos intentan resolver el mismo problema: acelerar las actualizaciones de contenido en producción actualizando las páginas de forma incremental. Gatsby tiene builds incrementales desde la v3 y los aprovecha a fondo con distintas integraciones de CMS y con Gatsby Cloud, reconstruyendo solo lo nuevo, lo que normalmente lleva apenas unos segundos.

Next.js seguía un enfoque algo distinto que no requería lanzar un build adicional cuando cambiaba algo en el CMS. En su lugar, permitía indicar durante cuántos segundos se serviría la página desde la cache; pasado ese tiempo, iba a buscar los datos nuevos cuando llegaba el primer usuario desafortunado.

Al principio pensaba incluir esto como desventaja de Next.js. Era una funcionalidad muy demandada, pero mientras escribía el artículo presentaron la ISR bajo demanda, que debería resolver el problema al permitir revalidar la cache mediante llamadas externas. Desde el 17 de febrero se considera una funcionalidad en beta.

Consultas de datos en cualquier parte

Otra funcionalidad muy demandada en Next.js es poder consultar datos, al estilo de getServerSideProps o getStaticProps, a nivel de componente y no solo en la página padre. Hoy por hoy tienes que recurrir al props drilling o a stores/context para pasar datos desde el nivel superior a los componentes inferiores. React 18 y los Server Components deberían resolver este problema en el futuro.

Mientras tanto, en un proyecto con Gatsby puedes obtener datos de la capa GraphQL global desde cualquier sitio con useStaticQuery. Esto simplifica la arquitectura y te permite tener componentes reutilizables.

Importaciones muy externas

Es una novedad reciente de Next.js y tiene toda la pinta de convertirse en una gran ventaja a la hora de combinar soluciones Low-Code / No-Code con aplicaciones programadas a mano. Para entender esta funcionalidad, lo mejor es leer este magnífico ejemplo de uso entre Framer y Next.js. Puedes crear un componente personalizado en un editor visual, añadirle quizá alguna animación vistosa y después importarlo al proyecto con una sola línea:

Es impresionante y abre muchísimas posibilidades. Gatsby no permite hacerlo por ahora, así que, si es algo que quieres usar en tu proyecto, probablemente Next.js sea mejor opción.

Los sitemaps siempre suman

Ambos frameworks lo resuelven con librerías adicionales. Gatsby lo hace con un plugin y una configuración mínima. En Next.js, una librería hace lo mismo, pero requiere ejecutar un script adicional después del build.

i18n sin complicaciones

Lo curioso de este punto es que, aunque la implementación es casi idéntica en ambos frameworks, otra funcionalidad de Next.js llamada Global Middlewares la hace mucho más potente. Permite definir un middleware de nivel superior y, por ejemplo, detectar el país del usuario en la red edge y después servirle o redirigirle a una página generada estáticamente.

Conclusión

Podemos seguir recomendando ambos frameworks para desarrollar webs como soluciones muy fiables. Aun así, Gatsby funciona claramente mejor en generación estática y en integraciones gracias a su ecosistema de plugins. Para nosotros esas funcionalidades son críticas y vemos cómo Gatsby nos permite crear webs más rápido y hacerlas flexibles y fáciles de mantener. Next.js es un framework más orientado a lo dinámico, y yo lo elegiría solo si necesitara una capa adicional de autenticación en la web o esa funcionalidad de Global Middleware que ayuda con la i18n, los tests A/B o los feature flags. Son funcionalidades muy interesantes, pero normalmente solo hacen falta en proyectos enormes de nivel enterprise, donde uno puede permitirse ese tipo de experimentos.