Decir “no usamos React” en 2026 suena a opinión contraria por deporte. No lo es. Es la conclusión de varios años entregando software para PYMES y operadores en LatAm donde HTMX cumple mejor el contrato: app funcional, mantenible por una persona, que rinde bien en el celular Android de S/300.000 que usa el cliente final.

Esto no es un manifiesto. Es lo que aprendimos.

Qué cubre HTMX

HTMX agrega 5 atributos HTML que cubren el 90% de lo que la gente usa React para hacer en una app interna:

• hx-get / hx-post para hacer requests sin recargar la página.
• hx-target para decir dónde insertar la respuesta.
• hx-swap para decir cómo reemplazar (innerHTML, outerHTML, append, etc).
• hx-trigger para reaccionar a eventos (click, change, blur, etc).
• hx-include para mandar form data extra.

El servidor manda HTML, no JSON. El cliente reemplaza pedazos del DOM con ese HTML. No hay store, no hay state, no hay rehidratación, no hay sync entre cliente y servidor.

Lo que ganas

El servidor tiene la verdad

En React + API REST, tienes lógica de negocio repartida entre cliente y servidor. Validaciones en ambos lados, format en ambos lados, sync de estado en ambos lados. El bug típico es que el cliente y el servidor discrepan, y nadie sabe quién tiene razón.

Con HTMX, el servidor renderiza el HTML, valida, formatea y manda exactamente lo que se va a mostrar. El cliente lo pinta. No hay discrepancia posible.

Bundle = HTMX (~14 KB) + tu CSS

Sin webpack, sin vite, sin esperar 30 segundos a que yarn build termine. Sin bundle splitting, sin tree shaking, sin Code Splitting con React.lazy(). El usuario descarga 14 KB de HTMX y los KB de CSS que necesites.

Para una app interna en Chile, donde mucha gente la abre en un Android de gama media en una conexión lenta, eso es la experiencia que quieres.

Los developers entregan más rápido

Esto sorprende a quien no lo ha probado. Una feature típica en React toca 4–6 archivos: el componente, el hook, el state slice, la API route, los tipos compartidos, los tests. En HTMX toca 2: el handler en Go o lo que uses, y el partial de Templ que renderiza el HTML.

Más simple = más rápido = menos bugs.

Mantención mínima

npm audit cada 2 semanas tirando warnings, breaking changes en libs cada 6 meses, deprecaciones de hooks, migraciones de Class to Functional, de Pages Router a App Router. Todo eso desaparece. HTMX 1.x es estable, no tiene roadmap de “rewrite”. Templ es un generador de strings, no tiene mucho que romper.

Lo que pierdes

Honestamente:

Interactividad pesada del lado del cliente

Si tu app tiene un editor de texto rico, un canvas de drawing, un spreadsheet con scroll virtual, drag-and-drop sofisticado, un mapa con 500 markers que se filtran en tiempo real, un dashboard con 20 charts que se actualizan en streaming…

…entonces React (o Vue, o Solid, o Svelte) es claramente la elección correcta. HTMX no compite ahí.

Animaciones complejas y transiciones de página

HTMX puede hacer transiciones simples (fade-in, swap suave). Pero si quieres rutas con animaciones tipo SPA (la página A se desliza fuera mientras entra la B), Framer Motion + React es 10x más fácil.

Optimistic UI sofisticada

Para “guarda esto, muestra como si ya estuviera guardado, si falla revierte y muestra error”, React + React Query lo resuelve elegante. HTMX lo puede hacer pero el código es más manual.

Apps offline-first

Service workers, IndexedDB, sync cuando vuelve la conexión. Acá React

• una librería como TanStack Query con persistQueryClient o similar te lleva más lejos sin reinventar.

Para quién HTMX es claramente la elección correcta

• Una PYME que necesita un panel interno multi-usuario.
• Un bot de WhatsApp con backoffice para que el equipo edite catálogos, tags, plantillas.
• Un SaaS multi-tenant donde 80% son formularios, listas, filtros y reportes.
• Un e-commerce o booking donde la magia del frontend es agendar o pagar (no entretenimiento).

Esto cubre fácil el 70% de los proyectos B2B en LatAm.

Para quién no

• Apps tipo Notion, Figma, Linear o cualquier producto donde el frontend es el producto.
• Apps de un solo cliente donde el costo de los developers no importa pero la experiencia del usuario sí.
• Equipos donde el budget está dictado por “lo que sabemos hacer”, y lo que saben hacer es React. Pelear contra eso pierde plata.

El argumento honesto

HTMX no es “mejor que React”. HTMX es mejor para un subset claro de proyectos que en LatAm es enorme: software interno y SaaS B2B donde el frontend es un medio, no el fin.

Cuando estás eligiendo stack para un proyecto que va a vivir 5 años en una PYME, la pregunta correcta no es “qué prefieren los developers”. Es “qué stack permite que un equipo chico mantenga esto durante una década sin reescribir”. Para esa pregunta, HTMX gana casi siempre.

Si tienes un proyecto donde el frontend es un medio para llegar a un backend que importa, hablemos. WhatsApp o correo.

← Volver a notas