El día que olvidamos cómo funciona el navegador

Imagina que quieres publicar en internet una frase sencilla: «Abrimos de lunes a viernes, de nueve a dos». A finales de los noventa aquello se resolvía con un archivo de texto, cuatro etiquetas y un FTP que tardaba lo suyo pero funcionaba. Hoy, para ese mismo cometido, lo normal es inicializar un proyecto, instalar un framework, configurar un empaquetador, añadir TypeScript «porque es lo profesional», montar un servidor que renderice en el lado del servidor lo que luego se volverá a renderizar en el lado del cliente y, finalmente, desplegarlo todo en una plataforma que te cobra por cada vez que alguien lee que abres de nueve a dos.

El resultado es el mismo párrafo. Exactamente el mismo. Pero ahora viene acompañado de varios cientos de kilobytes de JavaScript, una carpeta node_modules que pesa más que la discografía completa de Alaska y un fichero de configuración que nadie en el equipo se atreve a tocar porque la persona que lo escribió se fue a otra empresa hace dos años.

En algún momento del camino, la industria del desarrollo web decidió que lo sencillo era sospechoso. Y en ese mismo momento, sin que nadie levantara la mano para protestar, olvidamos cómo funciona el navegador.

El navegador solo habla tres idiomas

Conviene recordar algo que parece obvio pero que se ha convertido en un secreto de familia: el navegador no entiende React, ni Vue, ni Svelte, ni JSX, ni TypeScript, ni Sass, ni ninguno de los inventos con nombre de startup que aparecen cada trimestre. El navegador entiende HTML, CSS y JavaScript. Punto. Todo lo demás es una traducción, y toda traducción tiene un coste.

Esto no es una opinión, es arquitectura. Cuando escribes un componente en cualquier framework moderno, ese código tiene que pasar por una cadena de montaje que lo convierta en algo que el navegador sea capaz de leer. Es como escribir una carta en esperanto, pasarla por tres traductores automáticos y entregarla al destinatario, que en realidad hablaba castellano desde el principio. La carta llega, sí, pero llega tarde, más gorda y con alguna frase rara que nadie sabe de dónde ha salido.

Lo fascinante es que hemos normalizado tanto esa cadena de traducción que muchos desarrolladores jóvenes, brillantes y bien pagados, no saben escribir una página web sin ella. Saben hacer un useEffect con los ojos cerrados, pero dudan si un <button> dentro de un <form> envía el formulario por defecto. Es como conocer al dedillo el menú de un restaurante de fusión y no saber freír un huevo.

Anatomía de un hola mundo en 2026

Hagamos el ejercicio con un poco de crueldad. Para mostrar un texto estático en pantalla con el stack que se considera estándar, el recorrido suele ser algo así: un gestor de paquetes descarga cientos de dependencias, muchas de las cuales solo existen para que otras dependencias funcionen. Un compilador transforma tu TypeScript en JavaScript. Un transpilador convierte ese JavaScript moderno en otro JavaScript algo menos moderno, por si alguien sigue usando un navegador de la época de la Expo de Sevilla. Un empaquetador junta todos los trozos, los trocea de nuevo con criterios que solo él comprende y los minifica hasta dejarlos ilegibles.

Después llega el servidor, que ejecuta todo ese JavaScript para generar el HTML que, con un poco de sentido común, podrías haber escrito tú directamente. Ese HTML viaja al navegador junto con el JavaScript necesario para volver a generarlo, y entonces ocurre el milagro que la industria ha bautizado con un nombre de crema facial: la hidratación.

Todo esto, recordemos, para decir que abres de lunes a viernes. Si el texto cambia dos veces al año, cuando llegan las vacaciones de verano, la desproporción entre el problema y la solución es tan grande que resulta casi poética.

Hidratar lo que nunca estuvo seco

La hidratación merece su propio apartado porque es probablemente el concepto más involuntariamente cómico del desarrollo web contemporáneo. La idea es la siguiente: el servidor te envía una página ya construida, perfectamente visible y legible. Pero esa página está «seca», porque el framework todavía no ha tomado el control de ella. Así que el navegador descarga el JavaScript, lo ejecuta, reconstruye mentalmente toda la página que ya tenía delante, compara ambas versiones y, si coinciden, le enchufa los eventos. Si no coinciden, te suelta un error en consola que ningún ser humano ha conseguido descifrar a la primera.

