El Enfoque HTML-First: Por Qué htmx y los Frameworks Ligeros Están Revolucionando el Desarrollo Web

Dec 11, 2025 · 20 min read

Durante años, cuando se trataba de construir algo “moderno” en la web, la elección casi automática recaía en React, Angular, Vue y todo el ecosistema de las Single Page Applications (SPA). Estos frameworks se convirtieron en la opción segura, casi un estándar de facto. Pero últimamente se está produciendo un cambio significativo en el panorama del desarrollo front-end. Muchos equipos — incluidos algunos de gran tamaño y con proyectos enterprise — se están orientando hacia frameworks HTML-first como htmx y otras herramientas que adoptan un enfoque más tradicional, guiado por el servidor.

Y honestamente, tiene todo el sentido. 🎯

No todas las aplicaciones necesitan un pesado motor client-side. En muchos casos, el modelo SPA añade más complejidad que valor. Los frameworks HTML-first vuelven a poner en primer plano parte de la simplicidad y la velocidad para la que la web fue originalmente diseñada, sin renunciar a la interactividad que los usuarios esperan.

En este artículo exploraremos en profundidad las razones de esta tendencia, respaldadas por datos y estadísticas concretas.

El Problema del JavaScript Bloat: Los Números Hablan Claro 📊

Antes de analizar las ventajas del enfoque HTML-first, es fundamental comprender la magnitud del problema que estamos enfrentando.

El Crecimiento Exponencial del JavaScript

Los datos del HTTP Archive son elocuentes: la cantidad media de JavaScript transferido por página ha pasado de 90 KB en 2010 a 650 KB en 2024. Y esta tendencia no muestra signos de desaceleración.

Pero estos son solo los valores medios. Un análisis detallado de 2024 revela casos mucho más extremos:

Slack, una aplicación de chat, carga 55 MB de JavaScript — prácticamente el tamaño del Quake 1 original con todos los recursos incluidos
Jira, un software de gestión de tareas, pesa casi 50 MB
LinkedIn llega a 31 MB
Los simples botones “Like” de las redes sociales requieren típicamente 12 MB de código
Incluso Google Maps, relativamente modesto para los estándares modernos, pesa 4.5 MB

Si asumimos que una línea de código media tiene unos 65 caracteres, estamos hablando de enviar aproximadamente 150.000 líneas de código con cada sitio web, ¡a veces solo para mostrar contenido estático!

💡 ¿Lo habías pensado? Slack, una app de mensajería, requiere más espacio que un videojuego 3D completo de los años 90. Para enviar mensajes de texto.

El Impacto en el Rendimiento

JavaScript es el recurso computacionalmente más costoso que un navegador debe gestionar. Es a menudo el cuello de botella que determina si una página aparece rápida o lenta, ya que un bundle sobredimensionado puede bloquear el renderizado y degradar el rendimiento general.

Para quien utiliza un portátil de gama alta con conexión de fibra, esto podría ser solo una pequeña molestia. Pero para quien navega con un teléfono de gama baja o una conexión inestable, puede hacer la diferencia entre quedarse en el sitio o abandonarlo completamente.

Los Tamaños de los Frameworks a Comparación

Aquí hay una comparación de los tamaños de los principales frameworks JavaScript (versiones gzipped), según los datos de LogRocket y Strapi:

Framework	Tamaño Gzipped
Angular	~62.3 KB
React + ReactDOM	~44.5 KB
Vue	~34.7 KB
htmx	~14 KB

htmx pesa aproximadamente un tercio de Vue y menos de un cuarto de Angular. Y estos son solo los frameworks core — las aplicaciones reales típicamente incluyen bibliotecas para routing, state management, form handling, HTTP client y mucho más.

Construir con HTML en Lugar de Luchar con Capas de JavaScript 🛠️

Las herramientas HTML-first permiten concentrarse en la estructura y el comportamiento real de la aplicación, en lugar de tener que gestionar árboles de componentes, hydration, reducers, context providers y todo el overhead que acompaña a los frameworks SPA.

