La web actual frente a la web que merecemos

¿Recuerdas cuando desarrollar para la web era sencillo? Podías saberte de memoria las normas clave. Hoy, la spec de HTML supera los 18 MB de texto denso que muta sin parar. El modelo de "estándar vivo" implica actualizaciones constantes. Cada navegador soporta un subconjunto distinto. Todos terminamos parcheando rarezas innecesarias.

Da para pensar: ¿y si rediseñáramos la web desde cero?

El problema central: la complejidad como barrera

Lo que duele admitir: esa maraña de complejidad no es casual. Normas tan enredadas solo permiten a gigantes con presupuestos millonarios crear browsers. Esto ahoga la competencia, frena ideas frescas y deja que unos pocos dicten el futuro de la web por negocio, no por utilidad.

Míralo en términos de estrategia. Un estándar inflado, lleno de funciones oscuras y fallos de renderizado, obliga a:

• Equipos enormes de ingenieros para un nuevo browser.
• Pequeños proyectos fuera de juego.
• Los grandes controlando todo.
• La innovación en pausa.

Si ya dominas el mercado, eso no es un error. Es tu fortaleza.

¿Cómo sería una web más simple?

Piensa en una spec que quepa en un ZIP comprimido. Tan chica que la imprimes entera. Con versiones semánticas claras (1.2.3, nada de "estándar vivo") que no cambian una vez lanzadas. Coges la 1.2.0, te vas a una isla desierta y montas un browser perfecto solo con eso.

Gramática estricta en vez de caos tolerante

La filosofía actual de "corregir errores" complica la vida a quien parsea HTML. Los browsers aplican reglas locas para mostrar código roto, porque "la web lo pide". ¿Y si lo invertimos?

Una spec con gramática formal y sin ambigüedades. Las páginas valen o no valen. Sin trucos ni interpretaciones libres. Así, las normas serían precisas y fáciles de procesar por cualquiera.

Resultado genial: los devs pasarían a formatos amigables como Markdown o YAML, que generan markup válido. Las herramientas se simplifican. Todos ganan.

Versionado semántico como pacto firme

Los cambios semanales de los estándares vivos generan caos para devs que buscan estabilidad. El versionado semántico lo arregla:

• Parches: solo correcciones de texto, gramática intacta.
• Menores: novedades compatibles con lo anterior.
• Mayores: roturas controladas.

De golpe, codificas para 1.2.0 y sabes que va en browsers de 1.2.0 a 1.3.x, pero no en 1.1.x. Tomas decisiones reales. Planificas sin estrés.

Texto como prioridad absoluta

La fiebre por multimedia y scripts ha hinchado la web sin sentido. ¿Y si ponemos el texto y la estructura semántica en el centro?

El texto es ligero, traducible, accesible y rápido. Una página así:

• Se adapta a cualquier pantalla sin esfuerzo.
• Funciona con lectores de pantalla sin parches.
• Sigue legible si falla el CSS.
• Se comprime a tamaños ridículos.

No es retroceder. Es volver a lo esencial: compartir info entre personas.

El dilema de los scripts

Opinión polémica: meter scripting en la web fue un error.

Antes de saltar, escúchame. No digo que los programas interactivos sean malos. Digo que embeber un lenguaje completo en cada página creó un monstruo de seguridad y complejidad. ¿Código de cualquier sitio con acceso casi total al sistema? Suena loco.

¿Y si la interactividad dinámica usara sistemas declarativos limitados? ¿Apps complejas como programas aparte, no scripts en browser?

Por qué importa hoy

No es teoría abstracta. Golpea tu día a día:

Para registradores de domains y hosts: Una web simple trae más seguridad, cumplimiento claro y optimización fácil. En NameOcean, gastamos horas lidiando con rarezas de la plataforma web. Normas limpias recortan ese esfuerzo.

Para devs: Especs claras = menos bugs, ciclos rápidos, debug sencillo. Apuntas a versiones fijas sin perseguir browsers.

Para startups: Menos complejidad abre puertas. Más rivales, más ideas, mejores tools.

Para usuarios: Archivos chicos, cargas rápidas, accesibilidad nativa, seguridad por defecto.

La resistencia al control de estándares

Lo clave: los estándares cambian por dinámicas de poder, no solo por técnica. Si ves el bloat como muralla deliberada, entiendes por qué arreglar la web cuesta.

Cualquier reinvención debe jugar a la teoría de juegos: ¿cómo mantener normas abiertas y simples con incentivos millonarios para enredarlas?

La clave son límites duros: techos de tamaño de archivo, gobierno explícito, garantías de compatibilidad y custodia comunitaria. No es solo código. Es política.

Qué puedes hacer ya

No forkearás la web mañana (aunque hay proyectos intentándolo). Pero sí:

• Construye simple. Reduce JavaScript. Prioriza HTML semántico. Haz sitios que funcionen sin CSS.
• Apunta a versiones concretas de browsers. Documenta tus blancos de compatibilidad.
• Impulsa texto puro. Que tu sitio lea bien en texto plano. Usa Markdown para contenido.
• Cuestiona features de vendors que hinchan sin valor. Poder no es deber.
• Apoya estándares abiertos y alternativas. Browsers chicos, proyectos open-source y comunidades necesitan devs con principios, no solo cuota de mercado.

La pregunta de fondo

La web no tiene por qué ser tan complicada. Que lo sea dice mucho de cómo evolucionan estándares en un mundo capitalista. La solución técnica es simple; la política, un desafío.

Da igual si surge una "web bifurcada". Lo que cuenta es cuestionar. Nos mantiene alerta. La web que tenemos no es destino. Es elección. Y lo elegido se puede cambiar.

La próxima vez que luches con quirks de browser o copies features locas para competir, recuerda: no tiene que ser así.