Paradigmas del frontend: cómo elegir la arquitectura de su aplicación web

Antes de elegir una herramienta, elija un paradigma

Cuando un equipo discute «¿React o Angular?», con frecuencia está discutiendo la pregunta equivocada. La decisión que de verdad cuesta años de mantenimiento es otra: dónde y cuándo se arma la pantalla. ¿En el navegador del usuario? ¿En un servidor, en cada visita? ¿Una sola vez, al construir el sitio? ¿Es una aplicación instalada en la computadora o en el celular?

Cada respuesta es un paradigma, con ventajas reales y costos que no aparecen en la demostración. Este artículo es un mapa para un CTO o un director digital: qué es cada uno, cuándo conviene según el negocio, qué cuesta de verdad y cómo salir de uno sin reescribir todo. Es criterio, no receta.

1. Aplicación de una sola página (SPA)

MDN la define como una aplicación web que carga un solo documento y actualiza su contenido con JavaScript cuando hay que mostrar otra cosa. La ventaja: el usuario navega sin recargar páginas completas, con una experiencia más dinámica. Y MDN nombra también el costo: SEO, más esfuerzo para mantener el estado y la navegación, y para medir el rendimiento de forma significativa.

La documentación de React añade otro: las SPA son fáciles de empezar, pero pueden tener tiempos de carga inicial más lentos, y si cada componente pide sus datos después de pintarse se forman «cascadas» de peticiones, donde cada paso espera al anterior.

Dónde encaja: sistemas internos y paneles detrás de un inicio de sesión, y cualquier producto de interacción muy intensa donde llegar desde un buscador no es la prioridad: ahí la interacción pesa más que la primera carga.

2. Renderizado en el servidor (SSR)

El servidor arma el HTML en cada solicitud y lo envía ya listo. Angular lo resume así: el servidor responde con un documento renderizado, lo que da cargas más rápidas que el renderizado en el cliente y un HTML completo para los rastreadores. web.dev nombra el contrapeso: el primer byte puede tardar más, porque el servidor tiene que trabajar antes de responder.

Hay un matiz que conviene entender: la página «se ve» lista antes de que sea interactiva. web.dev lo describe como la hidratación: hasta que el JavaScript termina, la página parece lista, pero sus funciones interactivas aún no responden.

Dónde encaja: páginas públicas con contenido que cambia por visita o por usuario y que importa para buscadores.

3. Generación estática (SSG)

El HTML de cada URL se genera una vez, al construir el sitio. Según web.dev, eso da tiempos de respuesta consistentemente rápidos y permite servirlo desde una red de distribución de contenido (CDN); según Angular, el sitio puede desplegarse solo con una CDN o un servidor de archivos, sin mantener un servidor propio. El límite también está en web.dev: es inviable cuando hay millones de páginas únicas, y exige conocer las URL de antemano.

Dónde encaja: sitios corporativos, documentación, blogs, catálogos que cambian poco.

4. Híbridos e islas

La práctica real rara vez es «uno u otro». Angular describe el renderizado híbrido como la combinación de servidor, estático y cliente, ruta por ruta. Next.js lo expresa con componentes de servidor y de cliente: por omisión, páginas y layouts se arman en el servidor, y solo lo que necesita estado, eventos o APIs del navegador se marca como de cliente, con lo que se envía menos JavaScript.

// Ilustrativo, de la documentación de Next.js: la página se arma en el servidor
// y solo el botón (marcado con 'use client') es interactivo en el navegador.
<LikeButton likes={post.likes} />

La arquitectura de islas lleva la idea al extremo. La documentación de Astro la describe así: la mayor parte de la página es HTML estático y solo pequeñas «islas» reciben JavaScript, únicamente donde hace falta.

Dónde encaja: casi cualquier producto público con zonas interactivas: un catálogo estático con un cotizador, un sitio de contenido con un carrito.

5. Microfrontends

Dividen una aplicación grande en partes que equipos distintos construyen y liberan por separado. La documentación de single-spa los llama «un microservicio dentro del navegador», cada uno con su repositorio y su construcción; Module Federation, de webpack, permite que compilaciones separadas formen una sola aplicación y compartan dependencias.

Ahora, lo que esas páginas no dicen y nosotros sí: un microfrontend resuelve un problema de organización, no de tecnología (criterio nuestro; las fuentes citadas describen beneficios y no costos). Tiene sentido cuando varios equipos, con ritmos de liberación distintos, chocan en una misma base de código. Con un equipo pequeño agrega costuras que alguien tiene que mantener: versiones compartidas de librerías, consistencia visual entre partes y una experiencia que no se sienta cosida.

Y hay un costo que llega hasta el usuario: si cada equipo carga sus propias copias de las mismas librerías, el navegador descarga lo mismo varias veces. Las propias fuentes recomiendan compartir las instancias de las librerías grandes; que eso ocurra depende de que los equipos se coordinen, y se verifica con las señales de rendimiento que mencionamos más abajo.

6. Aplicaciones de escritorio y móviles multiplataforma

