Por qué Gumroad no eligió htmx

• Gumroad evaluó htmx para su nuevo proyecto Helper esperando un frontend ligero, pero cambió a React/Next.js a medida que crecieron las exigencias de UX compleja
• htmx parecía prometedor para interacciones simples, pero en formularios con validación dinámica y campos condicionales la lógica del lado del servidor se volvía verbosa y el flujo de desarrollo se sentía poco natural
• El drag-and-drop del constructor de flujos, la colaboración en tiempo real, la gestión compleja de estado y la generación dinámica de formularios se implementaban de forma más directa en el ecosistema de React y su modelo de componentes
• El material para resolver problemas y el soporte de herramientas de IA eran más abundantes en Next.js y React, mientras que htmx estaba en desventaja en velocidad de desarrollo por la falta de datos de entrenamiento open source
• htmx puede encajar bien en apps existentes renderizadas en servidor o en modelos de interacción simples, pero para interfaces con mucho estado como Helper, React y Next.js resultaron ser una mejor opción

---

Contexto de por qué evaluaron htmx en Helper

• Gumroad empezó a evaluar htmx como candidato de frontend al iniciar su nuevo proyecto Helper
• La expectativa inicial venía de su experiencia previa de que React era más pesado de lo necesario, y vieron en htmx una posible forma de agregar interacciones simples de manera ligera
• Dentro del equipo incluso hubo opiniones de que htmx se parecía a un meme que satiriza el ecosistema de JavaScript cada vez más complejo
  • Así como Tailwind puede parecer otra sintaxis para CSS inline, también había quienes veían htmx como algo más cercano a otra sintaxis para JavaScript inline
• Tailwind sí encontró su lugar dentro del stack de herramientas de Gumroad, pero htmx no escaló de forma adecuada para el propósito de Helper ni llevó a la mejor experiencia de usuario para sus clientes

Dónde React/Next.js se sintió más natural

• Experiencia de desarrollo y manejo de formularios

  • Aunque una implementación correcta también era posible con htmx, en Gumroad sintieron que el proceso para hacer funcionar las cosas en Next.js era más intuitivo
  • En formularios complejos con validación dinámica y campos condicionales, el trabajo del lado del cliente en React era más simple, mientras que en htmx la lógica del lado del servidor se alargaba

• Limitaciones de UX e interacción

  • htmx tiende a empujar las apps hacia un enfoque tipo Rails/CRUD, por lo que la experiencia base podía volverse fácilmente común o genérica
  • La interfaz de drag-and-drop del constructor de flujos requería implementaciones de rodeo en htmx y se sentía más tosca que la experiencia fluida obtenida con librerías de React

• Herramientas de IA y velocidad para resolver problemas

  • Las herramientas de IA estaban más familiarizadas con Next.js que con htmx, y una de las razones señaladas fue la falta de datos de entrenamiento open source
  • Había mucha más documentación y recursos del lado de React/Next.js, así que cuando surgían problemas era más rápido encontrar soluciones

• Complejidad y escalabilidad

  • A medida que el proyecto se volvía más complejo, la simplicidad de htmx empezaba a sentirse más como una limitación que como una ventaja
  • Al agregar colaboración en tiempo real y visualización compleja de datos, en el enfoque centrado en servidor de htmx se volvió cada vez más difícil manejar el estado entre múltiples componentes

Diferencias evidentes según las funciones de Helper

• Drag-and-drop: react-beautiful-dnd del ecosistema de React ofrecía drag-and-drop fluido y accesible con poca configuración
• Gestión compleja de estado: para reflejar en tiempo real en la UI la configuración de cada etapa del flujo y la lógica condicional, los enfoques de manejo de estado de React como useState o Redux resultaban más directos
• Generación dinámica de formularios: crear formularios de configuración distintos según el tipo de etapa y modificarlos según la entrada del usuario se resolvía de forma más intuitiva con el modelo de componentes de React
• Colaboración en tiempo real: la función para que varios usuarios editen simultáneamente un flujo se implementó de forma relativamente directa con WebSockets y React, mientras que en htmx requería lógica de servidor más compleja y JavaScript personalizado
• Optimización de rendimiento: a medida que los flujos crecían en tamaño y complejidad, React permitía optimizar el renderizado con más detalle mediante el virtual DOM y hooks como useMemo y useCallback

Ecosistema y conclusión final

• El ecosistema de React/Next.js es grande y maduro, y ofrecía soluciones para casi todos los problemas con los que se encontró Gumroad
• Con htmx era frecuente terminar cediendo en funcionalidades o rehaciéndolas por cuenta propia, y también había casos en que servicios y librerías de terceros tenían bindings para React pero no equivalentes para htmx
• Tras migrar a React/Next.js, Gumroad evaluó que era una elección más adecuada para construir UX compleja
  • Podían avanzar más rápido, crear una experiencia de usuario más inmersiva y aprovechar herramientas y librerías ya existentes
  • También pudieron mejorar de forma importante la experiencia de uso de la app para los clientes principales de Helper
