El final de mi viaje Gatsby

Se acabaron los “dolores de cabeza de Gatsby” . Juan Diego Rodríguez reflexiona sobre su decisión de dejar de utilizar a Gatsby como marco de referencia. A través de un examen detallado de sus fortalezas y debilidades, proporciona información valiosa y opciones alternativas para los desarrolladores que navegan por sus opciones de herramientas.

Un dato curioso sobre mí es que mi cumpleaños es el día de San Valentín. Este año quería celebrarlo lanzando un sitio web sencillo que permite a las personas recibir cartas anónimas a través de un enlace personal. La idea se me ocurrió a principios de febrero, así que quería terminar el proyecto lo antes posible ya que el tiempo apremiaba.

Teniendo esto en cuenta, decidí no hacer SSR/SSG con Gatsby para el proyecto, sino optar por una aplicación de una sola página (SPA) usando Vite y React, una decisión bastante difícil considerando mi amplia experiencia con Gatsby. Hace años, cuando comencé a usar React y a aprender más y más sobre el intrincado panorama web actual , elegí Gatsby.js como mi marco de renderizado preferido porque SSR/SSG era necesario para cada sitio web, ¿verdad?

Lo usé para todo , desde el sitio web más básico hasta el proyecto más complejo. Me encantó y pensé que era la mejor herramienta, y tenía una confianza increíble en mi decisión ya que estaba obteniendo puntuaciones perfectas de Lighthouse en el proceso.

Pasaron los años y me encontré luchando constantemente con los complementos de Gatsby, recurriendo a soluciones pirateadas para ellos e incluso pasando más tiempo esperando a que se iniciara el servidor. Sentí que estaba arreglando más que haciendo. Incluso comencé una serie para esta revista sobre los “dolores de cabeza de Gatsby” que más experimenté y cómo superarlos.

Era como si Gatsby se volviera más difícil de usar con el tiempo debido a muchos problemas no solucionados: dependencias obsoletas, arranques en frío, compilaciones lentas y complementos obsoletos, por nombrar algunos. Comenzar un proyecto de Gatsby se volvió tedioso para mí y las partituras perfectas de Lighthouse no podían compensar eso.

Entonces, decidí dejar de usar Gatsby como mi marco de referencia.

Para mi sorpresa, la combinación Vite + React que mencioné anteriormente resultó ser mucho más eficiente de lo que esperaba y al mismo tiempo mantuvo casi las mismas excelentes medidas de rendimiento que Gatsby. Es una conclusión difícil de digerir después de años de lealtad de Gatsby.

Quiero decir, sigo pensando que Gatsby es extremadamente útil para muchos proyectos y planeo hablar de ellos en un momento. Pero Gatsby ha sufrido una serie de eventos desafortunados recientemente después de que Netlify lo adquirió, cuyos impactos se pueden ver en los resultados con tendencia a la baja de la encuesta más reciente sobre el estado de JavaScript . La probabilidad de que un desarrollador retome Gatsby nuevamente después de usarlo para otros proyectos se desplomó del 89% a un escaso 38% solo entre 2019 y 2022.

Aunque Gatsby seguía siendo el segundo marco de renderizado más utilizado en 2022 (todavía esperamos resultados de la encuesta de 2023), mi predicción es que la disminución continuará y caerá muy por debajo del 38%.

Dado que esta es mi despedida personal de Gatsby, quería escribir sobre dónde, en mi opinión, salió mal, dónde sigue siendo útil y cómo estoy manejando mis proyectos futuros.

Gatsby: una retrospectiva

Kyle Mathews comenzó a trabajar en lo que eventualmente se convertiría en Gatsby a fines de 2015. Gracias a su capa de datos única y su enfoque SSG, se esperaba que tuviera éxito y logró una ronda inicial de financiación de $ 3,8 millones en 2018 . A pesar de las dudas iniciales, Gatsby se mantuvo firme en su compromiso y se convirtió en un pionero en la comunidad Jamstack al mejorar constantemente su marco de código abierto y traer nuevos y mejores cambios con cada versión.

Entonces… ¿dónde salió todo mal?

Yo diría que fue la introducción de Gatsby Cloud en 2019, ya que Gatsby tenía como objetivo generar ingresos continuos y solidificar su modelo de negocio. Muchos (incluido yo mismo) señalan la caída de Gatsby en Gatsby Cloud, ya que terminaría recortando recursos del marco principal e incluso dificultando el alojamiento en otros proveedores de nube.