Cuando el navegador no alcanza, hay tres caminos de naturaleza distinta:

• Aplicación web instalable (PWA). Según MDN y web.dev, es una aplicación construida con tecnologías web que se instala, puede funcionar sin red, recibir notificaciones y usar la pantalla completa, con una sola base de código. MDN precisa que sigue apoyándose en un motor de navegador y que debe diseñarse con mejora progresiva, porque las APIs avanzadas no están en todos los navegadores.
• Escritorio. Electron empaqueta Chromium y Node.js para hacer aplicaciones de escritorio con JavaScript, HTML y CSS en Windows, macOS y Linux; su documentación aclara que el proceso que muestra la interfaz no tiene acceso directo a Node.js, por seguridad. Tauri toma otro camino: usa el motor web del propio sistema operativo y un núcleo en Rust, lo que su documentación señala como la razón de que sus aplicaciones sean muy pequeñas. Cada decisión tiene su costo: llevar su propio motor da un comportamiento más uniforme entre sistemas; depender del que trae cada uno ahorra tamaño, pero el motor puede diferir de un sistema a otro y el equipo debe resolver diferencias visuales y de comportamiento (criterio nuestro; en ambos casos hay que probar en cada sistema operativo que usted soporta). Cuándo el escritorio es de verdad la respuesta —impresoras, lectores, básculas, archivos locales— lo explicamos en ¿Su aplicación web ya no es suficiente?.
• Móvil multiplataforma. React Native crea, en tiempo de ejecución, las vistas nativas de Android y iOS a partir de componentes de React; por eso, según su documentación, las aplicaciones se ven y se sienten como cualquier otra. Es una tercera vía entre la web móvil y dos desarrollos nativos separados.

Cuándo no hace falta nada de esto

Si lo que necesita es un blog o una tienda estándar, una plataforma de contenido ya construida, renderizada en servidor de forma clásica, puede ser mejor negocio que armar una arquitectura a medida (criterio nuestro). Un paradigma se elige cuando hay un problema que lo justifica, no por novedad.

Cómo elegir según su negocio

Los costos que no salen en la demostración

• Costo de operar. El estático se sirve con una CDN; el renderizado en servidor exige ejecutar código en cada visita, en un servidor propio o de un proveedor, con su costo por uso, su escalado y su monitoreo. Que un proveedor administre la infraestructura cambia quién la opera, no que alguien deba vigilarla.
• Costo de talento. Cada paradigma pide habilidades distintas. Un híbrido bien hecho exige que el equipo entienda qué corre dónde; si no, aparecen errores que solo ocurren «en el servidor». Y cuenta el volumen: una herramienta con menos gente que la domine puede abaratar la infraestructura y encarecer la contratación (criterio nuestro).
• Costo de medición. Elegir un paradigma no mejora el rendimiento por sí solo. Google define sus tres señales de experiencia en el percentil 75 de las cargas, segmentadas entre móvil y escritorio: se miden con usuarios reales, antes y después de cada decisión.
• Costo de seguridad. Mover lógica al servidor protege secretos, pero un servidor expuesto también se defiende; mover lógica al cliente la hace pública (lo detallamos en Qué debe tener un frontend profesional).
• Costo de salida. El más olvidado: cuánto cuesta cambiar de idea. Un paradigma que obliga a reescribir para cambiar es una decisión cara aunque hoy parezca barata.

Migrar sin reescribir todo

Reescribir de cero es la opción que más cuesta y la que más tarda en dar resultados. La alternativa que recomendamos como criterio es migrar por rutas, empezando por las que más pesan para el negocio. Las fuentes lo hacen posible: Next.js afirma que una SPA existente puede migrar sin reescribirse por completo, que puede comenzar como sitio estático o incluso como SPA estricta y añadir funciones de servidor progresivamente, y ofrece guías de migración incremental desde otros entornos. La documentación de React señala que un framework cubre desde el inicio lo que una aplicación solo cliente resuelve a mano, como evitar cascadas de peticiones.

Tres preguntas ordenan una migración:

1. ¿Qué pantalla le cuesta más hoy? Cargas lentas en la que genera ingresos, o una página pública que no se encuentra. Empiece ahí, no por la más fácil.
2. ¿Qué se puede mover sin tocar la lógica de negocio? La presentación suele separarse de la lógica; si no, ese es el primer hallazgo.
3. ¿Cómo sabrá que mejoró? Defina antes la señal (rendimiento, conversión, errores) y mídala con datos reales.

Qué responder antes de decidir

Cinco preguntas que un comité puede contestar en una hora: ¿quién llega desde un buscador y quién no? ¿Qué datos no pueden vivir en el dispositivo? ¿Cuántos equipos tocan el mismo producto? ¿Qué canal usa su cliente más importante? Y, sobre todo, ¿cuánto le costaría cambiar de arquitectura dentro de tres años?

Cierre

La arquitectura correcta no es la más moderna: es la que su negocio puede operar, medir y cambiar. En Hábil ayudamos a elegirla con un criterio compartido y a construir el camino de migración que su equipo pueda sostener.