Es el equivalente a que te entreguen un piso amueblado y, antes de dejarte sentar en el sofá, un señor tenga que volver a montar todos los muebles en su cabeza para comprobar que son los mismos que ya estaban allí. Mientras tanto, tú ves el sofá, intentas sentarte y no puedes. Ese lapso en el que la web parece lista pero no responde a los clics tiene incluso métricas propias, porque la industria, en lugar de dejar de hacerlo, prefirió medirlo.

Para arreglar los problemas de la hidratación han surgido la hidratación parcial, la hidratación progresiva, las islas, la resumabilidad y los componentes de servidor. Todas son soluciones ingeniosas, y detrás de todas hay gente muy lista. Pero cuesta no ver la ironía: llevamos años inventando formas cada vez más sofisticadas de enviar menos JavaScript al navegador, que es exactamente lo que hacíamos antes de empezar a enviarle tanto.

La experiencia del desarrollador contra la del usuario

Cuando uno plantea todo esto en voz alta, la respuesta suele girar en torno a dos palabras mágicas: escalabilidad y experiencia de desarrollador. La primera es razonable cuando hablas de una aplicación con cientos de pantallas, estado compartido y equipos de cincuenta personas tocando el mismo código. La segunda es más resbaladiza, porque suele significar que el desarrollador está cómodo, y la comodidad del desarrollador no siempre coincide con la del usuario.

El usuario no ve tu arquitectura de componentes, ni tu tipado estricto, ni tu recarga en caliente. El usuario ve una pantalla en blanco durante tres segundos en un móvil de gama media, en un tren que atraviesa un túnel, con la batería al quince por ciento. Cada kilobyte de JavaScript que decides enviar no se paga en tu flamante portátil de desarrollo, se paga en el dispositivo de otra persona, con el procesador de otra persona y los datos de otra persona.

Y luego está la accesibilidad, esa gran olvidada. Un <button> nativo es accesible por teclado, anunciable por lectores de pantalla y enfocable sin que tengas que hacer nada. Un <div> con un evento de clic, que es lo que muchos frameworks acaban generando cuando se usan con prisa, no es nada de eso hasta que alguien añade a mano todo lo que el navegador ya te regalaba. Hemos pasado años reinventando mal lo que el HTML hacía bien de serie.

El SEO también se da cuenta

Para quienes viven de que Google los encuentre, la hipercomplicación del front-end tiene una consecuencia directa. Los buscadores han mejorado mucho a la hora de ejecutar JavaScript, pero siguen prefiriendo, con toda la lógica del mundo, el contenido que llega servido en HTML desde la primera petición. Una página que necesita ejecutar un paquete de JavaScript para mostrar su texto es una página que le pone deberes al rastreador, y a nadie le gusta hacer deberes ajenos.

Las métricas de rendimiento que influyen en el posicionamiento, las famosas Core Web Vitals, miden en buena medida el daño que hacemos con nuestras propias decisiones técnicas. El tiempo que tarda en aparecer el contenido principal, lo mucho que se mueve la página mientras carga, lo que tarda en responder cuando la tocas. Una web hecha con HTML semántico, CSS razonable y un poco de JavaScript donde de verdad hace falta suele sacar notas espléndidas sin esfuerzo. Una web sobreingenierizada suele necesitar un consultor para arreglar lo que nadie tendría que haber roto.

View Source, la mejor escuela del mundo

Durante años existió una universidad gratuita, abierta las veinticuatro horas y con un catálogo infinito de asignaturas. Estaba escondida en el menú contextual de cualquier navegador y se llamaba «Ver código fuente». Veías una web que te gustaba, pulsabas Ctrl+U y ahí estaba todo: la estructura, los estilos, los trucos, las chapuzas, los comentarios que el autor había olvidado borrar. Aprendías copiando, rompiendo y volviendo a copiar. Toda una generación de desarrolladores web se formó así, sin bootcamps ni certificaciones, a base de curiosidad y de fisgar en casa ajena.