El marco central se había optimizado de tal manera que el uso de Gatsby y Gatsby Cloud juntos no requería configuraciones de alojamiento adicionales, lo que, como consecuencia, dificultaba mucho las implementaciones en otras plataformas, tanto por no proporcionar documentación para implementaciones de terceros como por lanzar funciones exclusivas, como compilaciones incrementales , que solo estaban disponibles para los usuarios de Gatsby que se habían comprometido a usar Gatsby Cloud. En resumen, alojar proyectos en cualquier cosa que no fuera Gatsby Cloud parecía una penalización.

Como marco, Gatsby perdió usuarios ante Next.js, como se muestra tanto en las encuestas como en las tendencias de npm, mientras que Gatsby Cloud tuvo dificultades para competir con empresas como Vercel y Netlify; el primero adquirió Gatsby en febrero de 2023 .

“Después de un tiempo quedó claro que [Gatsby] no estaba ganando la batalla del marco contra Vercel, como marco de propósito general [...] Y probablemente estaban un poco encerrados por nosotros en términos de construir una plataforma en la nube. .”

— Matt Biilmann , director ejecutivo de Netlify

La adquisición de Netlify fue la gota que colmó el vaso en un pajar del marco que ya estaba tambaleándose. La migración de Gatsby Cloud a Netlify tampoco fue agradable para los clientes; A algunos equipos se les cobró un 120% más, o habían incurrido en tarifas superfluas , después de realizar la conversión de Gatsby Cloud a Netlify, ¡incluso con el mismo plan de Gatsby Cloud que tenían! Muchas características clave de Gatsby Cloud, específicamente compilaciones incrementales que redujeron los tiempos de compilación de pequeños cambios de minutos a segundos, simplemente ya no estaban disponibles en Netlify, a pesar de que Kyle Mathews dijo que se trasladarían a Netlify :

"Muchas innovaciones de rendimiento específicas para sitios web grandes con mucho contenido, vista previa y flujos de trabajo de colaboración se incorporarán a la plataforma Netlify y, cuando sea relevante, estarán disponibles en todos los marcos".

—Kyle Mathews

Sin embargo, en un hilo del foro de Netlify con fecha de agosto de 2023, apenas seis meses después de la adquisición, un ingeniero de soporte de Netlify contradijo la declaración de Mathews, diciendo que no había planes para agregar funciones incrementales en Netlify .

Eso no dejaba ninguna razón importante para permanecer con Gatsby. Y creo que este comentario en el mismo hilo resume perfectamente el sentimiento colectivo de la comunidad:

“Ay. Gran golpe para los clientes de Gatsby Cloud. La velocidad de construcción incremental fue exactamente la razón por la que cambiamos de Netlify a Gatsby Cloud en primer lugar. Es realmente desafortunado verse obligado a migrar y al mismo tiempo introducir una enorme regresión en el rendimiento y la experiencia”.

La adquisición de Netlify también provocó una reestructuración de la empresa que redujo sustancialmente la plantilla del equipo de ingeniería de Gatsby, seguida de un cese total de las actividades de compromiso. Un informe en un siniestro tweet del cofundador de Astro, Fred Schott, exacerbó aún más las preocupaciones sobre el futuro de Gatsby.

Lennart Jörgens, ex desarrollador full-stack de Gatsby y Netlify, respondió, insinuando que solo quedaba una persona después de los despidos:

Puede ver todos estos factores que contribuyen a la caída del uso de Gatsby en la encuesta Stack Overflow de 2023 .

Biilmann abordó las preocupaciones de la comunidad sobre la viabilidad de Gatsby en un número abierto del repositorio de Gatsby :

"Si bien no planeamos que Gatsby sea el lugar donde se lleve a cabo la principal innovación en el ecosistema marco, será una opción segura, sólida y confiable para construir sitios web y tiendas de comercio electrónico con calidad de producción, y obtendrá nuevos poderes de maneras de grandes herramientas complementarias”.

— Matt Bülmann

También arrojó luz sobre el enfoque futuro de Gatsby:

• “En primer lugar, garantizar la estabilidad, la previsibilidad y el buen desempeño.
• En segundo lugar, bríndele nuevos poderes mediante una fuerte integración con todas las herramientas nuevas que agregamos a nuestra plataforma web componible (para obtener más información sobre todo eso, puede consultar nuestra página de inicio).
• En tercer lugar, hacer que Gatsby sea más abierto desacoplando algunas partes que estaban estrechamente vinculadas a la infraestructura de nube patentada. La función Adaptadores ya lanzada es parte de ese esfuerzo”.

— Matt Bülmann

Entonces, Gatsby dejó de competir contra Next.js en innovación y, en cambio, se centrará en mantener el marco existente limpio y estable en su estado actual. Francamente, este parece el curso de acción más razonable considerando la situación actual.