Con htmx, por ejemplo, simplemente se envía HTML desde el servidor, y la biblioteca sustituye las partes correctas en la página. Nada de carpetas con 20 archivos para un solo componente React. Nada de bibliotecas de state management client-side. Nada de over-engineering.

Es un enfoque que resulta sorprendentemente directo y lineal.

Un Ejemplo Práctico

Consideremos un simple botón que carga contenido dinámico.

Enfoque tradicional SPA (React):

// useState, useEffect, fetch API, loading state management,
// error handling, conditional rendering...
function LoadDataButton() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  const handleClick = async () => {
    setLoading(true);
    try {
      const response = await fetch('/api/data');
      const json = await response.json();
      setData(json);
    } catch (e) {
      setError(e);
    } finally {
      setLoading(false);
    }
  };

  return (
    <div>
      <button onClick={handleClick} disabled={loading}>
        {loading ? 'Loading...' : 'Load Data'}
      </button>
      {error && <div className="error">{error.message}</div>}
      {data && <DataDisplay data={data} />}
    </div>
  );
}

Enfoque HTML-first con htmx:

<button hx-get="/data"
        hx-target="#result"
        hx-indicator="#loading">
  Load Data
</button>
<span id="loading" class="htmx-indicator">Loading...</span>
<div id="result"></div>

El servidor devuelve directamente el HTML listo para visualizar. Fin de la historia.

✨ La diferencia es evidente: 30+ líneas de código React vs 5 líneas de HTML con htmx. Mismo resultado, complejidad radicalmente diferente.

El Rendimiento Mejora Casi Automáticamente ⚡

Las SPAs envían toneladas de JavaScript al navegador — y el navegador paga este precio cada vez: parsing, ejecución, hydration, diffing del virtual DOM, y así sucesivamente.

Los frameworks HTML-first funcionan de manera opuesta. Cargan rápidamente porque el navegador hace lo que sabe hacer mejor: renderizar HTML. La interactividad se añade en pequeñas piezas específicas en lugar de enviar un runtime completo.

Los Datos Confirman

Según un estudio de 2024:

El Time to Interactive (TTI) mediano para las SPAs era de 2.9 segundos, contra 1.8 segundos para los sitios SSR
El Time to First Byte (TTFB) mediano era de 0.6 segundos para las SPAs, contra 0.2 segundos para SSR

Los usuarios — especialmente los móviles — notan inmediatamente la diferencia.

Por Qué el Server-Side Rendering es Más Rápido para el Contenido

La ventaja del SSR reside principalmente en el tiempo más rápido para visualizar el contenido, que se hace más evidente en conexiones de Internet lentas o dispositivos poco potentes. El markup renderizado por el servidor no necesita esperar a que todo el JavaScript sea descargado y ejecutado para ser visualizado, por lo que los usuarios ven una página completamente renderizada antes.

Esto se traduce generalmente en mejores métricas Core Web Vitals, experiencia de usuario superior, y puede ser crítico para las aplicaciones donde el tiempo de visualización del contenido está directamente asociado a la tasa de conversión.

La UI Guiada por el Servidor es Más Limpia para la Mayoría de las Aplicaciones Business 🏢

La mayor parte de la lógica real — validación, reglas de negocio, control de accesos — reside de todos modos en el servidor. Los frameworks HTML-first no obligan a duplicarla en ambos lados.

En lugar de crear un endpoint API, transformarlo, consumirlo y sincronizar todo en el cliente… simplemente se renderiza HTML con el estado actualizado.

Simple. Predecible. Fácil de comprender y depurar.

Un Solo Routing, Una Sola Fuente de Verdad

Uno de los aspectos más subestimados del enfoque HTML-first es la eliminación de la duplicación del routing. En las SPAs tradicionales, inevitablemente se termina con dos sistemas de routing paralelos: uno en el servidor (para las APIs y el rendering inicial) y uno en el cliente (para la navegación interna). Esto significa doble configuración, doble mantenimiento y, a menudo, inconsistencias difíciles de depurar.