Hoy, si haces ese mismo gesto en muchas webs modernas, lo que encuentras es un <div id="root"></div> solitario, como un piso piloto sin muebles, seguido de un churro de JavaScript minificado que parece escrito por un gato caminando sobre el teclado. No hay nada que aprender ahí, salvo quizá humildad. La web, que nació como el medio más transparente y didáctico jamás inventado, se ha ido volviendo opaca sin que casi nadie lo lamente.

Por eso reivindicar el «Ver código fuente» no es una pose nostálgica. Es reivindicar una forma de trabajar en la que el resultado final es legible, en la que lo que escribes se parece a lo que el navegador recibe, y en la que cualquiera con curiosidad puede entender cómo está hecho lo que está mirando. Una web que se puede leer es una web que se puede aprender, mantener y arreglar. Una web que solo se puede compilar depende para siempre de que la cadena de herramientas siga viva.

El navegador de hoy es un monstruo y lo tratamos como a un abuelo

Lo más absurdo de todo es que muchas de estas capas nacieron para suplir carencias que el navegador ya no tiene. Hace quince años tenía sentido tirar de librerías para casi todo, porque los navegadores eran torpes, incoherentes entre sí y bastante limitados. Hoy la situación es radicalmente distinta y seguimos comportándonos como si no lo fuera.

El HTML actual trae ventanas modales nativas con <dialog>, desplegables con <details>, elementos emergentes con la API de popover y validación de formularios sin escribir una línea de script. El CSS moderno permite anidar selectores, consultar el tamaño del contenedor en lugar del de la pantalla, seleccionar un elemento padre en función de sus hijos con :has() o animar transiciones entre páginas. El JavaScript nativo tiene módulos, fetch, componentes web y un rendimiento que habría parecido ciencia ficción cuando se inventó jQuery. Buena parte de lo que antes exigía una dependencia hoy cabe en unas pocas líneas de código que el navegador ejecuta sin intermediarios.

Tratamos al navegador como a un abuelo al que hay que cortarle la comida en trocitos, cuando en realidad es un atleta en plena forma que podría comerse el filete entero sin despeinarse. Le hemos puesto tantos andadores que ya no recordamos que sabe correr.

No es nostalgia, es criterio

Sería injusto y un poco cascarrabias terminar sugiriendo que todo lo moderno es malo. Los frameworks existen por buenas razones y hay proyectos en los que son la herramienta adecuada: aplicaciones complejas con mucho estado, interfaces que se parecen más a un programa de escritorio que a un documento, equipos grandes que necesitan convenciones compartidas. Nadie en su sano juicio construiría un editor de vídeo en el navegador a base de HTML plano y buena voluntad. Incluso los generadores de sitios estáticos, que usan un proceso de compilación, tienen la decencia de escupir al final HTML limpio y dejar al navegador en paz.

El problema no son las herramientas, sino haberlas convertido en el punto de partida obligatorio para cualquier cosa. Usar el mismo stack para el panel de control de un banco y para la web de una panadería no es profesionalidad, es inercia. La pregunta que deberíamos hacernos antes de abrir la terminal no es «¿con qué framework lo hago?», sino «¿necesito realmente algo más que lo que el navegador ya sabe hacer?». Y la respuesta, con más frecuencia de lo que la industria está dispuesta a admitir, es que no.

Volver a lo básico como acto de rebeldía

Quizá la próxima revolución del front-end no consista en inventar otra capa, sino en quitar unas cuantas. Escribir HTML semántico que se entienda solo. Usar CSS para lo que CSS sabe hacer, que ya es casi todo. Añadir JavaScript como quien añade sal, con mesura y solo donde mejora el plato. Publicar páginas que, al pulsar Ctrl+U, enseñen algo a quien mira en lugar de esconderlo.

El navegador lleva treinta años esperando pacientemente a que nos acordemos de él. Sigue ahí, cada vez más capaz, hablando los mismos tres idiomas de siempre. Solo tenemos que volver a dirigirnos a él directamente, sin traductores, y comprobar que, para decir que abrimos de lunes a viernes de nueve a dos, basta y sobra con un párrafo.