1. Qué pasa cuando abres una web
Cada vez que escribes una dirección en el navegador se pone en marcha una conversación entre dos programas. Tu navegador, el cliente, pide un recurso; un ordenador remoto, el servidor, lo busca o lo genera y se lo devuelve. Esa conversación sigue las reglas del protocolo HTTP: una petición con un método (GET, POST…), una ruta y unas cabeceras, y una respuesta con un código de estado (200, 404, 500…) y un contenido.
Lo interesante empieza cuando la respuesta llega. El navegador no se limita a mostrar un texto: lee el HTML y construye con él un árbol de objetos, el DOM; lee el CSS y calcula el aspecto de cada elemento; descarga imágenes y scripts; y ejecuta el JavaScript, que puede cambiar cualquier cosa de la página mientras el usuario la usa. Este módulo trata precisamente de esa última parte: el código que se ejecuta en el navegador del usuario, no en el servidor.
Una web es como un restaurante
Cliente y servidor: quién hace qué
Una aplicación web moderna reparte el trabajo. El servidor guarda los datos, aplica las reglas de negocio y controla quién puede hacer qué. El cliente se encarga de la experiencia: mostrar la información, reaccionar al instante a los clics y validar un formulario antes de enviarlo. Saber dónde debe ir cada cosa es una de las decisiones más importantes de un desarrollador web.
| Código en el cliente (este módulo) | Código en el servidor (DWES) | |
|---|---|---|
| Dónde se ejecuta | En el navegador de cada usuario | En el servidor de la empresa |
| Lenguajes | JavaScript (y lo que compila a él: TypeScript, WebAssembly) | PHP, Java, Node.js, Python, C#… |
| Acceso a datos | Solo a lo que el servidor le envía | A la base de datos y los ficheros |
| Ventaja | Respuesta inmediata, sin recargar la página | El usuario no puede ver ni modificar el código |
| Límite | El usuario puede ver, parar o modificar el código | Cada acción requiere ir y volver por la red |
La regla de oro
2. JavaScript y las tecnologías del cliente
JavaScript nació en 1995 en Netscape, escrito por Brendan Eich en unos pocos días, para dar algo de vida a las páginas. Se estandarizó con el nombre de ECMAScript, y desde 2015 (la versión ES6 o ES2015) recibe una actualización cada año. Hoy es el único lenguaje que todos los navegadores entienden de forma nativa, y por eso cualquier tecnología del cliente acaba, de una forma u otra, convertida en JavaScript.
Pese al nombre, no tiene nada que ver con Java: es un lenguaje interpretado (en realidad compilado al vuelo por el navegador), de tipado dinámico (una variable puede guardar un número y luego un texto) y multiparadigma, porque permite programar con funciones, con objetos o con clases.
| Tecnología | Qué es | Cuándo se usa |
|---|---|---|
| JavaScript | El lenguaje nativo del navegador | Siempre: es la base de todo lo demás |
| TypeScript | JavaScript con tipos, creado por Microsoft; se compila a JavaScript | Proyectos medianos y grandes, donde los tipos evitan errores |
| WebAssembly | Formato binario que el navegador ejecuta casi a velocidad nativa | Cálculo intensivo: editores de vídeo, juegos, programas escritos en C++ o Rust |
| Librerías y frameworks | React, Vue, Angular, Svelte… escritos en JavaScript | Aplicaciones grandes con muchas pantallas y estado |
Qué puede hacer y qué no
El JavaScript del navegador vive en una caja de arena (sandbox). Puede modificar la página, responder a eventos, pedir datos a un servidor, guardar pequeñas cantidades de información, dibujar gráficos o reproducir sonido. Lo que no puede es leer los ficheros de tu disco sin tu permiso, abrir otros programas o pedir datos a cualquier web sin su consentimiento. Esta última restricción se llama política del mismo origen y la verás de nuevo cuando hablemos de AJAX y CORS.
3. Navegadores, motores y compatibilidad
Cada navegador incluye un motor de JavaScript que traduce tu código a instrucciones de la máquina: V8 en Chrome y Edge (y también en Node.js), SpiderMonkey en Firefox y JavaScriptCore en Safari. Todos siguen el mismo estándar, pero no incorporan las novedades el mismo día. Por eso, antes de usar una función reciente, conviene comprobar en caniuse.com o en la documentación de MDN qué navegadores la admiten.
Cuando necesitas que tu código funcione en navegadores antiguos tienes dos herramientas. Un transpilador como Babel reescribe la sintaxis moderna en una equivalente más antigua, y un polyfill añade a mano las funciones que al navegador le faltan. En la práctica, las herramientas de construcción como Vite se encargan de ambas cosas según los navegadores que indiques.
4. Cómo se integra JavaScript en una página
El código llega a la página a través de la etiqueta <script>. Puedes escribirlo dentro de ella, pero lo habitual es ponerlo en un fichero aparte: así el navegador puede guardarlo en caché y el HTML queda limpio.
1<!doctype html>
2<html lang="es">
3<head>
4 <meta charset="utf-8">
5 <title>Mi aplicación</title>
6 <script src="app.js" defer></script>
7</head>
8<body>
9 <h1 id="titulo">Hola</h1>
10 <noscript>Esta aplicación necesita JavaScript activado.</noscript>
11</body>
12</html>El detalle importante es cuándo se ejecuta el script. Por defecto, al encontrar un <script> el navegador deja de leer el HTML, descarga el fichero, lo ejecuta y solo después sigue. Si el script está en el <head> e intenta buscar el título, fallará: el título todavía no existe. Los atributos defer, async y type="module" cambian ese comportamiento:
| Forma | Descarga | Ejecución | Úsalo para |
|---|---|---|---|
| <script> | Bloquea la lectura del HTML | Inmediata | Casi nunca; solo al final del body |
| <script defer> | En paralelo | Cuando el HTML está leído, en orden | El código de tu aplicación |
| <script async> | En paralelo | En cuanto se descarga, sin orden | Scripts independientes: analítica, anuncios |
| <script type="module"> | En paralelo | Como defer, y permite import/export | Aplicaciones modernas organizadas en módulos |
Prueba el efecto en este editor: el script se ejecuta después del HTML y puede cambiarlo.
(sin mensajes)5. Las herramientas de trabajo
Para programar en el cliente no necesitas instalar gran cosa: un editor y un navegador. Pero hay herramientas que marcan la diferencia entre adivinar qué falla y verlo.
Las herramientas de desarrollo del navegador
Pulsando F12 se abren las DevTools, y conviene que se conviertan en tu segunda casa. En Elementos ves el DOM tal como está ahora (no como lo escribiste) y puedes editar estilos en directo. La Consola muestra los errores y los mensajes de console.log, y te deja ejecutar código sobre la página. En Fuentes puedes poner puntos de ruptura y avanzar línea a línea viendo el valor de cada variable. Y en Red ves cada petición que hace la página, con su tiempo, sus cabeceras y su respuesta.
- Editor: Visual Studio Code con extensiones como ESLint y Prettier.
- Node.js y npm: aunque el código se ejecute en el navegador, las herramientas de desarrollo se instalan y ejecutan con Node.
- Vite: crea el proyecto, lo sirve con recarga instantánea y lo empaqueta para producción.
- ESLint: detecta errores y malas prácticas mientras escribes.
- Git: control de versiones, imprescindible desde el primer día.
1npm create vite@latest mi-app -- --template vanilla
2cd mi-app
3npm install
4npm run dev # servidor de desarrollo con recarga automática
5npm run build # versión optimizada en la carpeta dist/6. Arquitecturas de aplicaciones web
No todas las webs reparten igual el trabajo entre cliente y servidor. Elegir bien la arquitectura depende de qué tipo de aplicación estés construyendo, y es una pregunta típica tanto en clase como en una entrevista.
| Arquitectura | Cómo funciona | Buena para |
|---|---|---|
| Multipágina (MPA) | El servidor genera cada página completa; cada clic carga una página nueva | Webs de contenido, tiendas, blogs; muy buen SEO |
| Una sola página (SPA) | Se carga una vez y JavaScript cambia la vista y pide datos en JSON | Aplicaciones muy interactivas: paneles, correo, editores |
| Renderizado en servidor + hidratación (SSR) | El servidor envía el HTML ya generado y luego JavaScript lo hace interactivo | Lo mejor de ambas: carga rápida y buena interacción |
| Sitio estático (SSG) | Las páginas se generan al construir el proyecto y se sirven como ficheros | Documentación, portfolios, apuntes como esta web |
| Aplicación web progresiva (PWA) | Una web que se instala, funciona sin conexión y envía notificaciones | Apps sencillas sin pasar por las tiendas |
Esta misma web es un ejemplo mixto: las páginas se generan como HTML al construir el proyecto (para que Google las lea bien) y después React toma el control para que los retos y el editor sean interactivos.
7. Ejercicios
¿Cliente o servidor?
Indica si cada tarea debe hacerse en el cliente, en el servidor o en ambos, y por qué: a) Comprobar que el email de un formulario tiene un formato correcto. b) Calcular el precio final de un pedido con los descuentos del cliente. c) Mostrar u ocultar un menú al pulsar un botón. d) Comprobar que el usuario tiene permiso para borrar un producto. e) Ordenar una tabla por una columna al hacer clic en su cabecera.
Investiga con las DevTools
Abre una web que uses a menudo, pulsa F12 y responde: ¿cuántas peticiones hace al cargar? ¿Cuánto pesan en total? ¿Cuántos ficheros JavaScript descarga y cuál es el más grande? Busca en la pestaña Red una petición que devuelva JSON y explica qué datos contiene. Por último, cambia desde Elementos el texto de un titular y recarga: ¿qué ocurre y por qué?
Elige la arquitectura
Propón una arquitectura (MPA, SPA, SSR, SSG o PWA) para cada proyecto y justifícala: 1. El blog de una academia que quiere aparecer bien en Google. 2. Un panel interno para gestionar pedidos, usado solo por empleados. 3. Una tienda online con miles de productos. 4. Una app de lista de la compra que debe funcionar en el supermercado sin cobertura.