• Las limitaciones de htmx no eran imposibles de superar, pero el proceso de resolverlas terminaba alejándose de las fortalezas de htmx y moviéndose hacia soluciones más naturales en un entorno centrado en JavaScript
• htmx puede ser una buena opción para proyectos construidos sobre apps existentes renderizadas en servidor o con modelos de interacción simples
• En interfaces complejas y con mucho estado como Helper, React y Next.js resultaron más adecuados, y Gumroad considera que puede seguir reevaluando su stack según cambien las necesidades y aparezcan nuevas tecnologías

[GN⁺]

Opiniones en Hacker News

• Esto es algo que había dejado en otro hilo: el CEO de Gumroad dijo en Twitter que había probado htmx en un proyecto, pero que al final eligieron NextJS.
  Como estaba buscando relatos negativos y bien pensados que valiera la pena publicar en el sitio de htmx, le pregunté si podía escribir sobre su experiencia, y agradecí que aceptara con gusto.

  • La actitud de exponer directamente los puntos donde htmx puede no ser siempre la mejor opción hace que respete más el proyecto.
    Es refrescante comparado con otros proyectos que afirman ser la mejor solución para todo.
    Me interesa especialmente la observación sobre arrastrar y soltar: me pregunto si realmente lo ven como algo difícil en htmx y, si es así, si hay planes para resolverlo.
  • El CEO de Gumroad también dijo que Rails en sí mismo era deuda técnica, y cuando le preguntaron por qué, solo respondió que React era mucho mejor.
    Lo dijo como si Rails y React no pudieran usarse juntos.
    El artículo en sí no me parece tanto una experiencia negativa con htmx, sino que, en cuanto aparecen arrastrar y soltar y colaboración en tiempo real, quizá la decisión de experimentar con htmx ya estaba mal desde el principio.
    Tampoco entiendo muy bien qué se supone que muestran las capturas de pantalla, pero aun así creo que es un buen texto para publicar en el sitio de htmx.
  • Es respetable mostrar en qué puntos htmx puede ser menos adecuado que otras herramientas.
    Para mí, htmx se parece más a un reemplazo de jQuery que a un reemplazo de React.
    htmx y jQuery agregan interacción a un documento; React intenta convertirse en todo el documento.
    La herramienta debería cambiar según el trabajo.
  • Después de ver el artículo enlazado y https://htmx.org/essays/htmx-sucks/, decidí no usar htmx ni recomendárselo a otros.
  • El otro hilo es https://news.ycombinator.com/item?id=41727315.

• La parte que dice “IA y soporte de herramientas: también worth noting que las herramientas de IA están muy familiarizadas con Next.js, pero no tanto con htmx” está escrita tranquilamente como si fuera una desventaja, pero es una señal bastante escalofriante para el futuro de las herramientas de desarrollo, bibliotecas, frameworks y lenguajes.
  Mi predicción es que los modelos de lenguaje grandes van a reforzar aún más los efectos de “el ganador se lo lleva todo” y de ventaja por llegar primero, y también fomentarán más el uso de herramientas open source gracias a una mayor cantidad y calidad de datos de entrenamiento.

  • El problema de la IA y el soporte de herramientas es, en realidad, una extensión del problema de la comunidad y el ecosistema.
    Incluso antes de los modelos de lenguaje grandes, React ya tenía la ventaja de que la mayoría de las preguntas estaban respondidas en StackOverflow y de que había bibliotecas maduras para casi cualquier uso.
    Ahora simplemente hay gente que le hace a un modelo de lenguaje grande las preguntas que antes habría hecho en StackOverflow, y el resultado es el mismo.
    Usar lo que mucha otra gente usa trae ventajas.
  • Que los modelos de lenguaje grandes aumenten los efectos de “el ganador se lo lleva todo” y de ventaja por llegar primero en herramientas de desarrollo probablemente sea cierto para quienes dependen de ellos para programar.
    Pero, como estrategia de largo plazo para una carrera en ingeniería de software, creo firmemente que no es una buena apuesta.
  • Las herramientas de IA están atrapadas en un punto específico del tiempo, y aunque se las entrene con material nuevo, la cantidad de información que pueden aprender tiene límites.
    He pensado que quizá esto podría ser algo bueno.
    La industria del software pasa demasiado tiempo persiguiendo las herramientas, funciones de lenguaje y frameworks más recientes.
    Tal vez un poco de estancamiento sea positivo si nos lleva a terminar el trabajo con las herramientas que ya tenemos, en vez de inventar un martillo nuevo cada seis meses.
  • Si un desarrollador no puede trabajar sin algo que escriba su código por él, no entiendo para qué lo contratarían en primer lugar.
  • No me preocupa demasiado este punto, y es posible que la preocupación de Gumroad esté exagerada.
    Solo por el comentario no se puede saber si de verdad tuvieron la experiencia de que la IA manejara mal HTMX, o si estaban pasando a hablar de la falta de otros materiales.
    Los modelos de lenguaje grandes a menudo funcionan muy bien como traductores de propósito general.
    Si aprenden patrones y conceptos generales de frameworks populares y conocen hasta cierto punto la sintaxis de un framework más pequeño, por experiencia también pueden generar código bastante bueno para frameworks de nicho.
    Es parecido a cómo los piratas pueden hablar con acento pirata sobre temas que nunca se mencionaron en los datos de entrenamiento.