Con htmx y el enfoque server-driven, existe un solo routing: el del servidor. Las URLs corresponden directamente a los recursos, el navegador gestiona la navegación de forma nativa, y el desarrollador tiene una única fuente de verdad que mantener.

Validación: Solo Donde Realmente Importa

El mismo principio se aplica a los controles formales y la validación de datos. En las arquitecturas SPA, los desarrolladores a menudo se encuentran implementando la misma lógica de validación dos veces: en el cliente (para proporcionar feedback inmediato y mejorar la UX) y en el servidor (donde los controles DEBEN siempre residir por razones de seguridad).

Con el enfoque HTML-first, la validación permanece donde debe estar: en el servidor. Y gracias a la velocidad de las respuestas HTML parciales, el feedback al usuario es de todos modos casi instantáneo. El servidor valida los datos y devuelve directamente el HTML con los eventuales mensajes de error ya renderizados. Nada de duplicación de lógica, nada de riesgo de inconsistencias entre las reglas cliente y servidor, nada de posibilidad de que un usuario malintencionado bypasee los controles client-side.

¿Y si para evitar hacer demasiadas peticiones al servidor se quiere implementar un control también en el lado cliente? ¡Se puede hacer sin problemas! La diferencia fundamental es que no se está obligado a implementar la validación dos veces — se puede elegir hacerlo solo cuando tiene sentido para la UX, sabiendo que la validación server-side ya está garantizada.

🔐 Nota sobre seguridad: La validación client-side siempre es bypasseable. Un usuario malintencionado puede simplemente desactivar JavaScript o modificar las peticiones HTTP. La validación server-side no es opcional — es la única que realmente cuenta para la seguridad.

El Patrón HATEOAS Revive

El enfoque HTML-first está en línea con el principio arquitectónico HATEOAS (Hypermedia as the Engine of Application State), uno de los constraints REST originales a menudo ignorados en las modernas APIs JSON.

¿Pero qué dice exactamente este principio? HATEOAS establece que un cliente debe poder interactuar con una aplicación enteramente a través de las respuestas hypermedia proporcionadas dinámicamente por el servidor. En otras palabras, el cliente no debe tener conocimiento a priori de cómo interactuar con el servidor más allá de un punto de entrada inicial — todas las acciones posibles deben ser descubiertas dinámicamente a través de los links y controles presentes en la respuesta misma.

Piénsalo: cuando el servidor devuelve HTML, devuelve automáticamente los links a las páginas relacionadas, los formularios para las acciones disponibles, los botones para las operaciones permitidas. La interfaz es la API. El navegador ya sabe cómo navegar los links y enviar los formularios — no se necesita ninguna lógica client-side para “interpretar” la respuesta y decidir qué hacer después.

¿Tus JSON-APIs pueden hacer esto? En la gran mayoría de los casos, no. Las APIs JSON devuelven datos crudos que el cliente debe interpretar, y la lógica de navegación e interacción debe ser implementada separadamente en el código front-end. El cliente debe “saber” a priori qué endpoints llamar, cómo construir las peticiones, y cómo interpretar las respuestas — violando de hecho el principio HATEOAS.

Hagamos un ejemplo concreto: una lista de clientes que al hacer clic muestra el detalle del cliente individual.

Con una JSON-API tradicional:

{
  "customers": [
    {"id": 1, "name": "Mario Rossi", "email": "mario@example.com"},
    {"id": 2, "name": "Luigi Verdi", "email": "luigi@example.com"}
  ]
}

El cliente recibe estos datos y debe saber a priori que para obtener el detalle debe llamar a /api/customers/{id}. Este conocimiento está hardcodeado en el código JavaScript del front-end. Si la URL cambia, el cliente se rompe. Si hay reglas de acceso que impiden ver ciertos clientes, el cliente no lo sabe hasta que intenta llamar al endpoint y recibe un error.

Con htmx y el enfoque HTML-first:

