La web ha evolucionado enormemente desde sus inicios, pero en algunos aspectos cruciales sigue anclada en el pasado. Mientras tecnologías como WebAssembly (WASM) ganan terreno incluso en el servidor, las páginas web que usamos todos los días todavía funcionan con sistemas viejos como el DOM, HTML y CSS, que fueron creados hace décadas y no están pensados para las necesidades de hoy.
En su blog profesional, el desarrollador Steven Wittens ha expuesto con detalle esa idea (y dejado caer, al final, algunas posibles soluciones) en un texto que propone repensar, desde su misma base, los fundamentos del desarrollo web.
¿Qué es el DOM y por qué es un lío?
Cuando visitas una página web, tu navegador construye una especie de «árbol» interno para entender y mostrar el contenido. Ese árbol se llama DOM, que significa Document Object Model o «Modelo de Objetos del Documento».
Imagina que el DOM es como una maqueta de LEGO de la página, donde cada bloque representa un elemento: un título, una imagen, un botón, etc. Suena bien, ¿verdad? El problema es que este sistema se ha vuelto tan viejo y complicado que ya nadie lo entiende del todo bien… ni siquiera los expertos.
Por ejemplo, en Google Chrome, un solo bloque de esa maqueta (document.body, que es básicamente el cuerpo de la página) tiene más de 350 funciones y propiedades diferentes. Y si hablamos del estilo (colores, márgenes, tamaños), hay más de 660 opciones solo para eso.
Es como tener una caja de herramientas tan grande que ya no sabes qué usar, ni cómo. Además:
- Muchas herramientas están obsoletas (ya no se usan, pero ahí siguen).
- Varias hacen lo mismo, pero de formas diferentes.
- Algunas cambian cosas en la página de maneras inesperadas.
Debido a este caos, la mayoría de desarrolladores modernos evitan trabajar directamente con el DOM. Usan herramientas más fáciles y organizadas (como React o Vue), que simplifican todo.
Y aunque hay intentos por mejorar esto, como los Web Components (una forma más moderna de crear partes reutilizables de una página), llegaron tarde y no son muy populares porque son difíciles de usar.
HTML: ¿Y la semántica, dónde quedó?
HTML es el lenguaje básico con el que se construyen las páginas web. Su objetivo original era permitir que los sitios fueran claros y organizados: con títulos, párrafos, listas, artículos, comentarios… todo bien etiquetado.
Eso se llama semántica: usar etiquetas que explican qué es cada parte del contenido, no solo cómo se ve.
Pero, aunque han pasado más de 10 años desde que salió la versión vigente de HTML (HTML5), seguimos sin tener etiquetas para cosas tan comunes como un hilo de conversación (<thread>) o un comentario (<comment>). Eso significa que los desarrolladores tienen que improvisar y usar etiquetas genéricas como <div> o <article>, que no dicen claramente lo que representan.
Además, las reglas para usar las etiquetas «correctamente» son confusas. Por ejemplo, según algunas guías, un artículo dentro de otro artículo podría considerarse un comentario… pero eso no tiene mucho sentido, ¿verdad?
Hoy en día, las grandes decisiones sobre cómo evoluciona HTML las toman principalmente los creadores de navegadores (como Google o Apple), no una comunidad abierta. ¿Y qué han hecho? Pues en lugar de rediseñar o simplificar HTML, han ido agregando pequeñas cosas nuevas aquí y allá, como quien sigue parcheando una prenda vieja.
CSS: ¿por qué alinear cosas en la web es tan difícil?
CSS (siglas en inglés de «hojas de estilo en cascada») es lo que usamos para darle forma y colores a una página web: tamaños, márgenes, colores, posiciones, etc. Pero a pesar de ser tan importante… muchas veces parece estar en contra nuestra.
¿Te ha pasado que simplemente quieres poner dos cosas una al lado de la otra, o que algo quede centrado en la pantalla, y por más que lo intentas no pasa lo que esperas? No estás solo.
El problema principal es que CSS no funciona como creemos.
Imagina que tienes una caja con dos cajones adentro y que quieres que cada cajón ocupe la mitad del espacio. Lógico, ¿no?
<div>
<div style="height: 50%">...</div>
<div style="height: 50%">...</div>
</div>
Pero CSS no lo entiende así. En realidad, necesita que primero le digas cuánto mide la caja grande. Si no lo haces, simplemente ignora tus instrucciones.
Esto es porque CSS trabaja de una forma algo rara: primero mira el contenido (lo que hay dentro) y luego decide qué tamaño debería tener el contenedor. Es como si compraras una caja para tus cosas… después de ver cuántas cosas tienes.
¿Cómo se soluciona eso? Bueno, el CSS moderno tiene herramientas como Flexbox, que ayudan a distribuir mejor el espacio entre elementos. Pero hasta esas herramientas cuentan con sus propios problemas.
SVG: potente pero caótico
SVG son las siglas en inglés de «gráficos vectoriales escalables». Es una tecnología que permite dibujar cosas como iconos, gráficos, logotipos o ilustraciones directamente dentro de una página web, sin que se vean borrosas al hacer zoom. Resulta útil porque…
- Puedes cambiar el tamaño de un dibujo sin perder calidad.
- Puedes modificar colores, formas o posiciones con código.
- Incluso puedes hacer que reaccione al pasar el mouse o hacer clic.
Pero, aunque SVG sea tan polivalente, usarlo en combinación con HTML y CSS puede volverse un lío por varias razones:
- No ‘habla el mismo idioma’ que CSS: Aunque a veces puedes aplicar estilos CSS a los dibujos SVG, no siempre funcionan igual. Hay reglas que se comportan diferente o simplemente no aplican.
- Es complejo: Para hacer un dibujo, tienes que escribir instrucciones como
<path d="M150 0 L75 200 L225 200 Z" />. ¡Sí, eso es un triángulo! Pero no es precisamente amigable a la vista ni fácil de entender. - ¿Cuándo usar SVG y cuándo HTML?: A veces puedes hacer una figura con HTML y CSS, otras veces necesitas SVG. Pero no hay una regla clara. Elegir entre uno u otro puede depender de detalles técnicos molestos.
- Algunas cosas útiles solo están en SVG: Por ejemplo, si quieres detectar clics en formas con bordes irregulares (como una estrella), SVG lo hace fácil. HTML y CSS… no tanto.
La pesadilla del ‘kitbashing web’
A lo largo de los años, el desarrollo de interfaces web ha evolucionado a base de «parchar» las herramientas existentes. Esto ha dado lugar al fenómeno del kitbashing, un término tomado del modelismo donde se ensamblan modelos a partir de piezas que no estaban diseñadas para funcionar juntas. En la web, esto se traduce en construir interfaces sofisticadas combinando HTML, CSS y SVG en formas para las que nunca fueron concebidos.
Esto ocurre porque HTML y CSS no fueron pensados originalmente para hacer aplicaciones. Se crearon para mostrar documentos, como artículos o noticias, no para hacer cosas como editores de texto tipo Google Docs o chats como WhatsApp Web.
Ejemplos de lo difícil que puede ser:
- Un chat que se quede pegado abajo (como en WhatsApp):
Parece algo básico, ¿no? Pero lograr que la ventana del chat se quede abajo cuando llega un nuevo mensaje requiere escribir código personalizado cada vez. No hay una forma fácil y automática de hacerlo con HTML y CSS. - Copiar y pegar texto con formato: Si alguna vez copiaste texto de una página web y lo pegaste en otro lugar, sabrás que a veces se conserva el color o el estilo… y a veces no. Hacer que eso funcione bien en una app web requiere «trucos invisibles», como poner elementos escondidos fuera de la pantalla para que el sistema entienda qué se está copiando.
- Listas y tablas muy largas (como una hoja de cálculo): Mostrar muchos datos (como en Excel) es difícil en una web. Si lo haces directamente, la página se vuelve lenta. Para solucionarlo, los desarrolladores tienen que «engañar» al navegador: solo muestran una parte de la lista y cambian lo que se ve a medida que el usuario se desplaza.
- Cajas que se vean bien en diferentes tamaños de pantalla: Ajustar el diseño para que se vea bien en un celular y en una computadora suena lógico, pero hacerlo con HTML y CSS puede ser muy complicado. A veces hay que escribir muchas reglas específicas, o usar herramientas externas que tratan de hacerlo más fácil.
Canvas: ¿una solución?
Ante las limitaciones evidentes del DOM y CSS, algunos desarrolladores y estándares emergentes han puesto sus ojos en una alternativa radical: usar <canvas> como plataforma principal para renderizar interfaces. La propuesta más notable en esta línea es HTML-in-Canvas, que plantea la idea de renderizar fragmentos de HTML dentro de un <canvas>, permitiendo personalizar completamente su presentación visual.
Suena atractivo: ¿por qué no aprovechar la potencia gráfica de Canvas para superar las deficiencias del modelo de caja y de estilo del navegador? Pero este enfoque trae consigo una gran cantidad de obstáculos tanto técnicos como filosóficos.
Para empezar, la API propuesta sigue estando atada al DOM, lo que significa que los elementos a renderizar deben seguir existiendo dentro del árbol de documentos para ser interpretables. Esto introduce una contradicción: si necesitas <canvas> para librarte del DOM, ¿por qué seguir dependiendo de él para dibujar?
Además, para lograr interactividad, el sistema obliga a reimplementar el modelo de interacción desde cero: gestión de eventos de mouse, teclas, estados de foco, accesibilidad… todo debe recrearse manualmente.
Se trata de un sistema donde el desarrollador asume el control absoluto, pero también la carga completa, como si estuviera desarrollando usando un motor de videojuegos.
Uno de los principales argumentos a favor de usar canvas es que “al menos es programable”. Pero en realidad, es un recurso extremadamente limitado:
- No tiene acceso directo a fuentes del sistema ni a APIs nativas de layout de texto.
- No ofrece herramientas nativas para manejar accesibilidad, localización o compatibilidad móvil.
- No permite reusar eficientemente estilos, efectos ni interacciones predefinidas del navegador.
¿Y entonces, qué?
Después de todo lo que hemos visto, queda claro que el modelo actual de cómo se construyen las páginas web —usando HTML, CSS y el famoso DOM— está roto, pero eso no significa que no haya solución. De hecho, según Wittens es totalmente posible mejorar todo esto… si nos atrevemos a cambiar las bases. Así que, ¿qué deberíamos hacer?
Empezar con una estructura más clara
Hoy en día, cuando haces una web, terminas mezclando muchas cosas: contenido, estilo y comportamiento. Todo está enredado.
Lo ideal sería separar mejor:
- Lo que se muestra (el diseño).
- Cómo se comporta (la interacción).
- Qué significa cada cosa (la semántica).
Tener estos tres aspectos separados haría que todo fuese más fácil de desarrollar, mantener y escalar.
Diseñar pensando en cómo se hacen apps hoy
Las páginas web de hoy ya no son solo documentos, son aplicaciones completas, como redes sociales, editores de texto, videojuegos… Y para eso necesitamos herramientas más modernas. Cosas como React, Vue o Svelte existen precisamente porque el sistema base (HTML+CSS+DOM) no da la talla.
Así que ¿por qué no rediseñar esas bases para que lo moderno ya venga incorporado?
- Que los cambios en la pantalla sean automáticos cuando cambie algo en el sistema.
- Que podamos mover elementos o cambiar estilos sin pelear con reglas raras de CSS.
- Que el código sea fácil de leer, escribir y entender.
Ya hay ejemplos funcionando
Wittens insiste en que no estamos hablando de fantasías, pues ya hay proyectos reales que ya están probando cómo se podría hacer todo esto mejor. Uno de ellos, por ejemplo, es Use.GPU, un sistema visual hecho con tecnología nueva llamada WebGPU. ¿Qué logra?
- Interfaces mucho más rápidas y suaves.
- Diseños con menos líneas de código.
- Posicionamiento de elementos que por fin tiene sentido (sí, centrar cosas es fácil).
- Efectos visuales sin trucos raros ni dolores de cabeza.
Y esto lo ha hecho una sola persona, con un sistema más claro y moderno que toda la maquinaria actual del navegador.
También hay navegadores nuevos como Servo y Ladybird que están empezando de cero. No arrastran todo el peso de 30 años de web, así que pueden tomar decisiones más inteligentes desde el principio.
Imagen | Marcos Merino mediante IA
En Genbeta | En esto consiste la labor de un desarrollador Full Stack: un perfil laboral todoterreno
–
La noticia
«El HTML está muerto», según este programador, y estas son las razones (también habla de cómo podríamos resucitarlo)
fue publicada originalmente en
Genbeta
por
Marcos Merino
.