La fatiga de gestionar dependencias: por qué dejé React y elegí Go+HTMX+Templ

• Este año, después de avanzar en proyectos personales usando Go, HTMX y Templ, decidí dejar de usar React
  • En el sitio oficial de HTMX se pueden encontrar varios argumentos convincentes para dejar React y elegir HTMX, pero siento que no mucha gente habla de la fatiga de gestionar dependencias
• ¿Qué es la "fatiga de gestionar dependencias"?
  • En mi último proyecto personal con React (un diccionario interactivo de catalán), me di cuenta de que estaba gastando demasiado tiempo principalmente en actualizar dependencias de paquetes de React
  • Al actualizar paquetes a sus versiones más recientes, aparecían cambios importantes en las API y tenía que invertir tiempo en refactorizar el código
  • Como la web app estaba desplegada como servicio público en una instancia de EC2, quería mantener las dependencias actualizadas
• ¿De verdad hacen falta nuevos lanzamientos de versiones mayores?
  • Paquetes como wouter (un paquete de enrutamiento para React) y TanStackQuery (usado para obtener datos del backend, almacenarlos en caché y gestionar el estado) rompieron gravemente la web app debido a actualizaciones de versiones mayores.
  • Cuando la primera actualización de versión mayor rompió la aplicación, refactoricé el código sin cuestionarlo, pero cuando pasó por segunda vez, empecé a dudar.
  • Me pregunté qué beneficio real estaba obteniendo la web app de los lanzamientos de versiones mayores, aparte de los parches de seguridad.
  • También me pregunté si realmente era necesario romper cinco veces la API de componentes clave.
  • Pensé en cuánto tiempo estaba perdiendo que podría usar para lanzar nuevas funciones u otros productos.
• El problema de la falta de tiempo
  • Como no tengo mucho tiempo para dedicar a proyectos personales de programación, no quiero desperdiciarlo refactorizando código después de actualizaciones mayores de dependencias.
  • Si estuviera construyendo productos para clientes y pensara cobrar por el trabajo de mantenimiento futuro, entonces usar muchas dependencias inestables podría estar bien.
  • Pero si quiero crear productos que requieran el menor mantenimiento posible, me mantendría lejos del ecosistema de JS.
• Uso de Go+HTMX+Templ
  • La razón principal por la que uso Go+HTMX+Templ en proyectos personales es que los proyectos en Go me permiten concentrarme en lanzar funcionalidades sin dejar de atender las actualizaciones habituales de dependencias y seguridad.
  • El propio lenguaje Go mantiene una biblioteca estándar estable y una especificación del lenguaje estable.

[bbulbum]

Parece que HTMX está recibiendo comentarios bastante positivos.
Da la impresión de que muchos lo están buscando como complemento para aplicaciones basadas en SSR.
Creo que debería probarlo alguna vez en un proyecto paralelo.

[savvykang]

No elegí las librerías de TanStack porque son más complejas de lo necesario y, además, en los últimos años la calidad de la documentación ha bajado. Y también me hace pensar si de verdad hace falta insistir siempre en usar la versión más reciente, porque el ciclo de reemplazo de los paquetes de npm es demasiado corto.

Eso sí, cuando trabajo en la empresa no creo que pueda dejar React. En un proyecto personal da igual lo que uses.

[dohyun682]

¿No hay realmente grandes problemas de dependencias mientras no hagas actualizaciones de versión mayor...?

[aer0700]

Hace poco vi una de las tareas programadas internas que corría en Python 2, y casi me quedo sin aire.
Después de pensarlo, decidimos dejarla así por ahora porque funciona bien. Pero no podremos aguantar para siempre sin actualizarla.

[aer0700]

El cansancio de gestionar dependencias VS el fastidio de reinventar la rueda
Es un debate viejo. Claro que lo correcto es no usar una rueda innecesaria, pero que hoy no haga falta no significa que mañana tampoco la vayas a necesitar...
Nunca he usado GO, pero últimamente se ven muchos servidores hechos con GO. Aunque no lo use de inmediato, creo que debería probarlo al menos una vez.

[clickin]

Parece que HTMX está a la vanguardia de las tecnologías de moda, así que mucha gente lo está probando, pero me pregunto si no sería mejor ir más bien por una dirección como go + vecty + gox.

[GN⁺]

Opiniones de Hacker News

• Comparte su experiencia desarrollando una app web con Actix, Tera y HTMX después de dejar de lado bibliotecas como React. Este stack ofrece gran mantenibilidad y ha sido bien recibido por los usuarios

  • Explica cómo desarrolló rápidamente una nueva app web y la desplegó para usuarios de prueba
  • Al no sufrir de "fatiga por la gestión de dependencias", pudo obtener una comprensión más profunda de sus herramientas

• Considera que las bibliotecas de Tanner tienen muchas funciones, pero carecen de un buen diseño de API

  • React Table y React Query son potentes, pero sus límites están mal definidos y eso causa problemas
  • La ventaja de React es que no es un framework y se detiene en límites bien diseñados
  • Intenta adoptar solo bibliotecas que cumplan con ese criterio

• Siente que los ejemplos de HTMX trasladan la complejidad a otra parte, y explica que JSX es una forma elegante de evitar las plantillas

  • Aún hay muchos problemas por resolver, como routing, manejo de estado y autenticación

• Le parece extraño decir que está dejando React, y sostiene que el problema no es React sino otras dependencias

  • La opción de escribir el backend en Go siempre estuvo disponible

• Enfatiza que no hay que olvidar que al actualizar a la siguiente versión mayor de un paquete, es normal esperar cambios

  • Usando Remix como ejemplo, explica cómo aplicar los cambios de forma gradual
  • Sostiene que los buenos paquetes requieren mucho esfuerzo

• Comparte su experiencia migrando un proyecto SPA a Django y HTMX, y explica que redujo drásticamente su dependencia de JavaScript

  • Expresa que la SPA se sentía como una bomba de tiempo

• Sostiene que React no es responsable de los paquetes de terceros mal mantenidos

  • Explica que no hacen falta herramientas de manejo de estado como routers o Redux

• Cree que la v5 de react-query debería haber sido compatible con la API de v3, pero explica que la migración es fácil y no obligatoria

  • Siente que la "fatiga por la gestión de dependencias" está exagerada y aconseja mantener una cantidad razonable de dependencias

• Cuestiona por qué hicieron el upgrade aunque la app web no obtuviera beneficios adicionales

  • Explica que no hay ventaja en actualizar a la versión más reciente

• Explica que después de dejar React y nextjs y cambiarse a otro stack, su estrés disminuyó y las actualizaciones ya no le provocan depresión