<ul>
  <li>
    <a hx-get="/customers/1" hx-target="#detail">Mario Rossi</a>
  </li>
  <li>
    <a hx-get="/customers/2" hx-target="#detail">Luigi Verdi</a>
  </li>
</ul>
<div id="detail"></div>

El servidor devuelve directamente el HTML con los links ya incorporados. El cliente no necesita “saber” nada — simplemente sigue los links presentes en la respuesta. Si un usuario no tiene acceso a cierto cliente, el servidor simplemente no incluye ese link en la lista. Si la URL cambia, el servidor genera los nuevos links y el cliente continúa funcionando sin modificaciones.

¿Cuál de los dos enfoques respeta HATEOAS? Solo el segundo. El HTML es hypermedia por definición — fue diseñado exactamente para este propósito.

Para ser precisos, una JSON-API bien diseñada debería incluir una propiedad links para el discovery de los recursos relacionados:

{
  "customers": [
    {
      "id": 1,
      "name": "Mario Rossi",
      "email": "mario@example.com",
      "links": {
        "self": "/api/customers/1",
        "orders": "/api/customers/1/orders"
      }
    }
  ],
  "links": {
    "self": "/api/customers",
    "next": "/api/customers?page=2"
  }
}

Pero seamos honestos: la gran mayoría de las JSON-APIs en producción no implementa estos links. Y aun cuando lo hace, el problema no está resuelto: el cliente de todos modos debe tener una UI ya preparada y capaz de interpretar esos datos y mostrarlos apropiadamente. Los links JSON dicen dónde ir, pero no cómo presentar lo que se encuentra. El cliente todavía debe “saber” que un customer tiene un nombre, un email, y que los pedidos deben mostrarse en una tabla con ciertas columnas.

Con el HTML, en cambio, la representación ya está incluida en la respuesta. No se necesita ninguna lógica de rendering client-side.

Con htmx, el servidor no devuelve solo datos, sino que devuelve representaciones completas de la interfaz de usuario con los links y las acciones disponibles ya incorporadas. Esto elimina toda una categoría de problemas relacionados con la sincronización del estado entre cliente y servidor.

Menos Código y Menos Dependencias 📦

Uno de los mayores beneficios es simplemente un codebase más pequeño:

Ningún bundle enorme que optimizar y depurar
Ningún pipeline de build complicado (webpack, babel, typescript config, etc.)
Menos partes móviles que pueden romperse
Onboarding más fácil para los nuevos miembros del equipo
Menos problemas de upgrade de versiones

Esto se traduce también en menos bugs y mantenimiento más rápido a largo plazo.

El Costo Oculto de la Complejidad

Cada biblioteca JavaScript que añades al proyecto trae consigo un costo que va mucho más allá de los kilobytes de la descarga inicial.

Tomemos un ejemplo típico: quieres formatear una fecha. Instalas moment.js (o una alternativa moderna). Pero esa biblioteca tiene sus dependencias, que a su vez tienen otras. De repente, para formatear “2025-01-15” en “15 de Enero de 2025”, has añadido cientos de kilobytes a tu bundle.

Y no termina ahí. Cada biblioteca:

Tiene su propio ciclo de releases con breaking changes
Puede tener vulnerabilidades de seguridad que requieren actualizaciones urgentes
Debe ser compatible con todas las otras bibliotecas del proyecto
Añade tiempo al build y al deploy

Muchos desarrolladores instalan bibliotecas como lodash, axios o moment solo para usar una única función. Es como comprar una caja de herramientas completa para usar solo el destornillador.

⚠️ Atención: Cada dependencia es un potencial punto de ruptura. Los incidentes en la supply chain de JavaScript continúan ocurriendo regularmente — desde paquetes comprometidos hasta maintainers que abandonan proyectos críticos. Menos dependencias = menos riesgos.

Con el enfoque HTML-first, gran parte de esta complejidad simplemente desaparece. El formateo de fechas ocurre en el servidor (donde tienes control total del formato), las peticiones HTTP son gestionadas por htmx con pocas líneas de atributos, y el DOM se actualiza automáticamente con el HTML recibido. No es necesario reinventar la rueda con 200 KB de JavaScript.

