HTML está muerto. La frase es perfecta para encender debates en redes y foros de desarrolladores. Pero, más allá del titular, hay una realidad incómoda detrás de esa provocación: la distancia entre lo que HTML5 prometió y lo que hoy sentimos cuando construimos aplicaciones modernas. Si alguna vez soñaste con crear un SaaS completo sin plugins, sin parches extraños y con acceso nativo a capacidades del dispositivo, entenderás por qué a muchos les suena a epitafio.
Lo que HTML5 prometió
HTML5 llegó con una misión clara: convertir la web en una plataforma de aplicaciones capaz de reemplazar a los viejos plugins, con multimedia, almacenamiento, gráficos y conectividad en primera clase. El discurso era irresistible: escribe para la web y tu app vivirá en cualquier navegador, sistema operativo o dispositivo. Menos fricción, más alcance, menos dependencias.
Lo que sí cumplió la plataforma web
Sería injusto decir que HTML5 fue humo. Muchas piezas llegaron, maduraron y hoy son pilares de la web moderna:
- Multimedia sin plugins con video y audio, además de gráficos con canvas y aceleración 3D vía APIs del navegador.
- Aplicaciones más ricas gracias a almacenamiento local, IndexedDB, Service Workers y caché controlada para experiencias offline.
- Conectividad en tiempo real con WebRTC y canales más eficientes para colaboración, streaming y llamadas.
- Integración con el sistema operativo con notificaciones, portapapeles, acceso a archivos y mejores capacidades de instalación para apps web.
- Acceso a hardware seleccionado mediante APIs del navegador, como sensores, Bluetooth o USB en contextos y navegadores compatibles.
No todo esto es HTML en sentido estricto. Es el conjunto: HTML como esqueleto, CSS para estilos, JavaScript y APIs del navegador como músculo y nervios. Pero, en la mente colectiva, HTML5 fue el paraguas que prometió llevarnos a esa web capaz de competir con lo nativo.
Donde se quedó corto
La otra cara es la de las promesas aplazadas o abandonadas, y la sensación de que la innovación se diluyó en pasos pequeños y dispersos:
- Estándares que quedaron en el camino como WebSQL o AppCache, que marcaron avances, pero terminaron deprecados o reemplazados tras años de inversión mental de la comunidad.
- APIs con soporte irregular entre navegadores que frenan la adopción en entornos productivos. Si no funciona de forma consistente, es difícil apostar fuerte.
- Componentes de interfaz nativos limitados. Formularios potentes, sí, pero con controles inconsistente y poca ambición: un selector de fecha no siempre es suficiente para una UI compleja.
- Complejidad accidental para funcionalidades clave. Offline, sincronización, permisos, empaquetado o distribución siguen siendo un rompecabezas para equipos pequeños.
El resultado es una paradoja: la web avanzó, pero muchos construyen apps como si HTML fuera solo un contenedor hueco para frameworks que hacen el trabajo duro. De ahí la percepción de que HTML está muerto. No porque no exista, sino porque dejó de ser el protagonista.
El golpe de realidad
La brecha entre expectativa y realidad también la agrandan dos fuerzas del mercado:
- Frameworks hiperproductivos. React, Vue, Svelte y compañía ofrecieron un modelo mental claro para construir interfaces reactivas, estado compartido y escalabilidad del front. En ese mundo, HTML se convierte en plantilla o DSL de salida, no en la fuente de verdad.
- La batalla de la interoperabilidad. La web es más abierta que nunca, pero la compatibilidad pixel-perfect y de APIs sigue siendo un trabajo artesanal. Donde una app nativa tiene un SDK homogéneo, la web tiene matices por navegador y plataforma.
¿Conclusión provisional? HTML no está muerto, está maduro. El problema es que maduro, a veces, suena a estable y estable suena a aburrido. Y cuando la competencia innova a ritmo de vértigo, la percepción pesa.
Cómo podríamos resucitar a HTML
Si resucitar significa devolverle el papel de protagonista, hay caminos posibles. Algunos ya asoman; otros requerirían decisiones valientes de la comunidad y los fabricantes de navegadores.
1. Una biblioteca de componentes nativos ambiciosa
No basta con input, select y dialog. La web necesita componentes de alto nivel, accesibles y performantes por defecto:
- Data grid, virtual list, tree view, tabs, steppers y menús contextuales estándares y estilables.
- Mejoras de formularios con autocompletado internacional, máscaras, rangos, valores monetarios y validaciones configurables.
- Patrones accesibles incorporados por diseño para reducir deuda técnica y errores comunes.
Esto no significa cerrar la puerta a la personalización, sino ofrecer bloques sólidos que cubran el 80 por ciento de casos, con APIs claras para el 20 por ciento restante.
2. Declarativo sobre imperativo
El HTML brilla cuando describe la UI sin lógica incidental. Potenciar lo declarativo reduciría la dependencia de JavaScript para tareas repetitivas:
- Sombras y encapsulamiento declarativos más simples para componentes con plantillas reutilizables.
- Vinculación de datos básica y eventos comunes sin bootstrap de JS para listas, formularios y estados simples.
- Caché y recursos offline definidos de forma declarativa para casos típicos como blogs, catálogos o lectores.
Menos pegamento imperativo y más intención expresada en el marcado.
3. Permisos, capacidades y empaquetado entendibles
La web necesita una historia de instalación, permisos y actualización aún más clara para competir con app stores y escritorios:
- Manifiestos de aplicación más expresivos y verificables, con perfiles de capacidades por contexto.
- Paquetes web firmados y actualizables que aseguren integridad y simplifiquen distribución empresarial.
- Permisos granulares con UX consistente y reglas predictibles por navegador.
No se trata de replicar las tiendas cerradas, sino de dar confianza y gobernanza a nivel de plataforma.
4. Rendimiento y observabilidad first-class
El rendimiento es experiencia. Algunas mejoras posibles:
- Directivas de rendimiento en el propio HTML para controlar prioridad de recursos, prerender y streaming de componentes.
- Métricas de usuario reales accesibles con APIs simples y estandarizadas.
- Lazy loading extensible más allá de imágenes e iframes para cualquier bloque declarativo.
Así la optimización deja de ser magia negra y pasa a ser parte del lenguaje.
5. Interoperabilidad sin excusas
Los avances en pruebas compartidas y especificaciones vivas han ayudado. Falta convertir la compatibilidad en contrato social fuerte:
- Niveles de compatibilidad versionados que permitan a equipos saber qué pueden usar sin sorpresas.
- Compromisos públicos de implementación cruzada antes de anunciar funcionalidades como listas para producción.
Menos promesas y más entregables que funcionen en todos lados el primer día.
La web ya tiene piezas para competir
Sería incorrecto pintar un panorama gris. Hoy podemos construir aplicaciones serias con la plataforma web, y muchas empresas lo hacen con éxito. Algunas prácticas que funcionan ahora mismo:
- Progresive enhancement de verdad. Renderizado en servidor, HTML semántico y comportamiento mejorado con JS donde aporta valor medible.
- Web Components estratégicos. Componentes encapsulados para piezas independientes, sin casarse con un framework como contrato de por vida.
- Service Workers con plantillas. Usar soluciones probadas para caché y sincronización en lugar de inventar desde cero.
- Medir antes de optimizar. Core Web Vitals, pruebas A/B y observabilidad desde el día uno. El rendimiento es producto, no posdata.
La clave es elegir el nivel de abstracción adecuado. Cuando una SPA la exige el negocio, adelante. Cuando un sitio de contenido puede vivir con HTML más ligero, también es una victoria.
Lo que nos enseñó HTML5
La gran lección es que la web no es un único estándar, sino un ecosistema. HTML no murió, pero dejó de ser el único héroe. La pregunta correcta quizá no es si HTML está muerto, sino si la web como plataforma mantiene su promesa. Y para eso necesitamos que HTML vuelva a llevar la batuta en lo declarativo, la accesibilidad, la interoperabilidad y la experiencia de desarrollo.
¿Y ahora qué?
La pelota no está solo en los navegadores. Está en la comunidad que decide qué se adopta, qué se enseña y qué se prioriza:
- Premiar lo nativo. Cuando un componente estándar sirva, úsalo. Eso envía señales.
- Evitar dependencias por inercia. Si una herramienta no resuelve un problema real, es peso muerto.
- Participar en el proceso. Estándares se escriben con casos reales. Reporta, propone, prueba.
Resucitar HTML es, en el fondo, recordar para qué existe: expresar la estructura y el significado de nuestras interfaces con la menor fricción posible, mientras la plataforma nos da superpoderes sin pedirnos un framework para cada gesto. Cuando esa visión vuelva a sentirse tangible, nadie preguntará si HTML está muerto. Estaremos demasiado ocupados construyendo sobre él.
HTML no está muerto, está maduro. La decepción nace de promesas desalineadas, avances irregulares y la sombra de los frameworks. Resucitarlo implica más componentes nativos, más declaratividad, permisos y empaquetado claros, y compromisos reales de interoperabilidad. La web ya compite, pero puede hacerlo con menos fricción y más ambición.
