La arquitectura de una web

Una aplicación web está partida en dos mitades que corren en máquinas distintas. La mitad de cliente, o front-end, viaja por la red y se ejecuta dentro del navegador del opositor: es el HTML que describe el contenido, el CSS que lo presenta y el JavaScript que lo hace reaccionar. La mitad de servidor, o back-end, se ejecuta en una máquina que el usuario no controla: recibe peticiones, consulta la base de datos, decide qué puede ver cada usuario y devuelve una respuesta.

Entre las dos mitades solo circula HTTP. El navegador manda una petición con un método (GET para pedir, POST para enviar datos) y una dirección; el servidor devuelve una respuesta con un código de estado y un cuerpo, que puede ser una página HTML, una hoja de estilo, una imagen o un fragmento de JSON. Nada más pasa de un lado a otro: el servidor no ve las variables de JavaScript del navegador y el navegador no ve el código del servidor.

Todo lo que se ejecuta en el cliente es público y modificable por el usuario. Todo lo que decide algo importante tiene que ejecutarse en el servidor.

Un navegador no es un programa monolítico. Dentro lleva dos piezas que se preguntan mucho porque se confunden. El motor de renderizado toma el HTML, el CSS y los recursos multimedia y decide qué píxel va en cada sitio: es el que pinta la página. El motor de JavaScript es el intérprete que ejecuta el código de la página: analiza el JavaScript, lo compila internamente y lo corre.

La tabla explica por qué tres navegadores distintos se comportan igual: Chrome, Edge y Opera comparten las dos piezas porque los tres están construidos sobre Chromium. Los que de verdad aportan diversidad son Firefox y Safari. Quantum, que a veces aparece citado como si fuese un motor aparte, fue el proyecto de modernización del propio Gecko, no su sustituto.

Al motor de JavaScript le llega el código ya traducido a JavaScript, sea cual sea el lenguaje en que lo escribiera el desarrollador. Node.js es ese mismo motor V8 sacado del navegador y empaquetado con librerías para funcionar como entorno de ejecución en el servidor: la comparación habitual es que Node es a JavaScript lo que la JRE es a Java, y V8 lo que la máquina virtual es dentro de la JRE.

El navegador ejecuta código que el usuario puede leer entero, modificar con las herramientas de desarrollo o directamente saltarse enviando la petición HTTP a mano. Por eso la validación que se hace en el cliente sirve para dar una respuesta inmediata y ahorrar viajes al servidor, pero no protege de nada: es comodidad, no seguridad.

La regla práctica es que toda comprobación que importe se repite en el servidor. Si un formulario de matrícula limita el campo de un curso a los cursos publicados, el servidor tiene que volver a comprobar que ese curso existe y que ese alumno puede matricularse, aunque el formulario ya lo hubiera comprobado en el navegador.

• Validación de cliente: mejora la experiencia y filtra errores tontos. Se puede desactivar.
• Validación de servidor: es la única que decide. Nunca es opcional.
• Autorización: siempre en el servidor. Ocultar un botón en el HTML no impide llamar a la operación.
• Secretos: nunca en el cliente. Una clave escrita en JavaScript es una clave publicada.

Dos mecanismos del propio navegador acotan el daño. La política del mismo origen impide que el JavaScript de una página lea datos de otro origen distinto (otro esquema, dominio o puerto), que es lo que evita que una web cualquiera lea el correo abierto en otra pestaña. Y el XSS es el ataque que consiste en colar código JavaScript ajeno dentro de una página de confianza: se evita escapando todo lo que venga del usuario antes de pintarlo.

Si el examen pregunta dónde se valida, la respuesta es en los dos sitios, pero la que cuenta es la del servidor.

El tipo MIME es la etiqueta con la que el servidor le dice al navegador qué clase de contenido le está mandando. Se escribe como tipo barra subtipo, y el navegador la usa para decidir si pinta la respuesta, si la interpreta como código o si la descarga. Sin ella el navegador tendría que adivinar por la extensión del fichero, que es exactamente lo que se quiso evitar.

CGI, de Common Gateway Interface, fue la primera forma de generar páginas dinámicas. El servidor web lanzaba un programa externo, escrito en cualquier lenguaje, le pasaba los datos de la petición en variables de entorno y devolvía al navegador lo que ese programa imprimiera. Era lento, porque arrancaba un proceso nuevo por cada petición, pero es la antesala directa de todo lo que vino después: los módulos incrustados en el servidor, FastCGI y los entornos de ejecución modernos.

JavaScript nació en Netscape con el nombre de Mocha, se rebautizó como LiveScript y acabó llamándose JavaScript por razones comerciales, no técnicas: no tiene parentesco con Java. Para que dejara de depender de un fabricante se llevó a normalizar a ECMA, y desde entonces el lenguaje se llama formalmente ECMAScript.

La norma es la ECMA-262. La versión que marcó el salto moderno del lenguaje es la sexta, que se conoce indistintamente como ES6 o ES2015 porque a partir de ahí las ediciones pasaron a nombrarse por año. Es la que trajo let y const, las clases, las funciones flecha, las promesas y los módulos.

ECMA-262 es JavaScript y ECMA-404 es JSON. Es el par de números que más se pregunta, y se confunden con facilidad porque JSON nació dentro de JavaScript.

El navegador solo entiende JavaScript, HTML y CSS. Como esos tres lenguajes se quedan cortos para proyectos grandes, se escribe en lenguajes más ricos y se traducen antes de publicar. A esa traducción se le llama transpilación: no se genera código máquina ni bytecode, sino código fuente de otro lenguaje del mismo nivel. De ahí el nombre alternativo source to source.

Conviene no confundir transpilar con compilar. Un compilador clásico traduce a código objeto ilegible para una persona, como cuando javac convierte un fichero .java en un .class. Un transpilador produce código fuente que se sigue leyendo: TypeScript entra y sale JavaScript.

Sobre esa base se apoyan los frameworks de front-end, que siguen el patrón modelo-vista-modelo de vista (MVVM): separan lo que se pinta de la lógica de negocio y mantienen sincronizados el estado y la interfaz. Los tres nombres de examen son Angular, de Google, React, de Meta, y Vue.js; Ember.js aparece como cuarto habitual.

Un proyecto de front-end moderno no se edita y se sube: se construye. Alrededor de Node.js hay una cadena de herramientas que resuelve cuatro problemas distintos, y el examen suele preguntar cuál resuelve cuál.

Los empaquetadores son los que dejaron sin sitio a los automatizadores de tareas: hacen ellos mismos la transpilación, la minificación y la resolución de dependencias, y entregan un puñado de ficheros listos para servir. El conjunto de npm, un empaquetador y una CLI equivale en el mundo JavaScript a lo que Maven hace en Java.

# Arranque típico del panel de un curso con la CLI de Angular
npm install -g @angular/cli      # instala la CLI (barra normal, no invertida)
ng new panel-alumno              # genera el esqueleto del proyecto
cd panel-alumno
npm install                      # descarga las dependencias en node_modules
ng serve                         # levanta el servidor de desarrollo

# Con yarn los comandos equivalentes son:
# yarn init, yarn install, yarn add <paquete>, yarn upgrade

npm usa init, install y update; yarn usa init, install, add y upgrade. Los dos leen el mismo package.json y dejan las librerías en node_modules.