Progressive Enhancement: Evolución, No Reescritura 🔄

Se puede añadir htmx a casi cualquier backend existente sin trastornar toda la estructura del proyecto.

¿Necesitas una tabla dinámica? Se mejora esa sección.

¿Necesitas interacciones modales sin una SPA completa? Se inserta el HTML al vuelo.

No es una decisión “todo o nada” — se mejora la interfaz paso a paso.

Los Tres Niveles del Progressive Enhancement

El progressive enhancement se basa en tres principios fundamentales:

Content First: En el corazón de cada sitio web está su contenido. El progressive enhancement asegura que el contenido sea accesible a todos los usuarios, incluso si tienen navegadores muy básicos o conexiones de Internet lentas. Esto significa partir de una sólida base HTML.
Funcionalidad Base: Garantizar que las funcionalidades core funcionen sin JavaScript avanzado. Con htmx esto es posible si se diseña con atención: los links pueden tener un href estándar como fallback, los formularios pueden funcionar con un submit normal. htmx mejora el comportamiento estándar del HTML. Sin embargo, es importante notar que las funcionalidades basadas en botones con hx-get o hx-post (que no sean submit de formularios) requieren JavaScript — está en el desarrollador decidir dónde el graceful degradation es importante y diseñar en consecuencia.
Experiencias Mejoradas: Añadir progresivamente funcionalidades avanzadas para navegadores y dispositivos que las soporten.

Wikipedia, alimentada por MediaWiki, es un ejemplo perfecto: es legible, navegable e incluso editable usando la interfaz HTML base sin styling o scripts, pero se mejora cuando estos están disponibles.

SEO, Accesibilidad y Comportamiento del Navegador Funcionan Nativamente 🌐

Cuando la aplicación usa HTML real en lugar de un Virtual DOM, se evitan muchos problemas accidentales que las SPAs introducen. El botón atrás, el deep linking, las herramientas de accesibilidad y el SEO funcionan todos naturalmente.

Ningún hack requerido.

Las Ventajas para el SEO

Dado que el contenido base siempre es accesible para los spiders de los motores de búsqueda, las páginas construidas con métodos de progressive enhancement evitan los problemas que pueden obstaculizar la indexación, mientras que tener que renderizar el contenido base de la página a través de la ejecución de JavaScript hace el crawling lento e ineficiente.

Esta estrategia acelera la carga y facilita el crawling por parte de los motores de búsqueda, ya que el texto en la página se carga inmediatamente a través del código fuente HTML en lugar de tener que esperar a que JavaScript se inicialice y cargue el contenido posteriormente.

Los motores de búsqueda dan prioridad a los contenidos accesibles y fáciles de leer. Partiendo de una estructura HTML limpia y asegurando que el contenido esté disponible para todos los usuarios, se mejoran las posibilidades de posicionarse bien en los resultados de búsqueda.

Preparados para la Era de la Búsqueda con IA

Hay un aspecto que muchos desarrolladores aún no están considerando: el ascenso de los motores de búsqueda basados en inteligencia artificial. Herramientas como ChatGPT Search, Perplexity, Google AI Overviews y otras están cambiando radicalmente la forma en que los usuarios encuentran información online.

Estos sistemas de IA necesitan contenido claro, estructurado e inmediatamente accesible. Aunque algunos crawlers modernos pueden ejecutar JavaScript, la ejecución a menudo es limitada, retrasada o incompleta. Una SPA que carga el contenido dinámicamente vía JavaScript corre el riesgo de ser indexada de forma parcial, imprecisa, o con retrasos significativos respecto a los sitios con contenido HTML inmediato.

Con el enfoque HTML-first, el contenido ya está presente en el documento HTML servido por el servidor. Los crawlers de IA (así como los tradicionales spiders de los motores de búsqueda) pueden inmediatamente acceder, comprender e indexar todo el contenido. Ninguna espera por la ejecución de JavaScript, ningún riesgo de que partes de la página no sean vistas.

