Respuesta corta a la pregunta que te trae aquí: no, no tienes que reescribir nada esta semana, y sí, merece la pena entender qué cambia porque htmx 4.0 es la primera versión pensada para que las apps hypermedia duren «100 años», en palabras del propio equipo. La versión 4.0.0 salió el 28 de agosto de 2026, cerrando 8 meses de trabajo (y un lanzamiento paralelo en cartucho de Game Boy, que ya es otra historia), y su discusión en Hacker News superó los 700 puntos. En esta guía traducimos los cambios técnicos a decisiones de negocio: cuándo migrar proyectos de clientes, cómo presupuestarlo y cómo vender el enfoque hypermedia sin que te miren raro.
Qué es htmx en 60 segundos (la versión para explicárselo a un cliente)
Resumen clave: Si tu código escucha eventos de htmx, este es el segundo punto a revisar en una migración. 3. Menos superficie, menos horas de mantenimiento. ¿Se romperán mis proyectos en 2.x? ¿Cuánto se cobra una migración de htmx 2 a 4?
Htmx es una librería JavaScript pequeña que te permite acceder a cosas modernas del navegador, AJAX, CSS Transitions, WebSockets, Server-Sent Events, directamente desde atributos HTML, sin escribir apenas JavaScript. En lugar de construir una API JSON y una aplicación frontend separada que la consume, tu servidor devuelve fragmentos de HTML y htmx los coloca en la página.
La frase que funciona con clientes: «tu web funciona sin dejar toda la lógica en el navegador, así que carga rápido, no se rompe con cada actualización del navegador y cualquier desarrollador que sepa HTML puede mantenerla». Dicho de otro modo: menos piezas móviles, menos mantenimiento, presupuesto más predecible. Para un freelance, «menos piezas móviles» se traduce en proyectos que puedes mantener tú solo durante años sin quedar casado con un ecosistema de herramientas.
Los cuatro cambios reales de la versión 4.0
La propia nota de lanzamiento lo aclara desde el principio: desde el punto de vista del usuario, htmx 4 es casi idéntico a htmx 2. Los cambios de fondo son pocos pero con consecuencias prácticas.
1. La herencia de atributos pasa a ser explícita
Es el cambio grande y la mayor carga de migración. En htmx 2, muchos atributos se «heredaban» por defecto: ponías una confirmación en un contenedor y los botones hijos la aplicaban. La herencia implícita, heredada de la época de intercooler.js, era potente pero difícil de razonar (funcionaba «como CSS», con los mismos problemas de sorpresa que tiene CSS). En htmx 4 los atributos no se heredan salvo que lo pidas expresamente con el sufijo :inherited:
Antes: <div hx-confirm="¿Seguro?"><button hx-delete="/item/1">Borrar</button></div>
Ahora: <div hx-confirm:inherited="¿Seguro?"><button hx-delete="/item/1">Borrar</button></div>
Para tus proyectos esto es una mejora silenciosa de mantenibilidad: el comportamiento visible está donde está escrito, no tres niveles arriba. Y desaparecen atributos de compensación como hx-disinherit, que ya no hacen falta.
2. Eventos renombrados con un formato estándar
Los eventos de htmx 2 habían crecido orgánicamente durante años y saber cuál se disparaba en cada momento era más arqueología que documentación. En la versión 4 todos siguen el patrón htmx:fase:accion (por ejemplo, htmx:beforeRequest pasa a ser htmx:before:request). Si tu código escucha eventos de htmx, este es el segundo punto a revisar en una migración.
3. Historial sin localStorage
El soporte de historial de htmx 4 deja de usar localStorage por defecto. El equipo lo identifica como causa de «muchos dolores de soporte» históricos. La mayoría de usuarios no notará nada; los que sí lo notarán son los que depuraban errores raros de estado restaurado, que simplemente desaparecen.
4. Internamente, fetch() en lugar de XMLHttpRequest
El motor pasa de XMLHttpRequest a la API fetch moderna. Para el día a día es transparente, pero es el cambio que habilita el futuro de la librería: streaming de HTML más natural, mejor integración con lo que viene. También explica el número de versión: hubo una reescritura interna (el autor la prototipó en una librería mínima llamada fixi) y luego un camino de vuelta hacia la compatibilidad con 2.x, hasta el punto de que las diferencias de comportamiento finales son pequeñas y deliberadas.
Un detalle logístico importante: htmx 4.0 no es todavía la versión «latest» en npm. El equipo la publica como «next» y mantendrá 2.x como «latest» hasta algún punto de principios de 2027, para no forzar la actualización a quien usa URLs de CDN sin versión. Si hoy enlazas htmx por CDN sin fijar versión, seguirás recibiendo 2.x. Las webs que construyes ahora no se romperán solas: esa decisión es una lección de respeto al usuario que dice mucho del proyecto.
¿Tienes que migrar ya? La decisión por casos
Como el propio anuncio no fuerza a nadie, la respuesta depende del estado de cada proyecto:
- Proyecto nuevo que arrancas este mes: arráncalo ya en 4.0 si dominas el flujo. Empiezas con la semántica definitiva y evitas tocarlo en 2027.
- Proyecto en mantenimiento con mucho uso de herencia implícita: espera a tener un hueco planificado. La migración es mecánica (hay herramienta de línea de comandos para localizar los atributos que necesitas marcar como
:inherited), pero revisar y testear una base de código heredada se cobra por horas. - Proyecto estable en 2.x sin eventos custom ni herencia rara: no lo toques. La promesa de compatibilidad del ecosistema es razonable y «si funciona, funciona» también es una decisión técnica válida.
- Cliente con tests automatizados: migración ideal: actualizas, corres los tests, arreglas los eventos renombrados que fallen y entregas con nota de versión. Medio día de trabajo bien facturado.
La regla general que aplicamos: migra cuando haya una razón (nueva funcionalidad, entrada de otro desarrollador, auditoría de dependencias), no cuando salga un número. Y documenta siempre en qué versión quedó cada cliente; dentro de dos años te lo agradecerá tu yo del futuro.
El argumento comercial: vender webs que no caducan
Aquí está el motivo por el que una release de una librería de 14 KB puede importarte como negocio. El equipo de htmx habla de «100-year web services»: aplicaciones construidas sobre HTML estándar que seguirán funcionando cuando los frameworks de hoy sean historia. Como freelance, ese argumento se traduce a tres frases de venta:
Mantenimiento más barato para el cliente
Una interfaz htmx tiene una fracción de las dependencias de una SPA típica: no hay cadena de build que envejece, no hay actualización mayor de framework cada año, no hay estado en el cliente que se corrompe. Menos superficie, menos horas de mantenimiento. Y las horas de mantenimiento suelen ser las peor pagadas y las más difíciles de vender; reducirlas mejora la rentabilidad de ambos lados.
Entregas más rápidas con el mismo precio
Sin API separada, sin aplicación cliente separada, sin gestión de estado: el CRUD que en React te ocupa dos semanas puede ocupar días con HTML servido. Mismo valor para el cliente, menos coste para ti, margen mayor. En proyectos de pyme (la inmensa mayoría del mercado freelance) la velocidad de entrega es la ventaja competitiva número uno.
Un nicho con poca competencia
Según los datos de SeniorStack, en el segmento frontend remoto en España hay 103 ofertas activas (a 27 de agosto de 2026) y las skills dominantes son React (59,2%), TypeScript (51,5%) y JavaScript (35%). En toda nuestra base de 14.275 ofertas analizadas, htmx aparece mencionada en una sola. Léelo dos veces: todo el mundo compite por las mismas posiciones React/TypeScript, y casi nadie ofrece interfaces hypermedia. Cuando un cliente quiere «una web sencilla que funcione y no me calle a palos cada año», quien sabe de htmx no tiene cola de competencia detrás.
Ojo: esto no significa que htmx sustituya a React en todo. Significa que tener ambos en tu repertorio te deja elegir la herramienta según el proyecto, y cobrar por el criterio, no solo por las teclas.
Cómo queda tu tarifa y tu propuesta
Un patrón que funciona al presupuestar proyectos hypermedia: cobra por resultado, no por tecnología. El cliente no compra «htmx»; compra «web administrable entregada en 3 semanas con mantenimiento estimado de 4 horas/mes». Si tu stack te permite cumplir eso con la mitad de horas internas, la diferencia es tuya. Con day rates de frontend en España moviéndose en bandas de 300-450 € según seniority y especialidad, la eficiencia del stack es literalmente tu multiplicador de margen.
Y para el mantenimiento recurrente, htmx juega a tu favor: menos actualizaciones de seguridad de dependencias, menos breaking changes, menos sorpresas. Puedes vender cuotas de mantenimiento más bajas manteniendo el mismo margen por hora real trabajada, que es exactamente el tipo de propuesta que renueva año tras año.
Migración de un proyecto cliente, paso a paso
Cuando llegue el momento, este es el procedimiento que recomendamos:
- Inventario de atributos heredados: ejecuta la herramienta de línea de comandos que publica el propio htmx para localizar todos los puntos donde la herencia implícita está en juego. Su salida es tu lista de trabajo.
- Fija la versión actual en los enlaces CDN del proyecto (debería estar ya, pero verifícalo): la migración a 4.0 es deliberada, nunca algo que llegue por sorpresa de CDN.
- Actualiza a 4.0 desde npm (o CDN fijado a la 4.0.x concreta) en una rama.
- Añade
:inheriteddonde el inventario del paso 1 lo indique y elimina loshx-disinheritsobrantes. - Renombra los eventos escuchados al nuevo formato
fase:accion. Busca en el proyecto las cadenashtmx:before,htmx:afteryhtmx:onpara no dejarte ninguno. - Prueba el flujo de historial (navegación adelante/atrás, recargas) porque el cambio de localStorage afecta exactamente ahí.
- Regresión visual y funcional con la checklist del proyecto, y despliegue con nota de versión para el cliente.
En proyectos de tamaño pyme, el rango realista está entre 2 y 8 horas si el paso 1 no escupe cientos de casos. Presupéstalo como trabajo de mantenimiento evolutivo, con precio cerrado una vez hecho el inventario.
Errores comunes al proponer htmx (y cómo evitarlos)
Error 1: venderlo como «el anti-React»
Los clientes no quieren guerras de stacks, quieren resultados. Presenta htmx por sus efectos (velocidad, estabilidad, coste), no por lo que no es. La discusión religiosa sobre frameworks es un tema de foros, no de propuestas.
Error 2: usarlo donde no encaja
Una aplicación con edición offline compleja, gráficos interactivos pesados o estado de cliente muy rico seguirá siendo más natural en un enfoque SPA. Saber decir «este proyecto pide React» también es parte del criterio por el que te pagan.
Error 3: migrar gratis
La migración a 4.0 es trabajo técnico con riesgo y debe facturarse. Cuando el cliente pregunta «¿esto me afecta?», la respuesta honesta es: «se puede quedar como está indefinidamente; si quieres migrar, son X horas con estos beneficios». Deja la decisión en su lado de la mesa con datos en el tuyo.
Error 4: no fijar versiones en el CDN
Htmx mantiene 2.x como «latest» precisamente para proteger a quien no fija versiones, pero tu contrato con la calidad de tus entregables no debería depender de esa cortesía. Fija siempre versión concreta en cada entrega: es una línea de código y te ahorra una clase de incidencias entera.
Preguntas frecuentes (FAQ)
¿Htmx 4.0 es gratis y de código abierto?
Sí, con licencia BSD de código abierto, como toda la historia del proyecto. No hay planes de pago ni telemetría. El «lanzamiento en Game Boy» de julio de 2026 fue una broma de marketing con cartucho incluido, no un cambio de modelo de negocio.
¿Se romperán mis proyectos en 2.x?
No. La versión 2.x sigue publicada, mantenida y siendo la «latest» en npm hasta principios de 2027. Nada fuerza la actualización; incluso el sitio oficial de la versión 4 referencia la nueva línea sin deprecar la anterior.
¿Cuánto se cobra una migración de htmx 2 a 4?
Depende del tamaño del proyecto y del uso de herencia implícita y eventos custom. En proyectos pyme típicos, entre 2 y 8 horas una vez hecho el inventario con la herramienta oficial. Nuestra recomendación: precio cerrado tras el inventario, facturado como mantenimiento evolutivo.
¿Aprender htmx me sirve si el mercado pide React?
Las dos cosas: React aparece en el 59,2% de las 103 ofertas activas de frontend remoto en España según los datos de SeniorStack, así que ignorarla no es opción. Pero htmx te diferencia justamente donde no hay cola: 1 mención en 14.275 ofertas analizadas significa que casi ningún competidor lo ofrece. Tu posición ideal: dominar la demanda (React/TypeScript) y monopolizar un nicho.
¿Funciona htmx con mi backend?
Sí. Htmx solo necesita que el servidor devuelva HTML: da igual Django, Rails, Laravel, Spring, Astro, PHP puro o lo que ya uses. Esa neutralidad es precisamente una de sus ventajas para freelances que heredan proyectos de todos los sabores.
¿Dónde sigo el desarrollo de la versión 4?
El anuncio oficial y la documentación completa están en el sitio de la versión 4 del proyecto (four.htmx.org), que además publica versiones de la documentación pensadas para modelos de lenguaje, útil si quieres que tu asistente de código domine la sintaxis nueva.
Resumen para tu próxima propuesta
Htmx 4.0 no es una revolución: es una consolidación. Herencia explícita, eventos predecibles, sin localStorage, fetch por debajo y sin prisa en npm. Para tu cartera de clientes pymes, el mensaje es estable: interfaces rápidas de entregar, baratas de mantener y que no caducan con la moda del año que viene. En un mercado donde el 59,2% de las ofertas frontend remotas piden lo mismo que pide todo el mundo, saber entregar lo mismo de otra forma, más rápido y con menos mantenimiento, es una ventaja que se nota en el margen. La versión 4.0 acaba de hacer esa ventaja un poco más sólida.
¿Te está sirviendo SeniorStack? Añádenos a tus fuentes preferidas en Google y nos verás destacados en tus resultados y respuestas de IA.