Contenido del curso
Crea tu primer app con SSR
- 6

Proyecto Helix Eye: de CSR a SSR
14:50 min - 7

Webpack para servidor Node con TypeScript
16:19 min - 8

Servidor Express con TypeScript desde cero
08:48 min - 9

Función template HTML dinámica en TypeScript
06:52 min - 10

renderToString y StaticRouter en el servidor
10:35 min - 11

Hidratación de React con hydrateRoot en SSR
11:38 min - 12

Prefetching de API en el servidor con Axios
13:00 min - 13

Inyectando initialProps del servidor a React
09:19 min - 14

Cómo inyectar estilos de SSR sin flickering
09:56 min
Bonus
Problemas reales de las SPAs con JavaScript
Resumen
Las Single Page Applications (SPA) son aplicaciones web que cargan todo el HTML, CSS y JavaScript desde un inicio para ofrecer una navegación fluida sin recargas. Si trabajas con React, Vue o Svelte, ya estás usando esta arquitectura, y entender sus límites te ayuda a decidir cuándo conviene migrar a otra estrategia.
¿Qué es una Single Page Application y cómo funciona?
Una SPA es una aplicación web de una sola página que expone HTML, CSS y JavaScript cargados desde el primer request. La magia ocurre gracias a un bundler como Webpack, Parcel o Vite, que toma todos tus archivos (por ejemplo, JSX) y los transforma en un único punto de entrada, normalmente un archivo llamado bundle.js.
Ese archivo se expone a internet y se descarga de inicio en el navegador. El resultado es una experiencia de navegación superfluida, sin los molestos reloadings que caracterizaban a la web antigua [0:18].
¿Qué hace un bundler en una SPA? Toma todos tus archivos fuente y los empaqueta en un solo archivo JavaScript que el navegador descarga una sola vez. Así no necesitas pedir recursos extra al servidor por cada ruta.
¿Cuál es la diferencia entre Multi Page Application y SPA?
Antes de React, lo común era construir sitios con múltiples archivos HTML: un index.html, un info.html, un store.html. Estos vivían en un servidor (por ejemplo, Apache) cuya única tarea era exponerlos al mundo [1:30].
Cuando hacías clic en una etiqueta de ancla <a>, el navegador iba al servidor a pedir el nuevo archivo. Eso provocaba un reloading en cada navegación. A esa arquitectura se le conoce como Multi Page Application (MPA).
¿Qué problemas tenía la Multi Page Application?
Las MPAs permitían modularizar la aplicación porque cada vista cargaba solo los archivos que necesitaba. Pero arrastraban varios dolores de cabeza:
- Recarga completa de la página en cada navegación.
- Código duplicado entre archivos HTML, CSS y JavaScript.
- Conflictos de estilos por el caché que el navegador guardaba en memoria.
- Problemas de lógica al reutilizar JavaScript entre vistas.
¿Cómo resuelve esto una SPA con React Router?
En lugar de tener varios HTML repartidos en el servidor, una SPA cuenta con un solo HTML, un JavaScript y un CSS que ejecutan toda la aplicación. Cuando combinas React DOM con React Router DOM, generas un router virtual dentro del navegador [3:45].
Ya no pides un nuevo archivo al servidor cada vez que cambias de ruta. Todo está contenido en el bundle inicial, y el router virtual se encarga de mostrar la vista correcta cuando navegas entre /, /info o /store.
¿Por qué las SPAs se vuelven pesadas y qué problemas generan?
Aquí viene lo interesante: el tamaño es crítico en una SPA. Si tu app tiene tres rutas, el bundle puede pesar unos cuantos kilobytes y todo va bien. Pero imagina una SPA del tamaño de Platzi, con miles de rutas dinámicas y estáticas. El bundle pasa de kilobytes a megabytes, y si la aplicación crece sin control, puede llegar al orden de gigabytes [5:20].
Este tipo de aplicaciones tienden a convertirse en monolitos pesados. Cuando llegues a ese punto, conviene cortarlas en piezas más pequeñas.
¿Por qué una SPA grande tarda en cargar? Porque el navegador descarga todo el HTML, CSS y JavaScript de golpe en la primera visita. Si el bundle pesa megabytes, la carga inicial se vuelve lenta.
¿Qué problemas tiene una SPA con SEO e indexación?
Cuando el servidor envía el primer HTML de una SPA, normalmente no incluye el DOM completo. El DOM se construye una vez que el JavaScript se ejecuta en el navegador, lo que dificulta que los motores de búsqueda indexen el contenido correctamente.
A esto se suman otros límites importantes:
- Alta dependencia de JavaScript: si el navegador no ejecuta JS, no se renderiza ni un solo
div. - Mayor consumo de recursos en el navegador, porque la tarea del router se delega al cliente y usa memoria local.
- Riesgos de seguridad asociados a las dependencias del proyecto, agravados por la fuerte dependencia de JavaScript.
¿Una SPA funciona sin JavaScript? No. Si el navegador no ejecuta JavaScript, la aplicación no se renderiza porque el DOM se genera del lado del cliente.
¿Qué habilidades técnicas se trabajan al entender las SPAs?
Dominar este tema implica varias competencias prácticas que vale la pena reconocer:
- Comprender el rol de un bundler como Webpack, Parcel o Vite en la generación de un único
bundle.js[0:38]. - Diferenciar entre routing del lado del servidor y routing virtual del lado del cliente con React Router DOM [3:45].
- Identificar cuándo una arquitectura SPA deja de escalar por tamaño y cuándo conviene migrar a otra estrategia [5:20].
- Reconocer las implicaciones de SEO, rendimiento y seguridad que trae una alta dependencia de JavaScript [6:30].
Si ya construiste una SPA o estás por hacerlo, cuéntame en los comentarios qué tan grande es tu bundle hoy y cómo estás manejando el crecimiento de tus rutas.