Eliminar React.js de la base de código y adaptar Htmx para la interactividad de la UI (2023)

Artículo original ↗ Discusión en Hacker News ↗

Sustituir SPAs al estilo React por HTMX y HTML renderizado en el servidor se presenta como una opción convincente para foros y sitios con mucho CRUD, donde la mayoría de las interacciones son simples y el tamaño de la carga y el tiempo hasta la interactividad importan más que un estado rico del lado del cliente. Los defensores destacan stacks más sencillos, mejor caché y cargas iniciales más rápidas, mientras que los críticos sostienen que HTMX escala mal para UIs complejas y muy interactivas, conduce a un “spaghetti” de atributos y repite problemas antiguos de la era de AngularJS. Muchos concluyen que HTMX funciona bien cuando el estado del lado del cliente es mínimo y las páginas son en gran medida documentales, pero los frameworks de estilo React/Vue siguen siendo más adecuados para interfaces sofisticadas de tipo app.

Alcance de HTMX frente a frameworks React/SPA

  • Muchos ven HTMX como ideal para aplicaciones renderizadas en el servidor, con mucho contenido o de estilo CRUD (foros, UIs de administración, formularios, filtros, paginación).
  • Otros sostienen que los frameworks de estilo React/Vue/Solid son mejores para UIs complejas, muy interactivas y con estado (chat, notificaciones, editores, reproductores multimedia, DAWs).
  • Debate sobre si el frontend moderno se ha “estabilizado” en JSX; algunos dicen que sí (dominio de React/Solid), otros señalan frameworks importantes que no usan JSX por defecto.

Rendimiento, tráfico y caché

  • Comentarios a favor de HTMX: se envía menos JS, primer render más rápido, caché más simple de fragmentos HTML, mejor para dispositivos de gama baja y páginas de aterrizaje con mucho tráfico.
  • Los críticos afirman que React con SSR/hidratación y CDNs puede ser eficiente; la generación pesada de fragmentos HTML a escala (>10k req/s) puede resultar costosa para HTMX.
  • Un practicante encontró HTMX lento al devolver respuestas HTML grandes para filtros complejos; cambiar a Alpine + parciales redujo la carga útil y se sintió más rápido.

Gestión de estado y preocupaciones de “spaghetti”

  • Los detractores argumentan que los enfoques de HTMX/atributos se parecen a Angular 1.0: “codelets” dispersos, gestión de estado difícil y eventual “spaghettificación”.
  • Los defensores de HTMX responden que el estado del lado del cliente debe ser mínimo; el estado real vive en el servidor, y las actualizaciones HTML reflejan la verdad del servidor.
  • Otros informan de equipos que volvieron a React después de que HTMX se volvió difícil de gestionar, mientras que algunos dicen que los sistemas basados en HTMX siguen siendo más fáciles de mantener.

Límites de interactividad y soluciones

  • Puntos débiles citados: interacciones ricas dentro de la página (listas que se desplazan y se actualizan a mitad del scroll, preservación de la selección de texto, formularios facetados complejos).
  • Mitigaciones sugeridas: extensiones de morphing del DOM, swaps out-of-band, mezclar HTMX con pequeños componentes JS (Alpine, Web Components, Leaflet, etc.).
  • Algunos ven HTMX como incompleto para experiencias “tipo app”; otros recomiendan arquitecturas híbridas (HTMX para la mayoría de las páginas, “islas” de React/Vue para widgets pesados).

Casos de uso, herramientas y alternativas

  • Informes entusiastas de HTMX impulsando aplicaciones web completas e incluso PWA; el soporte offline requiere service workers y caché intensiva, lo que algunos consideran complicado.
  • Quejas sobre la débil composición de componentes de HTMX y la falta de herramientas tipo Storybook; se sugieren sistemas al estilo LiveView, Places.js, Pyview o frameworks SSR orientados a JS.
  • Varios subrayan que no existe una herramienta universalmente mejor; la elección correcta depende del nivel de interactividad, la complejidad del estado, la escala y las habilidades del equipo.