En un mundo donde cada vez más tráfico llegará de las respuestas generadas por la IA, tener contenidos fácilmente accesibles y bien estructurados ya no es solo una best practice — es una necesidad competitiva.

🤖 Prepárate para el futuro: Los crawlers de IA se están volviendo cada vez más importantes. Un sitio invisible para la IA es un sitio que pierde oportunidades. El HTML-first te pone en pole position.

Las Ventajas para la Accesibilidad

Uno de los beneficios más significativos del progressive enhancement es la accesibilidad mejorada. Partiendo de una sólida base HTML, se asegura que el contenido sea accesible a todos los usuarios, incluidos aquellos con discapacidades.

Los lectores de pantalla y otras tecnologías asistivas funcionan nativamente con HTML semántico. Las SPAs, por otro lado, a menudo requieren implementaciones ARIA complejas y testing especializado para alcanzar el mismo nivel de accesibilidad.

htmx: La Estrella Emergente ⭐

htmx está viviendo un crecimiento impresionante. Según JavaScript Rising Stars 2024, htmx ha obtenido más estrellas GitHub anuales que bibliotecas más consolidadas como Vue y Angular (nota: esto se refiere al crecimiento anual de estrellas, no al total).

Los Números del Éxito

En el Stack Overflow Developer Survey 2024, htmx es el 22° framework web más usado con el 3.3% de los desarrolladores que lo utilizan
En términos de satisfacción, htmx es el 2° framework web más “admirado” con el 72.9% en la encuesta Stack Overflow 2024, segundo solo al framework Phoenix de Elixir (83.7%)
En el Django Developers Survey, el uso de htmx pasó del 5% en 2021 al 16% en 2022 — un crecimiento del 220%
htmx 2.0.0 fue lanzado el 17 de junio de 2024, marcando un importante hito de madurez
htmx fue admitido en el GitHub Accelerator en 2023, un programa que selecciona los proyectos open source más prometedores

Qué Hace Especial a htmx

htmx es pequeño (~14-16 KB min.gz), sin dependencias, extensible y, según los reportes, ha reducido el tamaño del código en un 67% respecto a React en proyectos comparables.

htmx no solo reduce el tamaño del bundle — elimina la necesidad del diffing del Virtual DOM, de los ciclos de vida de los componentes y de la orquestación del estado client-side. El resultado son cargas de página más rápidas, menos código que depurar y un modelo mental más ligero para construir interfaces de usuario.

Ideal para Apps Enterprise, Dashboards y Portales 💼

No todas las aplicaciones son herramientas de diseño altamente interactivas. Muchos de los sistemas que las empresas construyen — plataformas de reservas, dashboards, herramientas de administración, formularios, portales internos — se adaptan perfectamente a este modelo.

No necesitan 500 KB de JavaScript para gestionar interacciones básicas.

Los frameworks HTML-first encuentran un buen equilibrio entre interactividad y mantenibilidad.

Casos de Uso Perfectos para HTML-First

Dashboards administrativos: Tablas con paginación, filtros, acciones CRUD
Portales internos: Gestión de documentos, workflow approval, reportes
E-commerce backend: Gestión de pedidos, inventario, clientes
Formularios complejos multi-step: Wizards de registro, configuradores de producto
Sistemas de booking: Calendarios, reservas, gestión de slots
CRM y ERP: Gestión de contactos, pipeline de ventas, facturación
Aplicaciones de data-entry: Import/export de datos, bulk editing

htmx y Delphi: Una Combinación Ganadora 🚀

Para los desarrolladores Delphi, el enfoque HTML-first con htmx representa una oportunidad particularmente interesante. DelphiMVCFramework ofrece un excelente soporte para este paradigma, permitiendo aprovechar la potencia y la fiabilidad del backend Delphi con un front-end moderno y ligero.

Las Ventajas para los Desarrolladores Delphi