• La parte que dice “al crear formularios complejos con validación dinámica y campos condicionales, terminamos escribiendo lógica compleja del lado del servidor para manejar cosas que en React serían tareas simples del lado del cliente” me recuerda al meme de Anakin y Padme.
  “Pero igual van a implementar validación del lado del servidor, ¿verdad… verdad?”

  • Si un formulario web es más complejo que un formulario en papel, quizá habría que replantearse el propio formulario web.
    No se me ocurren muchos formularios que sean fáciles en React pero difíciles en htmx, salvo casos en los que quieres meter estado global de aplicación al estilo React y resolver el 90% con una biblioteca.
  • También se valida en el servidor.
    Solo que se hace una vez al enviar, no en cada página.

• A diferencia de la frase “pensé que htmx podía ser una buena solución para mantener el frontend muy liviano”, parece que htmx dejó de encajar en cuanto abandonaron el frontend liviano.
  Empezaron a usar bibliotecas de terceros para renderizar UI/UX compleja y gestión de estado.
  Además, decir “en React era más fácil hacer X” no es una comparación justa si lo hicieron con una biblioteca de terceros.
  Simplemente no tuvieron que hacerlo ustedes mismos porque alguien más lo hizo por ustedes.
  Estoy de acuerdo con mucho de lo que dice el artículo, pero si ya sabían que necesitaban estado y renderizado complejos, creo que htmx no era una buena solución desde el principio.

  • Creo que es exactamente así.
    Me gusta htmx, pero este artículo muestra que el autor tenía una comprensión técnica bastante limitada.
    No parecen ser ventajas y desventajas que se descubren con saber un poco de la plataforma web y leer la documentación de htmx.org, sino más bien ganas de probar HTMX por la onda del momento.
  • Hace un buen paralelo con la gente que nunca debería haber usado React desde el principio y escribe artículos del tipo “cambiamos nuestra app de React a htmx y todo mejoró muchísimo”.
  • La oposición htmx vs JavaScript me recuerda a las pruebas de desarrollo guiado por comportamiento de behave frente a las pruebas con pytest.
    El lenguaje Gherkin se ve bien en casos simples y, en principio, puede escalar también a casos complejos, pero cuanto más tienes que gestionar varias capas de abstracción, más cómodo se vuelve pytest, que es Python puro.
  • Pensé exactamente lo mismo.
    El alcance del proyecto no era para nada “simple”, y en mi caso habría ido directo con React.
  • Solo con ver la descripción de las funciones deseadas, parecía inevitable que hiciera falta JavaScript pesado.

• Sobre la parte que dice que “implementar una interfaz de arrastrar y soltar para el constructor de flujos de trabajo fue un gran desafío en htmx, y requirió rodeos torpes en comparación con la experiencia fluida que se puede obtener con una biblioteca de React”, HTMX funciona mejor cuando hace solo lo necesario para requerir un bundle de frontend, y nada más
  Basta con conectarse al evento htmx.onLoad y luego buscar y enlazar, dentro del contenido cargado, el markup con atributos, por ejemplo columns, cards, tasks, etc.
  Por ejemplo, se puede vincular sortable.js al markup renderizado y conectar los eventos de sortable con actualizaciones de estado mediante HTMX
  Es bastante simple, y la documentación tiene exactamente un ejemplo de esto: https://htmx.org/docs/#3rd-party

  • Estoy usando HTMX junto con componentes de UIKit
    Los sitios web modernos, con estado y dinámicos no son en absoluto incompatibles con HTMX

