"El HTML está muerto", según este programador, y estas son las razones (también habla de cómo podríamos resucitarlo)

Por otra parte, las reglas para usar las etiquetas "correctamente" son confusas. Por ejemplo, según algunas guías, un artículo internamente 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 emplazamiento 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 flanco de la otra, o que poco 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 medio del espacio. Natural, ¿no?

Pero CSS no lo entiende así. En ingenuidad, necesita que primero le digas cuánto mide la caja holgado. Si no lo haces, simplemente ignora tus instrucciones.

Esto es porque CSS trabaja de una forma poco rara: primero mira el contenido (lo que hay internamente) y luego decide qué tamaño debería tener el contenedor. Es como si compraras una caja para tus cosas... a posteriori de ver cuántas cosas tienes.

¿Cómo se soluciona eso? Bueno, el CSS reciente tiene herramientas como Flexbox, que ayudan a distribuir mejor el espacio entre rudimentos. 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 internamente de una página web, sin que se vean borrosas al hacer teleobjetivo. 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 ocurrir el mouse o hacer clic.

Pero, aunque SVG sea tan versátil, usarlo en combinación con HTML y CSS puede volverse un lío por varias razones:

• No 'palabra 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 difícil: Para hacer un dibujo, tienes que escribir instrucciones como . ¡Sí, eso es un triángulo! Pero no es precisamente entrañable a la presencia ni acomodaticio 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. Designar entre uno u otro puede reconocer de detalles técnicos molestos.
• Algunas cosas enseres solo están en SVG: Por ejemplo, si quieres detectar clics en formas con bordes irregulares (como una destino), SVG lo hace acomodaticio. HTML y CSS... no tanto.

La pesadilla del 'kitbashing web'

A lo derrochador de los primaveras, el incremento de interfaces web ha evolucionado a colchoneta de "parchar" las herramientas existentes. Esto ha cedido emplazamiento al engendro 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 noticiario, 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 debajo (como en WhatsApp):
  Parece poco central, ¿no? Pero ganar que la ventana del chat se quede debajo cuando llega un nuevo mensaje requiere escribir código personalizado cada vez. No hay una forma acomodaticio y ciberné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 emplazamiento, sabrás que a veces se conserva el color o el estilo… y a veces no. Hacer que eso funcione acertadamente en una app web requiere "trucos invisibles", como poner rudimentos 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 registro y cambian lo que se ve a medida que el sucesor se desplaza.
• Cajas que se vean acertadamente en diferentes tamaños de pantalla: Ajustar el diseño para que se vea acertadamente en un celular y en una computadora suena razonable, 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 acomodaticio.

Canvas: ¿una alternativa?

Frente a las limitaciones evidentes del DOM y CSS, algunos desarrolladores y estándares emergentes han puesto sus luceros en una alternativa radical: usar como plataforma principal para renderizar interfaces. La propuesta más extraordinario en esta semirrecta es HTML-in-Canvas, que plantea la idea de renderizar fragmentos de HTML internamente de un , permitiendo personalizar completamente su presentación visual.

Suena atractivo: ¿por qué no usar la potencia gráfica de Canvas para exceder las deficiencias del maniquí 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 aparecer, la API propuesta sigue estando atada al DOM, lo que significa que los rudimentos a renderizar deben seguir existiendo internamente del árbol de documentos para ser interpretables. Esto introduce una contradicción: si necesitas para librarte del DOM, ¿por qué seguir dependiendo de él para dibujar?

Por otra parte, para ganar interactividad, el sistema obliga a reimplementar el maniquí de interacción desde cero: trámite de eventos de mouse, teclas, estados de foco, accesibilidad... todo debe recrearse manualmente.

Se proxenetismo de un sistema donde el desarrollador asume el control tajante, pero igualmente la carga completa, como si estuviera desarrollando usando un motor de videojuegos.

Uno de los principales argumentos a valenza de usar canvas es que “al menos es programable”. Pero en ingenuidad, es un solicitud extremadamente constreñido:

• No tiene comunicación directo a fuentes del sistema ni a APIs nativas de layout de texto.
• No ofrece herramientas nativas para manejar accesibilidad, enclave o compatibilidad móvil.
• No permite reusar eficientemente estilos, posesiones ni interacciones predefinidas del navegador.

¿Y entonces, qué?

Posteriormente de todo lo que hemos trillado, queda claro que el maniquí contemporáneo de cómo se construyen las páginas web —usando HTML, CSS y el popular DOM— está roto, pero eso no significa que no haya alternativa. De hecho, según Wittens es totalmente posible mejorar todo esto… si nos atrevemos a cambiar las bases. Así que, ¿qué deberíamos hacer?

Aparecer 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 acomodaticio de desarrollar, surtir y ascender.

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 colchoneta (HTML+CSS+DOM) no da la talla.

Así que ¿por qué no rediseñar esas bases para que lo reciente ya venga incorporado?

• Que los cambios en la pantalla sean automáticos cuando cambie poco en el sistema.
• Que podamos mover rudimentos o cambiar estilos sin pelear con reglas raras de CSS.
• Que el código sea acomodaticio de descifrar, 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 convocatoria WebGPU. ¿Qué logra?

• Interfaces mucho más rápidas y suaves.
• Diseños con menos líneas de código.
• Posicionamiento de rudimentos que por fin tiene sentido (sí, centrar cosas es acomodaticio).
• Género visuales sin trucos raros ni dolores de inicio.

Y esto lo ha hecho una sola persona, con un sistema más claro y reciente que toda la maquinaria contemporáneo del navegador.

Además hay navegadores nuevos como Servo y Ladybird que están empezando de cero. No arrastran todo el peso de 30 primaveras de web, así que pueden tomar decisiones más inteligentes desde el principio.

Imagen | Marcos Merino mediante IA

En Genbeta | En esto consiste la trabajo de un desarrollador Full Stack: un perfil profesional todoterreno