Backend robusto: La solidez y el rendimiento de Delphi en el servidor
Template engines potentes: TemplatePro o WebStencils para generar HTML dinámico
Simplicidad de deployment: Un único ejecutable sin dependencias node.js
Ningún build JavaScript: Adiós a webpack, npm, y tool chains complejas
Competencias reutilizables: Los desarrolladores Delphi pueden ser productivos inmediatamente

Los proyectos quickstart disponibles en GitHub (TemplatePro + htmx y WebStencils + htmx) ofrecen un punto de partida ideal para comenzar.

💡 Consejo: Si eres un desarrollador Delphi y quieres empezar con htmx, clona uno de los proyectos quickstart y tendrás una aplicación funcionando en pocos minutos. Ninguna configuración npm, ningún webpack, ningún node_modules de 500 MB.

Cuándo NO Usar el Enfoque HTML-First ⚖️

Es importante ser honestos: el enfoque HTML-first no es la solución para todo. Aquí es cuando las SPAs tradicionales siguen siendo la mejor opción:

Aplicaciones altamente interactivas en tiempo real: Editores gráficos, herramientas de colaboración como Google Docs, aplicaciones de edición de video
Aplicaciones offline-first: Cuando la aplicación debe funcionar significativamente sin conexión
Juegos y aplicaciones 3D: Donde el rendering client-side intensivo es necesario
Aplicaciones con estado cliente complejo: Donde el estado de la interfaz es significativamente diferente del estado del servidor

Para estos tipos de aplicaciones, las SPAs ofrecen ventajas concretas: gestión sofisticada del estado local, transiciones fluidas entre vistas complejas, y la posibilidad de funcionar offline con service workers.

El Futuro: Un Enfoque Híbrido 🔮

La tendencia que estamos observando no es un retorno al pasado, sino una evolución hacia un enfoque más pragmático. Los mejores desarrolladores están aprendiendo a elegir la herramienta adecuada para el problema específico.

El Paradigma Islands Architecture

Una tendencia emergente es la “Islands Architecture”, donde la mayor parte de la página es HTML estático o server-rendered, con “islas” de interactividad JavaScript solo donde es necesario. Frameworks como Astro.js (con un impresionante 94% de usuarios que lo usarían de nuevo según el State of JavaScript 2024) están explorando este territorio.

htmx se inserta perfectamente en este paradigma, permitiendo añadir interactividad donde se necesita sin requerir una arquitectura completamente client-side.

Conclusiones 🎯

React y Angular tienen absolutamente su lugar, y son excelentes cuando realmente se necesita una aplicación client-side compleja. Pero para muchos proyectos, el enfoque HTML-first es más rápido de construir, más fácil de mantener y más ligero para el navegador.

No es un paso atrás — es un recordatorio de que la web ya nos proporciona todo lo que necesitamos para construir aplicaciones potentes y reactivas sin el peso adicional.

Con htmx que ahora cuenta con más del 72% de satisfacción entre los desarrolladores, un crecimiento explosivo de estrellas en GitHub, y la adopción por parte de equipos cada vez más grandes, está claro que esto no es solo una tendencia pasajera. Es un redescubrimiento de los principios fundamentales de la web, potenciado por herramientas modernas que hacen la experiencia de desarrollo fluida y agradable.

La próxima vez que comiences un nuevo proyecto web, antes de recurrir automáticamente a React o Vue, pregúntate: “¿Realmente necesito todo esto?” La respuesta podría sorprenderte.

🚀 ¿Listo para probar? Empieza con un pequeño proyecto o mejora una sección de una aplicación existente. htmx no requiere una reescritura completa — puedes adoptarlo gradualmente y ver los beneficios inmediatamente.

Recursos para Profundizar 📚

🎓 ¿Quieres profundizar con un curso? bit Time Professionals ofrece cursos dedicados sobre htmx y sobre la integración DelphiMVCFramework + TemplatePro + htmx. Seguir un curso estructurado te permite ser productivo desde el primer momento, con aplicaciones prácticas, ejemplos reales, patrones arquitectónicos probados y mejores prácticas aprendidas en años de experiencia en el campo. Los cursos están disponibles en italiano, inglés y español.