Este es una de las newsletters antiguas que se enviaron de forma exclusiva a los miembros del Club Negocios Seguros, y que se liberan públicamente un mes más tarde.
El Club Negocios Seguros está actualmente, y de forma temporal, cerrado, por lo que no se admiten nuevos miembros
*******
Negocios Seguros
Imagínate recibir de manera totalmente gratuita este tipo de historias directamente en tu correo.
Te envío cada lunes a las 7am un email con toda la actualidad sobre tecnología, seguridad y negocios digitales.Newsletter 1040
*********
La web ha evolucionado muchísimo desde sus orígenes, pero lo cierto es que en algunos aspectos clave sigue anclada en tecnologías viejas.
Mientras herramientas modernas como WebAssembly (WASM) o WebGPU empiezan a abrir camino incluso en el lado del servidor, la realidad es que las páginas que usamos a diario siguen construidas sobre HTML, CSS y el DOM, sistemas que fueron diseñados hace décadas… y que nunca estuvieron pensados para las necesidades actuales.
Lo decía hace poco el desarrollador Steven Wittens en su blog (EN): estamos construyendo con piezas que ya no encajan.
(el símil me parece interesantísimo y muy bien lanzado)
Y la pregunta es evidente: ¿por qué seguimos atrapados en un modelo roto?
¡Pues vamos a verlo!
El caos del DOM
Cuando visitas una página web, tu navegador levanta un árbol interno para mostrarte el contenido. Ese árbol es el DOM (Document Object Model).
La metáfora clásica es imaginarlo como una maqueta de LEGO: cada bloque es un elemento (título, párrafo, botón, imagen…).
Suena bien, ¿verdad?
El problema es que la caja de piezas se ha vuelto tan absurda que nadie la entiende del todo, ni siquiera los ingenieros que trabajan en Chrome o Safari.
Solo habría que revisar el DOM de esta misma página para darte cuenta de que la cosa no funciona. En teoría todo debería ser sencillo de identificar, pero en la práctica, en una web dinámica, como es esta, dependiente de numerosos componentes (que si wordpress, que si la plantilla, que si los plugins, que si las traducciones, que si el código propio…) la cosa se complica.
¿Un ejemplo?: solo document.body tiene más de 350 funciones y propiedades diferentes. Y si hablamos de estilos, CSS ofrece más de 660 formas distintas de tocar el aspecto visual.
¿El resultado?:
- Muchas funciones ya no se usan, pero siguen ahí.
- Otras hacen lo mismo de maneras distintas.
- Y algunas actúan de forma inesperada.
Por eso la mayoría de desarrolladores modernos no trabajan directamente con el DOM. Se refugian en capas intermedias como React o Vue, que simplifican lo que el sistema base no supo resolver.
Los Web Components intentaron traer algo de orden, pero llegaron tarde y su adopción ha sido mínima.
Y en estas estamos…
HTML: semántica que nunca llega
HTML nació con una misión clara: dar estructura al contenido. Que un título fuera un título, que un artículo se diferenciara de un comentario, que una lista fuera reconocible como tal.
Eso es la semántica, y debería ser la base de una web clara y accesible.
Pero más de 10 años después de HTML5 seguimos sin etiquetas para cosas tan básicas como <thread> (un hilo) o <comment> (un comentario). En lugar de eso, los desarrolladores tiramos de <div>s y <article>s genéricos, esperando que los buscadores y navegadores “adivinen” qué significan.
Y claro, el problema es que las decisiones sobre cómo evoluciona HTML las toman principalmente los fabricantes de navegadores, y lo hacen a golpe de parches.
En vez de rediseñar lo que está roto, han optado por poner tiritas en una prenda vieja.
El resultado es, por tanto, un lenguaje estancado, confuso y que no termina de cumplir bien su propósito original.
CSS: el eterno dolor de cabeza
CSS es el sistema encargado de darle forma a la web. Márgenes, tamaños, colores, posiciones… En teoría debería ser simple, pero en la práctica alinear dos cajas en pantalla puede convertirse en una pesadilla.
¿Que por qué? Porque CSS calcula el espacio de forma poco intuitiva: primero mira el contenido y después decide el tamaño de la caja. Si no le indicas medidas concretas, ignora tus instrucciones.
Con herramientas como Flexbox o Grid la cosa ha mejorado, pero aún así no deja de ser un lenguaje lleno de excepciones y contradicciones. Lo que debería ser fácil acaba exigiendo reglas y trucos que hacen perder tiempo a cualquier equipo de desarrollo.
SVG: potente pero incómodo
Los gráficos vectoriales escalables (SVG) son geniales para iconos, logotipos y gráficos. No se pixelan, se pueden animar, se integran con el resto de la página… pero también arrastran problemas:
- No se llevan del todo bien con CSS.
- Su sintaxis es críptica (intenta leer un
<path>y verás). - A veces no está claro si usar HTML+CSS o SVG para una misma tarea.
La consecuencia es que trabajar con SVG termina siendo otro dolor añadido a la ya caótica mezcla de tecnologías web.
Sin ir más lejos, en esta página cohabitan jpgs, pngs, SVGs y webm, y los voy usando casi indistintamente, sin criterio.
Kitbashing: la web como Frankenstein
El término kitbashing viene del modelismo: construir maquetas combinando piezas que no fueron diseñadas para ir juntas.
Pues bien, la web moderna es exactamente eso.
Intentamos hacer aplicaciones completas (chats, editores, redes sociales) con herramientas que fueron creadas para mostrar documentos estáticos.
Y claro, aparecen todos los parches:
- Mantener un chat siempre pegado abajo de la pantalla.
- Copiar y pegar texto con formato sin romperlo.
- Renderizar listas enormes sin que todo se vuelva lento.
- Adaptar un diseño a móvil y escritorio sin escribir mil reglas CSS.
Todo esto exige trucos invisibles, librerías externas y toneladas de código que solo existen porque el sistema base nunca estuvo pensado para esto.
Canvas y la tentación de reinventar la rueda
Ante tanto dolor, algunos miran hacia Canvas como solución.
La idea es clara: si HTML+CSS+DOM no dan la talla, ¿por qué no usar un lienzo programable y renderizar ahí todo?
El problema es que eso implica reinventar absolutamente todo: eventos, accesibilidad, interacción, localización… Como programar un videojuego desde cero, pero con la carga añadida de que sigues dependiendo del DOM.
Canvas tiene potencia, sí. Pero también limita muchísimo en temas clave como accesibilidad o compatibilidad móvil.
¿Entonces qué hacemos?
Ahí está el quid de la cuestión.
Lo que está claro es que el modelo actual está roto. Seguir parchando no es sostenible.
Necesitamos repensar la web desde tres bases claras:
- Separar contenido, estilo e interacción de forma nítida.
- Diseñar para aplicaciones, no solo para documentos.
- Apostar por un sistema más fácil de entender y mantener.
La buena noticia es que ya hay proyectos que lo están probando. Use.GPU (EN), por ejemplo, usa WebGPU para ofrecer interfaces más rápidas, claras y fáciles de programar. También navegadores como Servo o Ladybird están explorando caminos nuevos sin la mochila de 30 años de parches.
La web que viene
Y es que, recalco, no se trata de tirar todo lo que tenemos y empezar de cero (no podríamos aunque quisiéramos), pero sí de atrevernos a repensar lo fundamental.
La web nació como un sistema de documentos enlazados. Hoy es el ecosistema donde corren aplicaciones críticas para nuestra vida y nuestros negocios. Y mientras sigamos construyendo con piezas pensadas para otro mundo, estaremos limitados.
Quizás ha llegado el momento de dejar de remendar, y empezar a construir con herramientas que de verdad estén hechas para el presente.
¿Cómo lo ves?
Imagínate recibir en tu correo semanalmente historias como esta
El CLub Negocios Seguros está actualmente cerrado, pero puedes suscrirte ahora GRATIS a «Las 7 de la Semana», la newsletter sobre Nuevas Tecnologías y Seguridad de la Información. Cada lunes a las 7AM horario español un resumen con todo lo importante de estos últimos días, y recibe, de paso, acceso a mi último eBook, de más de 40 páginas, con herramientas de ofuscación en criptomonedas que usa la industria del blanqueo de capitales (y que deberías conocer para evitar caer en fraudes y ciberataques).