• Al leer el artículo, parece que el equipo está más acostumbrado al desarrollo frontend que al desarrollo backend
  Desde la perspectiva de un desarrollador de la vieja escuela, a veces se ve un poco de temor y malentendidos en la forma de pensar de los desarrolladores frontend
  Sinceramente, creo que para entender cómo funciona este enfoque solo hace falta ajustar un poco la forma de pensar, pero también entiendo que mucha gente nunca ha visto un enfoque cliente/servidor tradicional en toda su carrera
  Aun así, no se puede ignorar el valor de los componentes React ya hechos ni la ventaja de que sea fácil encontrar documentación y ayuda

  • Creo que no solo los desarrolladores, sino también que los diseñadores UX piensen al estilo React es una de las mayores barreras para adoptar htmx
    Una generación de diseñadores ha diseñado mobile y web como si fueran muy parecidos, y les ha pasado la complejidad de implementación a los desarrolladores
    Pero la web, en la medida de lo posible, debería ser distinta de mobile, y está bien que lo sea
    En el artículo dicen que el diseño era demasiado “generic”, como una app CRUD, pero ¿eso realmente es malo?
    Tenemos el gran logro de un modelo de documentos adoptado de forma universal, que permite crear experiencias de usuario predecibles en todos los sitios, pero lo vemos solo como “aburrido”
    Tratamos el aburrimiento como si fuera algo inherentemente problemático
    Entiendo la presión del mercado que exige experiencias únicas y con marca que se sientan como apps móviles, pero me hace imaginar cómo sería si los diseñadores pudieran pensar también al estilo WWW, tanto como piensan al estilo React

• Me gusta que HTMX publique en su sitio este tipo de artículos y otros parecidos
  Parece que había bastantes razones válidas por las que HTMX por sí solo no encajaba bien
  No soy especialista en frontend, pero tengo algunas ideas
  Primero, ¿no hay que hacer validación de formularios también en el backend de todos modos?
  Me pregunto por qué fue tan difícil que el sistema backend le comunicara los resultados al frontend
  En muchos casos hay muy buenas razones para validar formularios tanto en el frontend como en el backend, así que en esos casos HTMX por sí solo no alcanzaría, pero la forma en que se plantea este problema resulta un poco confusa
  Segundo, si se usa solo HTMX, la app puede verse empujada en cierta medida en esta dirección, y en algunos casos eso es bueno, pero parece que ellos concluyeron que para sus clientes necesitaban otro enfoque
  Tercero, me gustaría saber más sobre cómo este equipo estaba usando herramientas de IA para que depender de ellas se volviera un problema principal
  Si en el futuro las herramientas de desarrollo con IA se vuelven importantes, también es una pregunta interesante si el estándar para que un framework o lenguaje de programación nuevo consiga suficientes herramientas e integraciones como para ser adoptado será demasiado alto
  Cuarto, como suele pasar con las quejas sobre HTMX, algunos proyectos exigen más de lo que HTMX ofrece
  Quinto, una de las razones por las que me gustan Django y Python también es la profundidad de su comunidad, integraciones y ecosistema de add-ons
  Algo como https://unpoly.com/, que tiene un concepto parecido pero más funcionalidades que HTMX, tal vez les habría encajado mejor

• Sobre la frase “el proceso de desarrollo de Next.js se sintió natural”, no sé qué parte de esta sintaxis de ReactJS es natural
  Puede ser familiar, pero no es natural
  useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

  • Hasta donde sé, HTMX no tiene una solución elegante para timers e intervalos
    Al final habría que conectarlo de forma incómoda con JavaScript
  • Este ejemplo de código es bastante generoso
    Si quieres un hook personalizado con timeout variable, puede volverse mucho más complejo
    Dan también tuvo que escribir un artículo largo sobre este tema: https://overreacted.io/making-setinterval-declarative-with-r...
  • Me da curiosidad cómo se vería un código natural para este caso de uso
    ¿Puedes escribirlo?

• Es digno de elogio que htmx.org haya alojado este artículo

  • Creo que es realmente valioso cuando un servicio o herramienta explica no solo por qué usarlo, sino también por qué no usarlo
  • Publicar este artículo fue una actitud realmente humilde y honesta
    Al final, si alguien toma htmx y se enoja porque no satisface sus necesidades, ahora también hay un recurso al que se lo puede remitir
  • Está enlazado bajo “On The Other Hand…” en https://htmx.org/essays/
  • Al principio esperaba algo parecido a un rant o a un texto sarcástico, pero en realidad fue un buen artículo con buenos puntos, y me dio gusto
    Uso htmx en algunos de mis proyectos y me ha ido bastante bien
    Este tipo de artículos, al mostrar de forma poco común dónde htmx funciona bien y dónde se queda corto, en realidad me da más confianza para usar htmx

• El tercer punto se siente aterrador
  Me hace imaginar un mundo en el que las empresas pagan para que su framework esté sobrerrepresentado en los conjuntos de entrenamiento de los modelos, y luego venden contratos con base en eso
  Es parecido a tener la optimización para motores de búsqueda baked in dentro de las herramientas de desarrollo