¿Por qué la gente dejó de usar Gatsby?

Sí, Gatsby Cloud terminó abruptamente, pero como marco independiente de su proveedor de nube, otros aspectos alentaron a los desarrolladores a buscar alternativas a Gatsby.

En lo que a mí respecta, la experiencia de desarrollador de Gatsby ( DX ) se convirtió más en una carga que en una ayuda, y hay dos culpables principales a los que culpo: el infierno de dependencia y los tiempos lentos de agrupación .

Infierno de dependencia

Continúe y comience un nuevo proyecto Gatsby:

gatsby new

Después de esperar un par de minutos, obtendrás tu nuevo sitio de Gatsby. Con razón esperaría tener un borrón y cuenta nueva con cero vulnerabilidades y dependencias obsoletas con esta configuración lista para usar, pero esto es lo que encontrará en la terminal una vez que ejecute npm audit:

18 vulnerabilities (11 moderate, 6 high, 1 critical)

Esto parece preocupante, y lo es, no tanto desde una perspectiva de seguridad sino como una indicación de que DX está decayendo. Como generador de sitios estáticos (SSG), Gatsby, como era de esperar, entregará un sitio estático y seguro que (normalmente) no tiene acceso a una base de datos o servidor, lo que lo hace inmune a la mayoría de los ataques cibernéticos. Además, muchas de esas vulnerabilidades están en las herramientas de desarrollo y nunca llegan al usuario final. Por desgracia, confiar en npm auditevaluar la seguridad de su sitio es, en el mejor de los casos, una elección ingenua .

Sin embargo, esas vulnerabilidades revelan un problema subyacente: la enorme cantidad de dependencias que usa Gatsby es 168 (!) en el momento en que escribo esto. A modo de comparación, Next.js utiliza 16 dependencias. Muchas de las dependencias de Gatsby están desactualizadas, de ahí las advertencias, pero intentar actualizarlas a sus últimas versiones probablemente desatará un infierno de dependencias lleno de advertencias y errores adicionales de npm.

En un subreddit relacionado de 2022, un usuario preguntó: "¿Es posible tener un sitio de Gatsby sin vulnerabilidades?"

La verdadera respuesta es decepcionante, pero a marzo de 2024 sigue siendo cierta.

Un sitio de Gatsby debería funcionar completamente bien, incluso con tantas dependencias, y ampliar su proyecto no debería ser un problema, ya sea a través de su ecosistema de complementos u otros paquetes. Sin embargo, cuando intente actualizar cualquier dependencia existente, encontrará que no puede hacerlo. O al menos no puede hacerlo sin introducir cambios importantes en una de las 168 dependencias, muchas de las cuales dependen de versiones obsoletas de otras bibliotecas que tampoco se pueden actualizar.

Es esa rotonda de dependencias similar a un inicio que yo llamo infierno de dependencia .

Tiempos lentos de construcción y desarrollo

Para mí, uno de los aspectos más importantes a la hora de elegir una herramienta de desarrollo es lo cómodo que resulta utilizarla y lo rápido que es poner en marcha un proyecto. Como dije antes , a los usuarios no les importa ni saben qué es una “pila tecnológica” o qué marco se utiliza; Quieren un sitio web atractivo que les ayude a lograr la tarea para la que vinieron. Muchos desarrolladores ni siquiera se preguntan qué tecnología se utiliza en cada sitio que visitan; Al menos eso espero.

Teniendo esto en cuenta, la elección de un marco se reduce a la eficacia con la que puedes utilizarlo. Si su servidor de desarrollo experimenta constantemente arranques en frío y fallas y no puede reflejar rápidamente los cambios, eso es un DX deficiente y una señal de que puede haber una mejor opción.

Ésa es la razón principal por la que no buscaré automáticamente a Gatsby de ahora en adelante. La instalación ya no es una tarea trivial; las dependencias activan advertencias y el servidor de desarrollo tarda más de 30 segundos en iniciarse. Incluso descubrí que cuanto más tiempo funciona el servidor, más lento se vuelve; Esto me sucede constantemente, aunque admito que no he escuchado quejas similares de otros desarrolladores. De todos modos, me enfurece tener que reiniciar constantemente mi servidor de desarrollo cada vez que hago un cambio en archivos gatsby-config.js, gatsby-node.jsarchivos o cualquier otra fuente de datos.

Esta nueva realidad es particularmente dolorosa, sabiendo que una configuración de Vite.js + React puede iniciar un servidor en 500 ms gracias al uso de esbuild .

Correr gatsby buildempeora. Los tiempos de construcción para proyectos más grandes normalmente toman algunos minutos, lo cual es comprensible si consideramos todas las páginas, fuentes de datos y optimizaciones que Gatsby realiza detrás de escena. Sin embargo, incluso una pequeña edición de contenido en una página desencadena un proceso completo de creación e implementación, y la espera interminable no sólo es agotadora sino que distrae totalmente la tarea de hacer las cosas. Para eso se diseñaron las compilaciones incrementales y la razón por la que muchas personas cambiaron de Netlify a Gatsby Cloud cuando usaban Gatsby. Es una pena que ya no tengamos esa opción disponible.

En el momento en que se suspendió Gatsby Cloud junto con las compilaciones incrementales, los incentivos para continuar usando Gatsby se volvieron prácticamente inexistentes. Los lentos tiempos de construcción son simplemente demasiado costosos para el flujo de trabajo de desarrollo.

Lo que Gatsby hizo increíblemente bien

Sigo creyendo que Gatsby tiene cosas increíbles que otros frameworks de renderizado no tienen, y es por eso que seguiré usándolo, aunque sea para casos específicos, como mi sitio web personal. Simplemente no es mi marco de referencia para todo, principalmente porque Gatsby (y Jamstack) no estaba diseñado para todos los proyectos, incluso si Gatsby se comercializaba como un marco de propósito general.

Aquí es donde veo a Gatsby todavía liderando la competencia:

• La capa de datos GraphQL.
  En Gatsby, todos los datos configurados están disponibles en el mismo lugar, una capa de datos a la que es fácil acceder mediante consultas GraphQL en cualquier parte de su proyecto. Esta es, con diferencia, la mejor característica de Gatsby y trivializa el proceso de creación de páginas estáticas a partir de datos, por ejemplo, un blog a partir de la API de un sistema de gestión de contenidos o documentación a partir de archivos Markdown.
• Desempeño del cliente.
  Si bien la experiencia de desarrollador de Gatsby es cuestionable, creo que ofrece una de las mejores experiencias de usuario para navegar por un sitio web. Las páginas y los recursos estáticos ofrecen los tiempos de carga más rápidos posibles, y el uso de React Router con renderizado previo de enlaces próximos ofrece una de las experiencias más fluidas al navegar entre páginas. También debemos tener en cuenta la increíble API de imágenes de Gatsby, que optimiza las imágenes en todos los niveles.
• El ecosistema de complementos (más o menos).
  Normalmente existe un complemento de Gatsby para todo. Esto es fantástico cuando se utiliza un CMS como fuente de datos, ya que simplemente puede instalar su complemento específico y tener todos los datos necesarios en su capa de datos. Sin embargo, muchos complementos quedaron sin mantenimiento y quedaron obsoletos, lo que introdujo problemas de dependencia irresolubles que vienen con el infierno de dependencia.

Pasé por alto brevemente las partes buenas de Gatsby en contraste con las malas. ¿Eso significa que Gatsby tiene más partes malas? Absolutamente no; simplemente no encontrará las partes defectuosas en ninguna documentación. Las partes malas tampoco son un factor decisivo de forma aislada, pero se convierten en una experiencia de desarrollador larga y tediosa que aleja a sus defensores hacia otras soluciones o marcos de renderizado.

¿Necesitamos SSR/SSG para todo?

Dejaré constancia de que no voy a reemplazar a Gatsby con otro marco de renderizado, como Next.js o Remix, sino que simplemente los evitaré por completo. Descubrí que en realidad no son necesarios en muchos casos.

Piense, en primer lugar, ¿por qué utilizamos cualquier tipo de marco de renderizado? Yo diría que es por dos razones principales: robots de rastreo y tiempo de carga inicial .

SEO y robots de rastreo

La mayoría de las aplicaciones de React comienzan con un cuerpo hueco y solo tienen etiquetas vacías dival lado script. Luego, el código JavaScript se ejecuta en el navegador, donde React crea el DOM virtual e inyecta la interfaz de usuario renderizada en el navegador.

En redes lentas, los usuarios pueden notar una pantalla blanca antes de que la página se muestre, lo cual es levemente molesto en el mejor de los casos (pero devastador en el peor ).

Sin embargo, los motores de búsqueda como Google y Bing implementan robots que sólo ven una página vacía y deciden no rastrear el contenido. O, si está vinculando una publicación en las redes sociales, es posible que no obtenga los beneficios de OpenGraph, como una vista previa del enlace.

body  div/div  script type="module" src="/src/main.tsx"/script/body

Este fue el caso hace años, lo que hizo que SSR/SSG fuera necesario para que los robots de Google se dieran cuenta. Hoy en día, Google puede ejecutar JavaScript y representar el contenido para rastrear su sitio web. Si bien el uso de SSR o SSG hace que este proceso sea más rápido, no todos los bots pueden ejecutar JavaScript. Es una compensación que puede hacer para muchos proyectos y que puede minimizar en su proveedor de nube al renderizar previamente su contenido.

Tiempo de carga inicial

Las páginas pre-renderizadas se cargan más rápido ya que entregan contenido estático que libera al navegador de tener que ejecutar JavaScript costoso.

Es especialmente útil al cargar páginas que están detrás de la autenticación; en una página renderizada del lado del cliente (CSR), necesitaríamos mostrar un estado de carga mientras verificamos si el usuario ha iniciado sesión, mientras que una página SSR puede realizar la verificación en el servidor y enviar de vuelta el contenido estático correcto. Sin embargo, descubrí que esta compensación es un argumento poco convincente para usar un marco de renderizado en lugar de una aplicación CSR React.

En cualquier caso, mi SPA construido sobre React + Vite.js me dio una puntuación Lighthouse perfecta para la página de destino. Las páginas que obtienen datos detrás de la autenticación dieron como resultado puntuaciones de Core Web Vitals casi perfectas.

Para qué proyectos Gatsby sigue siendo bueno

Gatsby y los marcos de renderizado son excelentes para crear páginas mediante programación a partir de datos y, específicamente, para blogs, comercio electrónico y documentación.

Sin embargo, no se decepcione si no es la herramienta adecuada para cada caso de uso, ya que eso es como culpar a un destornillador por no ser un buen martillo. Todavía tiene buenos usos, aunque menos de los que podría debido a todas las razones que comentamos antes.

Pero Gatsby sigue siendo una herramienta útil. Si eres desarrollador de Gatsby, la razón principal por la que lo utilizarías es porque conoces a Gatsby. No utilizarlo podría considerarse un coste de oportunidad en términos económicos:

“El costo de oportunidad es el valor de la siguiente mejor alternativa cuando se toma una decisión; es lo que se renuncia”.

Imagine a un estudiante que dedica una hora y 30 dólares a asistir a una clase de yoga la noche antes de la fecha límite. El costo de oportunidad abarca el tiempo que se podría haber dedicado a completar el proyecto y los $30 que se podrían haber utilizado para gastos futuros.

Como desarrollador de Gatsby, podría iniciar un nuevo proyecto utilizando otro marco de renderizado como Next.js. Incluso si Next.js tiene un inicio de servidor más rápido, necesitaría tener en cuenta mi curva de aprendizaje para usarlo tan eficientemente como lo hago con Gatsby. Es por eso que, para mi último proyecto, decidí evitar los marcos de renderizado por completo y usar Vite.js + React; quería evitar el costo de oportunidad que conlleva dedicar tiempo a aprender a usar un marco "desconocido".

Conclusión

Entonces, ¿Gatsby está muerto? En absoluto, o al menos no creo que Netlify lo deje desaparecer pronto. La adquisición y los cambios posteriores a Gatsby Cloud pueden haber cobrado un precio enorme en el marco central, pero Gatsby todavía respira, incluso si las lentas confirmaciones actuales enviadas al repositorio parecen apenas vivas o hibernando.

Lo más probable es que me quede con Vite.js + React para mis proyectos futuros y solo use marcos de renderizado cuando realmente los necesite. ¿Cuáles son las compensaciones? ¿Sacrificar el rendimiento insignificante de la página en favor de un DX más rápido y agradable que mantenga mi cordura? Aceptaré ese trato todos los días.

Y, por supuesto, ésta es mi experiencia como fiel partidario de Gatsby desde hace mucho tiempo. Es probable que su experiencia sea diferente, por lo que el alcance de todo lo que digo puede variar según su experiencia en el uso de Gatsby en sus propios proyectos.

Por eso me encantaría que comentaras a continuación: si lo ves diferente, ¡dímelo! ¿Su experiencia actual con Gatsby es diferente, mejor o peor que hace un año? ¿Qué es diferente para ti, en todo caso? Sería fantástico contar con otras perspectivas aquí, tal vez de alguien que haya estado involucrado en el mantenimiento del marco.

Lecturas adicionales sobre SmashingMag

• Dolores de cabeza de Gatsby y cómo curarlos: i18n (Parte 1)
• Dolores de cabeza de Gatsby y cómo curarlos: i18n (Parte 2)
• Dolores de cabeza de Gatsby: trabajar con los medios (Parte 1)
• Dolores de cabeza de Gatsby: trabajar con los medios (Parte 2)

(gg, yk)Explora más en

• javascript
• gatsby
• Marcos
• Reaccionar