Arquitectura · 19 de octubre de 2026 · Daniel Murillo

Decisión de arquitectura frontend: React, Angular, Vue y el rendimiento

Cómo elegir framework, renderizado y estrategia mobile sin confundir popularidad con encaje. Una guía por escenario para 2026.

No existe un framework frontend universalmente superior. La decisión correcta depende del producto, el equipo, la experiencia que necesita ofrecer, la estrategia de publicación, los requisitos de SEO, la necesidad de mobile y el coste de mantenerlo durante años. La tecnología importa, pero importa más elegir una arquitectura que encaje con el problema y ejecutarla bien.

1. Antes de comparar frameworks: separar las decisiones

En muchas discusiones se comparan React, Angular, Vue, Astro o Next.js como si fueran alternativas exactamente equivalentes. No lo son. Hay varias capas:

Biblioteca o framework de UI: React, Angular y Vue.
Framework de aplicación y renderizado: Next.js, Nuxt, Angular SSR, Astro y Qwik City.
Estrategia de renderizado: CSR, SSR, generación estática (SSG), regeneración/revalidación y renderizado híbrido.
Herramientas de construcción y entrega: Vite, compiladores, bundlers, CDN, adaptadores de despliegue y pipelines CI/CD.
Estrategia mobile: React Native/Expo, Ionic con Capacitor, u otras soluciones nativas o multiplataforma.

Por ejemplo, React no es Next.js, aunque Next.js sea una de las opciones más conocidas para construir aplicaciones React con routing, renderizado en servidor y otras capacidades. Del mismo modo, Vue no es Nuxt, y Angular Universal es el nombre histórico con el que muchos conocen el SSR de Angular; en proyectos actuales conviene consultar la guía vigente de Angular SSR y usar la integración soportada por la versión elegida.

Esta distinción evita comparar una biblioteca con un framework completo o atribuirle al lenguaje una ventaja que en realidad proviene del renderizado, el tamaño del bundle, el caché o la infraestructura.

2. Las preguntas que deberían decidir la arquitectura

Antes de elegir tecnología, conviene responder:

¿Qué estamos construyendo? Una landing, un blog, un e-commerce, un dashboard, una SPA interna o una plataforma empresarial son problemas diferentes.
¿Qué tan importante es el SEO? Para páginas públicas que deben posicionar, el HTML inicial, los metadatos, la indexabilidad y el rendimiento importan mucho.
¿Cuánta interactividad real necesita el usuario? Una página con texto, imágenes y un formulario no necesita necesariamente enviar un runtime grande de JavaScript al navegador.
¿Habrá aplicación mobile? ¿Se necesita compartir lógica, componentes, diseño o incluso experiencia entre web y móvil?
¿Qué tamaño tendrá el producto? ¿Cuántas rutas, dominios funcionales, equipos, permisos, integraciones y ciclos de vida se esperan?
¿Quién lo mantendrá? La experiencia del equipo y su capacidad para contratar, revisar código, probar y operar la aplicación son criterios arquitectónicos, no detalles secundarios.
¿Cómo se publicará? ¿Hosting estático detrás de una CDN, servidor Node, funciones serverless, contenedores o plataforma gestionada?
¿Qué significa «rápido»? Puede significar carga inicial, interactividad, navegación posterior, tiempo de compilación, velocidad de desarrollo o tiempo de respuesta del servidor. Son métricas distintas.

Una buena decisión documenta las prioridades y sus compromisos, en vez de declarar que un framework es «el más rápido» sin especificar qué se midió.

3. CSR, SSR, SSG e híbrido: elegir el renderizado por ruta

El renderizado no es una decisión binaria de «usar SSR o no». Un mismo producto puede usar distintas estrategias según la ruta.

Estrategia	Cómo funciona	Ventajas	Costes y límites	Casos típicos
CSR (Client-Side Rendering)	El navegador carga JavaScript y construye la UI.	Interacciones ricas; despliegue estático posible; modelo natural para herramientas autenticadas.	El contenido puede tardar más en aparecer si depende mucho del bundle o de APIs; SEO y previews requieren más cuidado.	Dashboards, herramientas internas, aplicaciones muy interactivas.
SSR (Server-Side Rendering)	El servidor genera HTML por petición y el cliente puede hidratarlo.	Contenido inicial visible; útil para páginas personalizadas o datos actuales; favorece previews y rastreo.	Coste y latencia de servidor; complejidad de caché; hidratación; cuidado con estado por usuario y APIs exclusivas del navegador.	Catálogos, páginas personalizadas, portales públicos dinámicos.
SSG (Static Site Generation)	El HTML se genera en build.	Muy rápido y barato de servir desde CDN; alta disponibilidad y caché sencilla.	Cambios de contenido pueden requerir rebuild o revalidación; no es ideal para contenido altamente personalizado sin otra capa.	Landing pages, documentación, blogs y páginas de marketing.
Híbrido / ISR / revalidación	Se combinan páginas estáticas, SSR y actualización de contenido.	Ajusta coste, frescura y rendimiento según cada ruta.	Más decisiones sobre caché, invalidación y consistencia.	E-commerce, sitios de contenido grandes y productos con zonas públicas y privadas.
Islas / hidratación parcial	La mayor parte es HTML; solo componentes concretos reciben JavaScript.	Reduce JavaScript enviado cuando la página es principalmente contenido.	Hay que definir límites entre contenido estático e interactividad; no sustituye automáticamente una aplicación compleja.	Marketing, blogs, documentación y páginas de producto.
Resumability	La aplicación retoma en el cliente el estado y trabajo preparado en servidor, evitando la hidratación tradicional completa.	Puede reducir el trabajo inicial del navegador.	Modelo de programación y ecosistema distintos; hay que validar madurez y encaje del equipo.	Sitios y aplicaciones donde el coste de arranque cliente es crítico.

SSR no garantiza por sí solo una web rápida. Una página puede renderizarse en servidor y aun así cargar demasiados scripts, bloquear el hilo principal, servir imágenes enormes o tener un backend lento. A la inversa, una SPA bien construida puede sentirse excelente después de la primera carga, aunque no sea la opción ideal para una web cuyo contenido debe descubrirse desde buscadores.

Para sitios públicos, el objetivo debería ser entregar pronto el contenido útil, reducir JavaScript innecesario, cuidar el caché y medir los Core Web Vitals. Para una aplicación autenticada, el SEO quizá sea irrelevante y la prioridad puede estar en la navegación, el estado, la accesibilidad y la productividad del equipo.

4. React, Angular y Vue: comparación de alto nivel

Criterio	React	Angular	Vue
Naturaleza	Biblioteca de UI; necesita decisiones adicionales para completar la arquitectura.	Framework integral con convenciones y herramientas oficiales.	Framework progresivo con una curva de entrada amable y APIs oficiales para crecer.
Modelo de UI	Componentes funcionales, JSX y Hooks.	Componentes, templates, inyección de dependencias, servicios y APIs del framework.	Componentes de archivo único, templates y Composition API u Options API.
Reactividad	Estado y actualización declarados mediante Hooks y el modelo de React.	Signals, RxJS y mecanismos propios del framework, según el caso.	Reactividad fina con `ref`, `reactive`, `computed` y `watch`.
Arquitectura	Flexible; requiere acordar routing, datos, formularios, estado y convenciones.	Más prescriptiva; estructura y patrones comunes vienen definidos por el framework.	Flexible, con buenas herramientas oficiales; el equipo debe fijar convenciones al crecer.
TypeScript	Muy buen soporte; la calidad arquitectónica depende de cómo se diseñe el proyecto.	Integración central y profunda con TypeScript.	Muy buen soporte, especialmente con Composition API y `<script setup>`.
Ecosistema	Muy amplio, especialmente para web y mobile con React Native.	Ecosistema amplio y conjunto oficial integrado; menor necesidad de elegir piezas externas para funciones comunes.	Ecosistema sólido; Nuxt, Pinia, Vue Router y Vite cubren buena parte de las necesidades.
SSR / SSG	Normalmente se elige un framework como Next.js o una configuración específica.	SSR integrado en las herramientas modernas de Angular.	Nuxt es la opción habitual para SSR, SSG y aplicaciones Vue completas.
Mobile	React Native con Expo permite crear aplicaciones nativas usando React.	Ionic/Capacitor permite empaquetar una app web y acceder a capacidades nativas.	Ionic Vue con Capacitor permite un enfoque similar basado en Vue.
Riesgo principal	La libertad puede producir arquitecturas inconsistentes si no hay acuerdos.	La amplitud del framework puede sentirse pesada en proyectos pequeños o equipos sin experiencia.	Puede ser menos común en ciertos mercados o empresas; disponibilidad de talento debe evaluarse localmente.

No debe confundirse «más popular» con «mejor para este producto», ni «más integrado» con «siempre más productivo». React puede ser una excelente elección para un sistema empresarial cuando el equipo domina React y tiene acuerdos de arquitectura sólidos. Angular puede ser una gran elección cuando interesa que muchos equipos trabajen con patrones compartidos. Vue puede ser una solución de producción seria, no solamente una opción para proyectos pequeños.

4.1 React: flexibilidad y un ecosistema enorme

React es atractivo por su modelo de componentes, sus Hooks, el ecosistema y la posibilidad de compartir conocimientos con React Native. Su flexibilidad permite diseñar una arquitectura muy ajustada al producto.

Esa misma flexibilidad implica que el equipo debe tomar y mantener decisiones sobre:

Routing y estructura de rutas.
Obtención, caché e invalidación de datos.
Formularios y validación.
Estado local frente a estado compartido.
Autenticación, permisos y límites de módulos.
Estrategia SSR/SSG y despliegue.
Pruebas, convenciones, accesibilidad y observabilidad.

Para aplicaciones grandes, esto no es una desventaja inevitable: es un coste de gobernanza. Un equipo experimentado puede convertir esa libertad en una arquitectura excelente. Sin convenciones, en cambio, diferentes equipos pueden resolver el mismo problema de formas incompatibles.

En proyectos nuevos con requisitos de renderizado, routing y entrega integrados, Next.js es una alternativa relevante. Su modelo actual de App Router usa Server Components por defecto en páginas y layouts, y permite introducir Client Components cuando hacen falta estado, eventos o APIs del navegador. Esto puede reducir el JavaScript cliente, pero exige entender los límites entre servidor y cliente, caché, serialización y despliegue.

4.2 Angular: convenciones, integración y consistencia

Angular ofrece una solución más integrada: componentes, templates, inyección de dependencias, routing, formularios, HTTP, tooling, pruebas y una estructura reconocible. Eso puede reducir la cantidad de decisiones externas y facilitar que varios equipos compartan un mismo lenguaje arquitectónico.

Es especialmente competitivo en:

Aplicaciones empresariales con formularios complejos, roles y flujos de negocio.
Sistemas con muchos módulos y equipos.
Organizaciones que valoran convenciones, consistencia y una evolución controlada.
Proyectos TypeScript donde interesa que el framework cubra gran parte de las necesidades comunes.

El «Angular way» es una ventaja cuando el equipo lo adopta conscientemente. También puede convertirse en fricción si el proyecto es una página mínima, si el equipo no conoce Angular o si se introducen abstracciones sin necesidad.

Angular no elimina la necesidad de arquitectura. Sigue siendo importante definir límites de dominio, evitar componentes gigantes, aislar acceso a datos, diseñar contratos, probar reglas de negocio y evitar que todos los módulos dependan de todos.

Angular Signals moderniza el modelo de reactividad y permite seguir dependencias de forma granular. No son literalmente lo mismo que los Hooks de React: resuelven problemas relacionados, pero pertenecen a modelos distintos. En React, useState, useReducer, useEffect y los Hooks personalizados organizan estado y lógica reutilizable dentro del ciclo de renderizado. En Angular, signal, computed y effect modelan valores reactivos y sus dependencias. Angular también conserva RxJS para flujos asíncronos y operaciones complejas; Signals y RxJS pueden complementarse.

4.3 Vue: equilibrio entre ergonomía y capacidad

Vue ofrece una experiencia progresiva: se puede incorporar en una parte de una web o utilizar como base de una aplicación completa. Su Composition API facilita agrupar lógica relacionada y crear composables reutilizables; <script setup> y TypeScript ayudan a mantener componentes concisos.

Su reactividad se construye alrededor de APIs como:

ref() para valores reactivos.
reactive() para objetos reactivos.
computed() para valores derivados.
watch() / watchEffect() para observar cambios y reaccionar cuando corresponda.
Composables para encapsular y reutilizar lógica.

No necesita copiar exactamente los Hooks de React para ser comparable. Ambos permiten reutilizar lógica, pero la semántica de reactividad es distinta.

Para aplicaciones completas, Nuxt cubre SSR, generación estática y renderizado híbrido. Pinia es la opción recomendada actualmente para estado compartido en aplicaciones Vue nuevas; Vuex permanece en modo de mantenimiento y no es la recomendación por defecto para nuevos proyectos.

Vue puede funcionar perfectamente en aplicaciones grandes. La decisión de no usarlo en una empresa debería apoyarse en factores concretos —experiencia interna, contratación, integraciones, estándares y soporte—, no en la idea de que el framework no escala.

5. Una landing page: no siempre hace falta React, Angular o Vue

Una landing normalmente tiene contenido, imágenes, navegación, un formulario y quizá animaciones, analítica o una calculadora. Si la mayor parte de la página es contenido, convertirla en una SPA completa puede añadir complejidad y JavaScript innecesarios.

Opciones a considerar

Opción	Cuándo encaja	Observaciones
HTML semántico + CSS + JavaScript mínimo	Landing muy sencilla, estable y con pocas interacciones.	La solución más directa puede ser la mejor. No hace falta un framework por defecto.
Astro	Landing, marketing, blog, documentación, portfolio y sitios de contenido.	Renderiza HTML por defecto y permite añadir islas interactivas con React, Vue, Svelte, Preact y otras integraciones.
Qwik / Qwik City	El rendimiento de arranque y la cantidad de trabajo JavaScript en el cliente son criterios centrales.	Usa resumability en lugar de reproducir la hidratación tradicional completa. Tiene un modelo distinto que el equipo debe evaluar.
Next.js	Landing que comparte arquitectura con una aplicación React, necesita rutas dinámicas, contenido personalizado o un backend cercano.	Flexible y potente, pero no necesariamente la opción más simple para una página casi estática.
Nuxt	Landing o sitio de contenido dentro de un ecosistema Vue, con SSR/SSG.	Alternativa completa cuando Vue ya es la elección del equipo.
Angular SSR	La landing es parte de una plataforma Angular más amplia o la organización ya estandarizó Angular.	Tiene sentido por continuidad de plataforma; puede ser más de lo necesario para una landing independiente.

5.1 Astro: contenido primero, JavaScript cuando haga falta

Astro está diseñado para sitios orientados a contenido. Por defecto, sus componentes generan HTML y no envían JavaScript cliente innecesario. Cuando una sección requiere interactividad, se puede convertir en una isla y cargarla según su prioridad, por ejemplo al cargar la página o cuando se acerca al viewport.

Un enfoque razonable para una landing sería:

HTML semántico y contenido accesible.
CSS optimizado y fuentes/imágenes correctamente dimensionadas.
Formularios con validación y estados de error claros.
Carga diferida para componentes secundarios.
React, Vue o Preact solo para widgets que realmente lo necesitan.
Metadatos, canonical, Open Graph, sitemap y datos estructurados cuando apliquen.
Analítica y scripts de terceros limitados y medidos.

Astro no es «mejor que React» en todos los casos. Está optimizado para otro perfil de problema: contenido con interactividad localizada. Si la página se transforma en una aplicación con estado compartido complejo, navegación rica y numerosas interacciones, puede ser mejor usar un framework de aplicación o integrar una zona de aplicación de manera explícita.

5.2 Qwik: resumability y coste de arranque

Qwik busca evitar el coste de hidratación tradicional. En lugar de volver a ejecutar toda la lógica de la aplicación en el navegador para reconstruir el estado, la aplicación puede reanudarse a partir de información preparada durante el renderizado en servidor.

La idea es atractiva cuando importa mucho cuánto JavaScript debe descargarse y ejecutarse antes de responder a una interacción. Sin embargo, no se debe elegir solo por una promesa teórica de rendimiento. Hay que valorar el ecosistema, las integraciones necesarias, la experiencia del equipo, las herramientas de diagnóstico y el coste de mantenimiento. La mejor arquitectura no es la que gana una métrica aislada, sino la que alcanza los objetivos del producto con un coste total razonable.

Recomendación para una landing

Astro como primera opción si la página es principalmente contenido y SEO/rendimiento son prioritarios.
HTML/CSS/JS sin framework si el alcance es realmente pequeño y estable.
Next.js o Nuxt si la landing forma parte de una plataforma React/Vue o requiere renderizado dinámico más integrado.
Angular SSR si la continuidad con una plataforma Angular es una ventaja real.
Qwik como candidato que merece una prueba técnica cuando el rendimiento de arranque sea crítico y el equipo acepte evaluar un modelo menos convencional.

La recomendación debe validarse con una prueba representativa y métricas reales, no solo con demos.

6. Aplicaciones web pequeñas y medianas

Para una aplicación pequeña o mediana —por ejemplo, un portal de clientes, una agenda, un catálogo con autenticación o un panel administrativo— hay varias rutas válidas.

React + Vite o React + Next.js

Vite + React puede ser una opción simple para una SPA autenticada donde SEO no sea importante.
Next.js aporta routing, renderizado en servidor/estático, Server Components y mecanismos integrados de carga de datos y caché.
No todo componente debe ser de cliente en Next.js. Mantener en el servidor lo que no necesita interactividad reduce trabajo cliente, pero requiere comprender bien las fronteras servidor/cliente.

Vue + Vite o Vue + Nuxt

Vue + Vite es adecuado para una SPA o una aplicación web que no necesita SSR.
Nuxt encaja cuando se requiere SSR, SSG o una estrategia híbrida.
Para estado global, Pinia es la recomendación habitual para proyectos nuevos; Vuex no debería ser la opción automática por inercia.

Angular

Angular puede resolver aplicaciones medianas con una estructura consistente y tooling integrado.
SSR tiene sentido cuando existen páginas públicas indexables, se necesita HTML inicial o la experiencia del primer render lo justifica.
Para un panel interno autenticado, SSR puede no aportar suficiente valor para compensar la complejidad operativa.

Regla práctica: no añadas SSR solo porque el framework lo soporte. Añádelo cuando resuelva una necesidad observable: SEO, previews, primer render, personalización o requisitos de contenido. De lo contrario, una SPA estática bien construida puede ser más sencilla y barata de operar.

7. Aplicaciones grandes y empresariales

A medida que el sistema crece, la decisión deja de ser solamente sobre componentes. Importan los límites entre dominios, el ownership de módulos, la consistencia de los patrones, la automatización de pruebas, los cambios coordinados y la incorporación de nuevos desarrolladores.

7.1 Arquitectura por funcionalidades, no por tipo de archivo solamente

Una estructura que agrupa todo por tipo (components/, services/, models/) puede funcionar al inicio, pero en una aplicación grande puede hacer difícil entender qué pertenece a cada dominio. Conviene organizar principalmente por funcionalidad o dominio, y dentro de cada módulo separar UI, casos de uso, acceso a datos y modelos cuando el tamaño lo justifique.

Ejemplo conceptual:

src/
  app/
    core/                 # configuración global y servicios transversales
    shared/               # UI y utilidades verdaderamente reutilizables
    features/
      customers/
        components/
        pages/
        data-access/
        domain/
        customers.routes.ts
      billing/
        components/
        pages/
        data-access/
        domain/
        billing.routes.ts
  environments/

No es una estructura obligatoria ni una plantilla universal. Angular, React y Vue pueden organizarse por dominio. Lo importante es que las dependencias tengan una dirección clara, los módulos expongan contratos explícitos y «shared» no se convierta en un cajón donde termina todo.

7.2 Angular en escenarios empresariales

Angular destaca cuando el valor de sus convenciones supera el coste de adoptar el framework. Su integración de routing, formularios, inyección de dependencias, HTTP, CLI y TypeScript reduce la necesidad de seleccionar y ensamblar tantas piezas externas para necesidades comunes.

Eso no significa que Angular no use dependencias de terceros ni que las aplicaciones React necesariamente acumulen muchas. La diferencia está en cuánto deja el framework resuelto y cuántas decisiones debe estandarizar la organización.

Prácticas recomendadas:

Lazy loading por rutas y límites de dominio.
Componentes pequeños y con responsabilidades claras.
Servicios y adaptadores para aislar APIs.
Formularios reactivos cuando el flujo de validación lo requiera.
Signals para estado reactivo local/derivado; RxJS para flujos asíncronos cuando corresponda.
Evitar lógica de negocio compleja dentro de templates o componentes.
Pruebas unitarias, de integración y end-to-end según riesgo.
Mantener al día dependencias y migraciones del framework.

7.3 React en escenarios empresariales

React puede ser igual de válido para una aplicación grande, especialmente si la empresa ya tiene experiencia, componentes compartidos y tooling establecido. La condición es invertir en convenciones explícitas.

Hay que decidir y documentar, como mínimo:

Estructura por dominio y propiedad de cada módulo.
Routing y carga diferida.
Estrategia de datos remotos y caché.
Estado de UI, estado de servidor y estado persistente.
Formularios, validación y accesibilidad.
Límites entre Server Components y Client Components si se usa Next.js.
Sistema de diseño y reglas de composición.
Testing, linting, tipado y convenciones de imports.

No se necesita una librería global de estado para todo. El estado local puede vivir en el componente; el estado derivado debe calcularse cuando sea posible; los datos remotos suelen requerir una estrategia de caché específica; el estado compartido solo debe elevarse cuando exista una necesidad real.

7.4 Vue en escenarios empresariales

Vue también puede escalar. Nuxt, Vue Router, Pinia, TypeScript, herramientas de pruebas y convenciones internas permiten construir aplicaciones grandes. Lo decisivo es que el equipo defina límites, evite stores globales gigantes y separe la UI del acceso a datos y de las reglas del dominio.

La disponibilidad de perfiles y la experiencia existente pueden inclinar la balanza hacia React o Angular en algunas organizaciones. Eso es un dato del mercado y del equipo concreto, no una limitación intrínseca de Vue.

7.5 Monolito modular antes de microfrontends

En una aplicación grande, empezar con módulos bien delimitados dentro de una aplicación suele ser más sencillo que introducir microfrontends desde el primer día. Los microfrontends pueden ser útiles cuando hay equipos autónomos, ciclos de publicación independientes y límites organizacionales reales; también añaden complejidad de integración, diseño compartido, dependencias, routing y observabilidad.

Primero conviene establecer límites de dominio y ownership. La arquitectura de despliegue debería responder a necesidades concretas de coordinación, no a la expectativa de que dividir el frontend lo vuelve automáticamente escalable.

8. Reactividad y reutilización de lógica: Hooks, Signals y Composition API

Estos modelos se parecen en el objetivo —componer UI y reutilizar lógica—, pero no son intercambiables.

Concepto	React	Angular	Vue
Estado local	`useState`, `useReducer`	`signal()` y otras APIs según el caso	`ref()`, `reactive()`
Valor derivado	Cálculo durante render; `useMemo` cuando aporta valor	`computed()`	`computed()`
Efectos / sincronización externa	`useEffect` y otros Hooks según la necesidad	`effect()`; también APIs del ciclo de vida y RxJS	`watch()`, `watchEffect()` y hooks del ciclo de vida
Reutilizar lógica	Custom Hooks	Servicios, funciones, Signals y RxJS	Composables
Estado global	Context o librerías externas cuando se necesitan	Servicios, Signals, RxJS o librerías según el caso	Pinia o composables para casos simples

Ejemplos mínimos:

React

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  const doubled = count * 2;

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      {doubled}
    </button>
  );
}

Angular

import { computed, signal } from "@angular/core";

const count = signal(0);
const doubled = computed(() => count() * 2);

count.update((value) => value + 1);

Vue

<script setup lang="ts">
import { computed, ref } from "vue";

const count = ref(0);
const doubled = computed(() => count.value * 2);
</script>

<template>
  <button @click="count++">{{ doubled }}</button>
</template>

Los ejemplos ilustran el modelo, no una aplicación completa. En React, los Hooks tienen reglas de uso y no deben llamarse condicionalmente ni dentro de bucles. En Angular, los Signals rastrean las dependencias leídas y notifican a los consumidores. En Vue, el sistema de reactividad rastrea lecturas y actualiza los consumidores pertinentes.

No conviene optimizar prematuramente con useMemo, useCallback o efectos en React; tampoco convertir cada valor en un store global en Angular o Vue. Primero se debe mantener el flujo de datos claro y medir si existe un problema real.

9. Mobile: compartir tecnología no significa compartir toda la UI

Si el producto podría necesitar iOS y Android, la decisión debe tomarse desde el inicio, aunque el lanzamiento móvil sea posterior. Hay que diferenciar una web adaptable, una PWA, una app híbrida dentro de WebView y una app nativa multiplataforma.

Camino	Modelo	Ventajas	Límites
React Native + Expo	UI con componentes nativos; React y JavaScript/TypeScript.	Ecosistema mobile fuerte, herramientas de desarrollo y publicación integradas con Expo; comparte lógica y conocimientos con React web.	La UI web no se reutiliza directamente; algunas capacidades requieren módulos nativos o desarrollo específico.
Ionic + Angular + Capacitor	UI web en una WebView, con acceso a capacidades nativas mediante plugins.	Reutiliza conocimiento Angular, HTML/CSS y lógica web; útil para equipos web-first y aplicaciones de negocio.	La experiencia y rendimiento dependen del tipo de UI y del uso de la WebView; no es lo mismo que renderizar controles nativos.
Ionic Vue + Capacitor	Enfoque híbrido equivalente, usando Vue.	Aprovecha Vue y el ecosistema Ionic; acceso a cámara, geolocalización y otras capacidades mediante plugins compatibles.	Mismas consideraciones generales de WebView e integración nativa.
PWA	Aplicación web instalable con capacidades dependientes del navegador y sistema operativo.	Una sola entrega web, distribución sencilla y menor coste inicial.	Las APIs y capacidades disponibles varían según plataforma; no siempre sustituye una app publicada en tiendas.
Nativo	Swift/SwiftUI para iOS y Kotlin/Jetpack Compose para Android, entre otras opciones.	Máximo control sobre APIs y experiencia de cada plataforma.	Mayor coste si se mantienen implementaciones separadas.

React Native y Expo

Expo es un framework y conjunto de herramientas para desarrollar aplicaciones React Native. Facilita el ciclo de desarrollo, módulos nativos, routing opcional y servicios de build y distribución. Si la estrategia contempla una app móvil con una experiencia realmente nativa, es una de las opciones principales que se deben evaluar.

Compartir React no implica que una interfaz web pueda copiarse tal cual a React Native: la plataforma usa primitivas distintas, estilos distintos y capacidades diferentes. Lo más reutilizable suele ser lógica de dominio, validaciones, tipos, clientes API, reglas de negocio y parte del diseño de producto.

Angular o Vue con Capacitor

Capacitor permite empaquetar una aplicación web para distribuirla como aplicación móvil y acceder a APIs nativas mediante plugins. Angular y Vue pueden usarse con Ionic y Capacitor. Para equipos que ya dominan tecnologías web y construyen aplicaciones de negocio, puede reducir la duplicación y acelerar la entrega.

No recomendaría Cordova como primera opción para un proyecto nuevo sin una razón concreta. Capacitor es la ruta moderna asociada al ecosistema Ionic; Cordova sigue existiendo, pero debe evaluarse por compatibilidad con plugins, mantenimiento y necesidades del proyecto, no por costumbre.

Decisión mobile

Si la app es central para el producto y necesita una experiencia nativa cuidada: evaluar React Native + Expo y alternativas nativas.
Si es una app de negocio basada en formularios, catálogos, operaciones y contenido web, y el equipo es web-first: evaluar Ionic + Capacitor.
Si solo se necesita una experiencia móvil razonable y distribución sencilla: valorar primero una web responsive o PWA.
Si mobile es una posibilidad futura, no asumir que compartir framework equivale a compartir el frontend completo. Diseñar desde el principio una API estable y lógica de dominio separable.

10. CSS, diseño, gráficos, mapas y librerías de terceros

Tailwind CSS, Bootstrap y las librerías de UI no pertenecen exclusivamente a React, Angular o Vue. La compatibilidad concreta depende de cómo se integra cada paquete, si ofrece componentes específicos del framework y de qué versión de CSS/JS requiere.

CSS y sistemas de diseño

Tailwind CSS: útil cuando el equipo quiere componer estilos desde utilidades y mantener un sistema visual coherente mediante tokens y configuración.
Bootstrap: útil cuando se busca un sistema conocido de grid, componentes y estilos con convenciones predefinidas.
CSS Modules, Sass o CSS estándar: alternativas válidas cuando el alcance o la organización de estilos lo justifican.
Librerías de componentes: conviene evaluar accesibilidad, soporte de teclado, theming, compatibilidad con SSR, tamaño del bundle y mantenimiento.

La elección de CSS no debería determinar por sí sola el framework. El sistema de diseño, los tokens, la accesibilidad y la consistencia visual suelen ser más importantes que la marca de la librería.

Gráficas y visualización

Opciones como Apache ECharts, Chart.js, D3 y otras librerías pueden integrarse en distintos frameworks. Algunas tienen wrappers específicos para React, Angular o Vue. Antes de elegir, revisar:

Volumen de datos y complejidad de visualización.
Interacción, zoom, exportación y accesibilidad.
Renderizado en servidor y dependencias de window/DOM.
Tamaño del bundle y posibilidad de importar módulos selectivos.
Licencia, mantenimiento y experiencia del equipo.

Mapas

Mapbox, Google Maps, Leaflet y otras herramientas cuentan con integraciones o wrappers para diferentes ecosistemas. La decisión debería considerar geocodificación, rutas, clustering, costes por uso, términos de licencia, privacidad y funcionamiento móvil. Un wrapper específico del framework facilita la integración, pero no elimina los costes ni las restricciones del proveedor.

Regla de dependencias

No instales una librería solo porque exista un wrapper. Revisa actividad del proyecto, compatibilidad con la versión del framework, accesibilidad, licencia, vulnerabilidades, tamaño y posibilidad de sustituirla. En aplicaciones grandes, crea adaptadores para proveedores externos cuando el coste de acoplamiento sea significativo.

11. Buenas prácticas comunes, independientemente del framework

Arquitectura y código

Organizar por dominios o funcionalidades cuando el proyecto crece.
Mantener componentes pequeños, con responsabilidades explícitas.
Separar presentación, acceso a datos y reglas de negocio cuando ayude a probar y mantener el sistema.
Evitar estados duplicados y valores derivados almacenados innecesariamente.
Definir contratos tipados para APIs y errores.
Mantener un sistema de diseño y patrones de accesibilidad.
No crear una abstracción genérica hasta entender qué variaciones reales existen.

Rendimiento

Medir Core Web Vitals y rendimiento real en dispositivos representativos.
Optimizar imágenes, fuentes y recursos críticos.
Usar carga diferida para rutas y componentes no críticos.
Limitar scripts de terceros, analítica y widgets externos.
Evitar enviar JavaScript para contenido que no lo necesita.
Definir una política de caché coherente con la frescura requerida.
No confundir tamaño del bundle, tiempo de build, rendimiento del servidor y experiencia del usuario.

SEO y contenido

HTML semántico y contenido principal accesible sin depender de interacciones innecesarias.
Títulos, descripciones, canonical, Open Graph, sitemap y robots configurados correctamente.
URLs estables y enlaces rastreables.
Datos estructurados solo cuando sean apropiados y fieles al contenido.
Verificar el HTML generado y no confiar exclusivamente en que el buscador ejecute JavaScript.
Probar previews de redes sociales, paginación, redirecciones y páginas de error.

Calidad y entrega

TypeScript en proyectos donde aporte seguridad y mantenibilidad.
Lint, formato, pruebas unitarias, integración y end-to-end según el riesgo.
Pipeline CI que ejecute validaciones antes de publicar.
Entornos reproducibles, secretos fuera del código y dependencias revisadas.
Despliegues reversibles, monitoreo de errores y métricas de frontend.
Revisar accesibilidad con pruebas automáticas y manuales.
Documentar decisiones relevantes mediante ADRs (Architecture Decision Records).

12. Cómo comparar rendimiento sin caer en benchmarks engañosos

No existe un benchmark universal que permita afirmar que React, Angular, Vue, Astro o Qwik es «el más rápido» para cualquier producto. El resultado depende del caso de uso, versiones, implementación, renderizado, dependencias, tamaño de datos, hardware, red y metodología.

Para una comparación útil, construir prototipos equivalentes y medir varias dimensiones:

Dimensión	Qué medir
Carga inicial	LCP, FCP, CLS, TTFB y tamaño transferido.
Interactividad	INP, tiempo de ejecución de JavaScript y respuesta a interacciones representativas.
Navegación	Tiempo entre rutas, recursos descargados y experiencia tras la primera carga.
Renderizado servidor	TTFB bajo carga, CPU, memoria, throughput y errores.
Desarrollo	Tiempo para completar las mismas tareas, complejidad de pruebas y cambios posteriores.
Mantenibilidad	Claridad de límites, facilidad para incorporar un desarrollador y coste de actualización.
Operación	Coste de hosting, CDN, funciones/servidores, observabilidad y soporte.

Protocolo recomendado

Definir escenarios idénticos: landing de contenido, listado con filtros, formulario complejo y dashboard.
Usar versiones estables comparables y documentar las configuraciones.
Comparar la misma estrategia de renderizado cuando se evalúa el framework; luego comparar estrategias distintas como una segunda prueba.
Probar build de producción, no solo servidor de desarrollo.
Medir en dispositivos y redes representativos, incluyendo móviles de gama media.
Ejecutar suficientes repeticiones y reportar mediana y percentiles, no solo la mejor corrida.
Registrar bundle inicial, scripts ejecutados, solicitudes, memoria, CPU y resultados de Web Vitals.
Publicar el código, comandos, versiones y metodología para que otros puedan reproducir los resultados.

Un benchmark sintético ayuda a encontrar diferencias técnicas, pero no representa automáticamente la productividad del equipo ni el rendimiento de un producto real. Para una landing, el resultado relevante puede ser cuánto JavaScript se envía y qué tan rápido aparece el contenido. Para un dashboard, puede importar más la latencia de interacción con tablas grandes, la gestión de estado y la navegación posterior.

13. Matriz de decisión orientativa

Escenario	Primera opción a evaluar	Alternativas razonables	Por qué
Landing de contenido con SEO y carga rápida	Astro	HTML/CSS/JS, Next.js, Nuxt	Prioriza HTML y evita JavaScript innecesario por defecto.
Blog o documentación	Astro	Generador estático, Next.js, Nuxt	Contenido, SEO, CDN y mantenimiento sencillo.
Landing dentro de una plataforma React	Next.js o Astro según el grado de integración	HTML estático	Mantiene coherencia cuando comparte rutas, componentes o datos; Astro si es independiente y principalmente contenido.
SPA autenticada pequeña/mediana	React + Vite, Vue + Vite o Angular	Según experiencia del equipo	SSR suele ser opcional si SEO no importa.
Aplicación pública dinámica con SEO	Next.js, Nuxt o Angular SSR	Otras soluciones SSR maduras	Permiten generar HTML inicial y combinar estrategias por ruta.
Plataforma empresarial con múltiples equipos	Angular si sus convenciones encajan; React si el equipo ya lo domina	Vue/Nuxt con estándares claros	La gobernanza, experiencia y arquitectura pesan más que una clasificación abstracta.
Aplicación móvil con UI nativa	React Native + Expo	Desarrollo nativo	Permite construir apps iOS/Android con componentes nativos.
Aplicación de negocio web-first en tiendas móviles	Ionic + Capacitor con Angular o Vue	React + Capacitor, según necesidades	Reutiliza gran parte del enfoque web y conecta con capacidades nativas.
Experiencia móvil sencilla	Responsive/PWA	Capacitor	Menos complejidad si no se requieren capacidades nativas profundas.
Rendimiento inicial extremo como requisito diferencial	Prototipo con Astro o Qwik	Otras opciones con optimización cuidadosa	Evalúa JavaScript enviado, reactividad necesaria y complejidad real del producto.

La tabla es una guía para priorizar pruebas, no un ranking absoluto. La opción correcta puede cambiar si el equipo tiene mucha experiencia en otra tecnología o si el producto comparte una plataforma existente.

14. Recomendación final: elegir para el producto y para el equipo

Una decisión razonable puede resumirse así:

Para una landing o un sitio de contenido: empieza evaluando Astro o incluso HTML/CSS/JS sin framework. El contenido y la entrega deben ser rápidos; añade interactividad solo donde sea necesaria.
Para una aplicación web pequeña o mediana: React, Angular y Vue son opciones válidas. Elige CSR si encaja con el producto y SSR/SSG si hay una razón concreta. En React, Next.js es una opción integral; en Vue, Nuxt; en Angular, la solución SSR soportada por la versión actual.
Para una aplicación empresarial grande: prioriza convenciones, módulos, calidad de herramientas, testing, migraciones y experiencia del equipo. Angular aporta integración y consistencia; React aporta flexibilidad y un ecosistema enorme, pero exige acuerdos explícitos; Vue también puede escalar con Nuxt, Pinia y convenciones bien mantenidas.
Para mobile: decide si necesitas UI nativa, una app web empaquetada o una PWA. React Native + Expo e Ionic + Capacitor resuelven necesidades distintas y no deben tratarse como equivalentes exactos.
Para rendimiento: mide el producto y el usuario real. El framework no compensa una arquitectura de carga deficiente, imágenes pesadas, demasiados scripts, caché incorrecta o APIs lentas.

La pregunta final no debería ser «¿cuál framework gana?», sino:

¿Qué combinación de framework, renderizado, arquitectura, entrega y capacidades del equipo nos permite construir el producto correcto, con buen rendimiento y el menor coste sostenible de evolución?

En la práctica, el lenguaje o framework rara vez es el único factor decisivo. La calidad de las decisiones, la disciplina de ingeniería, las herramientas de entrega, la observabilidad y la capacidad del equipo para mantener el sistema suelen pesar mucho más a largo plazo.

Lecturas relacionadas

Referencias

React y Next.js

Angular

Vue y Nuxt

Astro y Qwik

Mobile

Rendimiento y accesibilidad

Nota editorial

Esta guía compara enfoques arquitectónicos y no pretende declarar un ganador universal. Las decisiones definitivas deben validarse con requisitos reales, versiones concretas, una prueba técnica representativa y el contexto del equipo. Conviene revisar la documentación oficial al iniciar un proyecto: los frameworks evolucionan con rapidez.

Índice

Arquitectura · 19 de octubre de 2026 · Daniel Murillo

Decisión de arquitectura frontend: React, Angular, Vue y el rendimiento

Cómo elegir framework, renderizado y estrategia mobile sin confundir popularidad con encaje. Una guía por escenario para 2026.

No existe un framework frontend universalmente superior. La decisión correcta depende del producto, el equipo, la experiencia que necesita ofrecer, la estrategia de publicación, los requisitos de SEO, la necesidad de mobile y el coste de mantenerlo durante años. La tecnología importa, pero importa más elegir una arquitectura que encaje con el problema y ejecutarla bien.

1. Antes de comparar frameworks: separar las decisiones

En muchas discusiones se comparan React, Angular, Vue, Astro o Next.js como si fueran alternativas exactamente equivalentes. No lo son. Hay varias capas:

Biblioteca o framework de UI: React, Angular y Vue.
Framework de aplicación y renderizado: Next.js, Nuxt, Angular SSR, Astro y Qwik City.
Estrategia de renderizado: CSR, SSR, generación estática (SSG), regeneración/revalidación y renderizado híbrido.
Herramientas de construcción y entrega: Vite, compiladores, bundlers, CDN, adaptadores de despliegue y pipelines CI/CD.
Estrategia mobile: React Native/Expo, Ionic con Capacitor, u otras soluciones nativas o multiplataforma.

2. Las preguntas que deberían decidir la arquitectura

Antes de elegir tecnología, conviene responder:

¿Qué estamos construyendo? Una landing, un blog, un e-commerce, un dashboard, una SPA interna o una plataforma empresarial son problemas diferentes.
¿Qué tan importante es el SEO? Para páginas públicas que deben posicionar, el HTML inicial, los metadatos, la indexabilidad y el rendimiento importan mucho.
¿Cuánta interactividad real necesita el usuario? Una página con texto, imágenes y un formulario no necesita necesariamente enviar un runtime grande de JavaScript al navegador.
¿Habrá aplicación mobile? ¿Se necesita compartir lógica, componentes, diseño o incluso experiencia entre web y móvil?
¿Qué tamaño tendrá el producto? ¿Cuántas rutas, dominios funcionales, equipos, permisos, integraciones y ciclos de vida se esperan?
¿Quién lo mantendrá? La experiencia del equipo y su capacidad para contratar, revisar código, probar y operar la aplicación son criterios arquitectónicos, no detalles secundarios.
¿Cómo se publicará? ¿Hosting estático detrás de una CDN, servidor Node, funciones serverless, contenedores o plataforma gestionada?
¿Qué significa «rápido»? Puede significar carga inicial, interactividad, navegación posterior, tiempo de compilación, velocidad de desarrollo o tiempo de respuesta del servidor. Son métricas distintas.

Una buena decisión documenta las prioridades y sus compromisos, en vez de declarar que un framework es «el más rápido» sin especificar qué se midió.

3. CSR, SSR, SSG e híbrido: elegir el renderizado por ruta

El renderizado no es una decisión binaria de «usar SSR o no». Un mismo producto puede usar distintas estrategias según la ruta.

Estrategia	Cómo funciona	Ventajas	Costes y límites	Casos típicos
CSR (Client-Side Rendering)	El navegador carga JavaScript y construye la UI.	Interacciones ricas; despliegue estático posible; modelo natural para herramientas autenticadas.	El contenido puede tardar más en aparecer si depende mucho del bundle o de APIs; SEO y previews requieren más cuidado.	Dashboards, herramientas internas, aplicaciones muy interactivas.
SSR (Server-Side Rendering)	El servidor genera HTML por petición y el cliente puede hidratarlo.	Contenido inicial visible; útil para páginas personalizadas o datos actuales; favorece previews y rastreo.	Coste y latencia de servidor; complejidad de caché; hidratación; cuidado con estado por usuario y APIs exclusivas del navegador.	Catálogos, páginas personalizadas, portales públicos dinámicos.
SSG (Static Site Generation)	El HTML se genera en build.	Muy rápido y barato de servir desde CDN; alta disponibilidad y caché sencilla.	Cambios de contenido pueden requerir rebuild o revalidación; no es ideal para contenido altamente personalizado sin otra capa.	Landing pages, documentación, blogs y páginas de marketing.
Híbrido / ISR / revalidación	Se combinan páginas estáticas, SSR y actualización de contenido.	Ajusta coste, frescura y rendimiento según cada ruta.	Más decisiones sobre caché, invalidación y consistencia.	E-commerce, sitios de contenido grandes y productos con zonas públicas y privadas.
Islas / hidratación parcial	La mayor parte es HTML; solo componentes concretos reciben JavaScript.	Reduce JavaScript enviado cuando la página es principalmente contenido.	Hay que definir límites entre contenido estático e interactividad; no sustituye automáticamente una aplicación compleja.	Marketing, blogs, documentación y páginas de producto.
Resumability	La aplicación retoma en el cliente el estado y trabajo preparado en servidor, evitando la hidratación tradicional completa.	Puede reducir el trabajo inicial del navegador.	Modelo de programación y ecosistema distintos; hay que validar madurez y encaje del equipo.	Sitios y aplicaciones donde el coste de arranque cliente es crítico.

4. React, Angular y Vue: comparación de alto nivel

Criterio	React	Angular	Vue
Naturaleza	Biblioteca de UI; necesita decisiones adicionales para completar la arquitectura.	Framework integral con convenciones y herramientas oficiales.	Framework progresivo con una curva de entrada amable y APIs oficiales para crecer.
Modelo de UI	Componentes funcionales, JSX y Hooks.	Componentes, templates, inyección de dependencias, servicios y APIs del framework.	Componentes de archivo único, templates y Composition API u Options API.
Reactividad	Estado y actualización declarados mediante Hooks y el modelo de React.	Signals, RxJS y mecanismos propios del framework, según el caso.	Reactividad fina con `ref`, `reactive`, `computed` y `watch`.
Arquitectura	Flexible; requiere acordar routing, datos, formularios, estado y convenciones.	Más prescriptiva; estructura y patrones comunes vienen definidos por el framework.	Flexible, con buenas herramientas oficiales; el equipo debe fijar convenciones al crecer.
TypeScript	Muy buen soporte; la calidad arquitectónica depende de cómo se diseñe el proyecto.	Integración central y profunda con TypeScript.	Muy buen soporte, especialmente con Composition API y `<script setup>`.
Ecosistema	Muy amplio, especialmente para web y mobile con React Native.	Ecosistema amplio y conjunto oficial integrado; menor necesidad de elegir piezas externas para funciones comunes.	Ecosistema sólido; Nuxt, Pinia, Vue Router y Vite cubren buena parte de las necesidades.
SSR / SSG	Normalmente se elige un framework como Next.js o una configuración específica.	SSR integrado en las herramientas modernas de Angular.	Nuxt es la opción habitual para SSR, SSG y aplicaciones Vue completas.
Mobile	React Native con Expo permite crear aplicaciones nativas usando React.	Ionic/Capacitor permite empaquetar una app web y acceder a capacidades nativas.	Ionic Vue con Capacitor permite un enfoque similar basado en Vue.
Riesgo principal	La libertad puede producir arquitecturas inconsistentes si no hay acuerdos.	La amplitud del framework puede sentirse pesada en proyectos pequeños o equipos sin experiencia.	Puede ser menos común en ciertos mercados o empresas; disponibilidad de talento debe evaluarse localmente.

4.1 React: flexibilidad y un ecosistema enorme

Esa misma flexibilidad implica que el equipo debe tomar y mantener decisiones sobre:

Routing y estructura de rutas.
Obtención, caché e invalidación de datos.
Formularios y validación.
Estado local frente a estado compartido.
Autenticación, permisos y límites de módulos.
Estrategia SSR/SSG y despliegue.
Pruebas, convenciones, accesibilidad y observabilidad.

4.2 Angular: convenciones, integración y consistencia

Es especialmente competitivo en:

Aplicaciones empresariales con formularios complejos, roles y flujos de negocio.
Sistemas con muchos módulos y equipos.
Organizaciones que valoran convenciones, consistencia y una evolución controlada.
Proyectos TypeScript donde interesa que el framework cubra gran parte de las necesidades comunes.

4.3 Vue: equilibrio entre ergonomía y capacidad

Su reactividad se construye alrededor de APIs como:

ref() para valores reactivos.
reactive() para objetos reactivos.
computed() para valores derivados.
watch() / watchEffect() para observar cambios y reaccionar cuando corresponda.
Composables para encapsular y reutilizar lógica.

No necesita copiar exactamente los Hooks de React para ser comparable. Ambos permiten reutilizar lógica, pero la semántica de reactividad es distinta.

5. Una landing page: no siempre hace falta React, Angular o Vue

Opciones a considerar

Opción	Cuándo encaja	Observaciones
HTML semántico + CSS + JavaScript mínimo	Landing muy sencilla, estable y con pocas interacciones.	La solución más directa puede ser la mejor. No hace falta un framework por defecto.
Astro	Landing, marketing, blog, documentación, portfolio y sitios de contenido.	Renderiza HTML por defecto y permite añadir islas interactivas con React, Vue, Svelte, Preact y otras integraciones.
Qwik / Qwik City	El rendimiento de arranque y la cantidad de trabajo JavaScript en el cliente son criterios centrales.	Usa resumability en lugar de reproducir la hidratación tradicional completa. Tiene un modelo distinto que el equipo debe evaluar.
Next.js	Landing que comparte arquitectura con una aplicación React, necesita rutas dinámicas, contenido personalizado o un backend cercano.	Flexible y potente, pero no necesariamente la opción más simple para una página casi estática.
Nuxt	Landing o sitio de contenido dentro de un ecosistema Vue, con SSR/SSG.	Alternativa completa cuando Vue ya es la elección del equipo.
Angular SSR	La landing es parte de una plataforma Angular más amplia o la organización ya estandarizó Angular.	Tiene sentido por continuidad de plataforma; puede ser más de lo necesario para una landing independiente.

5.1 Astro: contenido primero, JavaScript cuando haga falta

Un enfoque razonable para una landing sería:

HTML semántico y contenido accesible.
CSS optimizado y fuentes/imágenes correctamente dimensionadas.
Formularios con validación y estados de error claros.
Carga diferida para componentes secundarios.
React, Vue o Preact solo para widgets que realmente lo necesitan.
Metadatos, canonical, Open Graph, sitemap y datos estructurados cuando apliquen.
Analítica y scripts de terceros limitados y medidos.

5.2 Qwik: resumability y coste de arranque

Recomendación para una landing

Astro como primera opción si la página es principalmente contenido y SEO/rendimiento son prioritarios.
HTML/CSS/JS sin framework si el alcance es realmente pequeño y estable.
Next.js o Nuxt si la landing forma parte de una plataforma React/Vue o requiere renderizado dinámico más integrado.
Angular SSR si la continuidad con una plataforma Angular es una ventaja real.
Qwik como candidato que merece una prueba técnica cuando el rendimiento de arranque sea crítico y el equipo acepte evaluar un modelo menos convencional.

La recomendación debe validarse con una prueba representativa y métricas reales, no solo con demos.

6. Aplicaciones web pequeñas y medianas

Para una aplicación pequeña o mediana —por ejemplo, un portal de clientes, una agenda, un catálogo con autenticación o un panel administrativo— hay varias rutas válidas.

React + Vite o React + Next.js

Vite + React puede ser una opción simple para una SPA autenticada donde SEO no sea importante.
Next.js aporta routing, renderizado en servidor/estático, Server Components y mecanismos integrados de carga de datos y caché.
No todo componente debe ser de cliente en Next.js. Mantener en el servidor lo que no necesita interactividad reduce trabajo cliente, pero requiere comprender bien las fronteras servidor/cliente.

Vue + Vite o Vue + Nuxt

Vue + Vite es adecuado para una SPA o una aplicación web que no necesita SSR.
Nuxt encaja cuando se requiere SSR, SSG o una estrategia híbrida.
Para estado global, Pinia es la recomendación habitual para proyectos nuevos; Vuex no debería ser la opción automática por inercia.

Angular

Angular puede resolver aplicaciones medianas con una estructura consistente y tooling integrado.
SSR tiene sentido cuando existen páginas públicas indexables, se necesita HTML inicial o la experiencia del primer render lo justifica.
Para un panel interno autenticado, SSR puede no aportar suficiente valor para compensar la complejidad operativa.

7. Aplicaciones grandes y empresariales

7.1 Arquitectura por funcionalidades, no por tipo de archivo solamente

Ejemplo conceptual:

src/
  app/
    core/                 # configuración global y servicios transversales
    shared/               # UI y utilidades verdaderamente reutilizables
    features/
      customers/
        components/
        pages/
        data-access/
        domain/
        customers.routes.ts
      billing/
        components/
        pages/
        data-access/
        domain/
        billing.routes.ts
  environments/

7.2 Angular en escenarios empresariales

Prácticas recomendadas:

Lazy loading por rutas y límites de dominio.
Componentes pequeños y con responsabilidades claras.
Servicios y adaptadores para aislar APIs.
Formularios reactivos cuando el flujo de validación lo requiera.
Signals para estado reactivo local/derivado; RxJS para flujos asíncronos cuando corresponda.
Evitar lógica de negocio compleja dentro de templates o componentes.
Pruebas unitarias, de integración y end-to-end según riesgo.
Mantener al día dependencias y migraciones del framework.

7.3 React en escenarios empresariales

Hay que decidir y documentar, como mínimo:

Estructura por dominio y propiedad de cada módulo.
Routing y carga diferida.
Estrategia de datos remotos y caché.
Estado de UI, estado de servidor y estado persistente.
Formularios, validación y accesibilidad.
Límites entre Server Components y Client Components si se usa Next.js.
Sistema de diseño y reglas de composición.
Testing, linting, tipado y convenciones de imports.

7.4 Vue en escenarios empresariales

7.5 Monolito modular antes de microfrontends

8. Reactividad y reutilización de lógica: Hooks, Signals y Composition API

Estos modelos se parecen en el objetivo —componer UI y reutilizar lógica—, pero no son intercambiables.

Concepto	React	Angular	Vue
Estado local	`useState`, `useReducer`	`signal()` y otras APIs según el caso	`ref()`, `reactive()`
Valor derivado	Cálculo durante render; `useMemo` cuando aporta valor	`computed()`	`computed()`
Efectos / sincronización externa	`useEffect` y otros Hooks según la necesidad	`effect()`; también APIs del ciclo de vida y RxJS	`watch()`, `watchEffect()` y hooks del ciclo de vida
Reutilizar lógica	Custom Hooks	Servicios, funciones, Signals y RxJS	Composables
Estado global	Context o librerías externas cuando se necesitan	Servicios, Signals, RxJS o librerías según el caso	Pinia o composables para casos simples

Ejemplos mínimos:

React

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  const doubled = count * 2;

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      {doubled}
    </button>
  );
}

Angular

import { computed, signal } from "@angular/core";

const count = signal(0);
const doubled = computed(() => count() * 2);

count.update((value) => value + 1);

Vue

<script setup lang="ts">
import { computed, ref } from "vue";

const count = ref(0);
const doubled = computed(() => count.value * 2);
</script>

<template>
  <button @click="count++">{{ doubled }}</button>
</template>

9. Mobile: compartir tecnología no significa compartir toda la UI

Camino	Modelo	Ventajas	Límites
React Native + Expo	UI con componentes nativos; React y JavaScript/TypeScript.	Ecosistema mobile fuerte, herramientas de desarrollo y publicación integradas con Expo; comparte lógica y conocimientos con React web.	La UI web no se reutiliza directamente; algunas capacidades requieren módulos nativos o desarrollo específico.
Ionic + Angular + Capacitor	UI web en una WebView, con acceso a capacidades nativas mediante plugins.	Reutiliza conocimiento Angular, HTML/CSS y lógica web; útil para equipos web-first y aplicaciones de negocio.	La experiencia y rendimiento dependen del tipo de UI y del uso de la WebView; no es lo mismo que renderizar controles nativos.
Ionic Vue + Capacitor	Enfoque híbrido equivalente, usando Vue.	Aprovecha Vue y el ecosistema Ionic; acceso a cámara, geolocalización y otras capacidades mediante plugins compatibles.	Mismas consideraciones generales de WebView e integración nativa.
PWA	Aplicación web instalable con capacidades dependientes del navegador y sistema operativo.	Una sola entrega web, distribución sencilla y menor coste inicial.	Las APIs y capacidades disponibles varían según plataforma; no siempre sustituye una app publicada en tiendas.
Nativo	Swift/SwiftUI para iOS y Kotlin/Jetpack Compose para Android, entre otras opciones.	Máximo control sobre APIs y experiencia de cada plataforma.	Mayor coste si se mantienen implementaciones separadas.

React Native y Expo

Angular o Vue con Capacitor

Decisión mobile

Si la app es central para el producto y necesita una experiencia nativa cuidada: evaluar React Native + Expo y alternativas nativas.
Si es una app de negocio basada en formularios, catálogos, operaciones y contenido web, y el equipo es web-first: evaluar Ionic + Capacitor.
Si solo se necesita una experiencia móvil razonable y distribución sencilla: valorar primero una web responsive o PWA.
Si mobile es una posibilidad futura, no asumir que compartir framework equivale a compartir el frontend completo. Diseñar desde el principio una API estable y lógica de dominio separable.

10. CSS, diseño, gráficos, mapas y librerías de terceros

CSS y sistemas de diseño

Tailwind CSS: útil cuando el equipo quiere componer estilos desde utilidades y mantener un sistema visual coherente mediante tokens y configuración.
Bootstrap: útil cuando se busca un sistema conocido de grid, componentes y estilos con convenciones predefinidas.
CSS Modules, Sass o CSS estándar: alternativas válidas cuando el alcance o la organización de estilos lo justifican.
Librerías de componentes: conviene evaluar accesibilidad, soporte de teclado, theming, compatibilidad con SSR, tamaño del bundle y mantenimiento.

Gráficas y visualización

Opciones como Apache ECharts, Chart.js, D3 y otras librerías pueden integrarse en distintos frameworks. Algunas tienen wrappers específicos para React, Angular o Vue. Antes de elegir, revisar:

Volumen de datos y complejidad de visualización.
Interacción, zoom, exportación y accesibilidad.
Renderizado en servidor y dependencias de window/DOM.
Tamaño del bundle y posibilidad de importar módulos selectivos.
Licencia, mantenimiento y experiencia del equipo.

Mapas

Regla de dependencias

11. Buenas prácticas comunes, independientemente del framework

Arquitectura y código

Organizar por dominios o funcionalidades cuando el proyecto crece.
Mantener componentes pequeños, con responsabilidades explícitas.
Separar presentación, acceso a datos y reglas de negocio cuando ayude a probar y mantener el sistema.
Evitar estados duplicados y valores derivados almacenados innecesariamente.
Definir contratos tipados para APIs y errores.
Mantener un sistema de diseño y patrones de accesibilidad.
No crear una abstracción genérica hasta entender qué variaciones reales existen.

Rendimiento

Medir Core Web Vitals y rendimiento real en dispositivos representativos.
Optimizar imágenes, fuentes y recursos críticos.
Usar carga diferida para rutas y componentes no críticos.
Limitar scripts de terceros, analítica y widgets externos.
Evitar enviar JavaScript para contenido que no lo necesita.
Definir una política de caché coherente con la frescura requerida.
No confundir tamaño del bundle, tiempo de build, rendimiento del servidor y experiencia del usuario.

SEO y contenido

HTML semántico y contenido principal accesible sin depender de interacciones innecesarias.
Títulos, descripciones, canonical, Open Graph, sitemap y robots configurados correctamente.
URLs estables y enlaces rastreables.
Datos estructurados solo cuando sean apropiados y fieles al contenido.
Verificar el HTML generado y no confiar exclusivamente en que el buscador ejecute JavaScript.
Probar previews de redes sociales, paginación, redirecciones y páginas de error.

Calidad y entrega

TypeScript en proyectos donde aporte seguridad y mantenibilidad.
Lint, formato, pruebas unitarias, integración y end-to-end según el riesgo.
Pipeline CI que ejecute validaciones antes de publicar.
Entornos reproducibles, secretos fuera del código y dependencias revisadas.
Despliegues reversibles, monitoreo de errores y métricas de frontend.
Revisar accesibilidad con pruebas automáticas y manuales.
Documentar decisiones relevantes mediante ADRs (Architecture Decision Records).

12. Cómo comparar rendimiento sin caer en benchmarks engañosos

Para una comparación útil, construir prototipos equivalentes y medir varias dimensiones:

Dimensión	Qué medir
Carga inicial	LCP, FCP, CLS, TTFB y tamaño transferido.
Interactividad	INP, tiempo de ejecución de JavaScript y respuesta a interacciones representativas.
Navegación	Tiempo entre rutas, recursos descargados y experiencia tras la primera carga.
Renderizado servidor	TTFB bajo carga, CPU, memoria, throughput y errores.
Desarrollo	Tiempo para completar las mismas tareas, complejidad de pruebas y cambios posteriores.
Mantenibilidad	Claridad de límites, facilidad para incorporar un desarrollador y coste de actualización.
Operación	Coste de hosting, CDN, funciones/servidores, observabilidad y soporte.

Protocolo recomendado

Definir escenarios idénticos: landing de contenido, listado con filtros, formulario complejo y dashboard.
Usar versiones estables comparables y documentar las configuraciones.
Comparar la misma estrategia de renderizado cuando se evalúa el framework; luego comparar estrategias distintas como una segunda prueba.
Probar build de producción, no solo servidor de desarrollo.
Medir en dispositivos y redes representativos, incluyendo móviles de gama media.
Ejecutar suficientes repeticiones y reportar mediana y percentiles, no solo la mejor corrida.
Registrar bundle inicial, scripts ejecutados, solicitudes, memoria, CPU y resultados de Web Vitals.
Publicar el código, comandos, versiones y metodología para que otros puedan reproducir los resultados.

13. Matriz de decisión orientativa

Escenario	Primera opción a evaluar	Alternativas razonables	Por qué
Landing de contenido con SEO y carga rápida	Astro	HTML/CSS/JS, Next.js, Nuxt	Prioriza HTML y evita JavaScript innecesario por defecto.
Blog o documentación	Astro	Generador estático, Next.js, Nuxt	Contenido, SEO, CDN y mantenimiento sencillo.
Landing dentro de una plataforma React	Next.js o Astro según el grado de integración	HTML estático	Mantiene coherencia cuando comparte rutas, componentes o datos; Astro si es independiente y principalmente contenido.
SPA autenticada pequeña/mediana	React + Vite, Vue + Vite o Angular	Según experiencia del equipo	SSR suele ser opcional si SEO no importa.
Aplicación pública dinámica con SEO	Next.js, Nuxt o Angular SSR	Otras soluciones SSR maduras	Permiten generar HTML inicial y combinar estrategias por ruta.
Plataforma empresarial con múltiples equipos	Angular si sus convenciones encajan; React si el equipo ya lo domina	Vue/Nuxt con estándares claros	La gobernanza, experiencia y arquitectura pesan más que una clasificación abstracta.
Aplicación móvil con UI nativa	React Native + Expo	Desarrollo nativo	Permite construir apps iOS/Android con componentes nativos.
Aplicación de negocio web-first en tiendas móviles	Ionic + Capacitor con Angular o Vue	React + Capacitor, según necesidades	Reutiliza gran parte del enfoque web y conecta con capacidades nativas.
Experiencia móvil sencilla	Responsive/PWA	Capacitor	Menos complejidad si no se requieren capacidades nativas profundas.
Rendimiento inicial extremo como requisito diferencial	Prototipo con Astro o Qwik	Otras opciones con optimización cuidadosa	Evalúa JavaScript enviado, reactividad necesaria y complejidad real del producto.

14. Recomendación final: elegir para el producto y para el equipo

Una decisión razonable puede resumirse así:

Para una landing o un sitio de contenido: empieza evaluando Astro o incluso HTML/CSS/JS sin framework. El contenido y la entrega deben ser rápidos; añade interactividad solo donde sea necesaria.
Para una aplicación web pequeña o mediana: React, Angular y Vue son opciones válidas. Elige CSR si encaja con el producto y SSR/SSG si hay una razón concreta. En React, Next.js es una opción integral; en Vue, Nuxt; en Angular, la solución SSR soportada por la versión actual.
Para una aplicación empresarial grande: prioriza convenciones, módulos, calidad de herramientas, testing, migraciones y experiencia del equipo. Angular aporta integración y consistencia; React aporta flexibilidad y un ecosistema enorme, pero exige acuerdos explícitos; Vue también puede escalar con Nuxt, Pinia y convenciones bien mantenidas.
Para mobile: decide si necesitas UI nativa, una app web empaquetada o una PWA. React Native + Expo e Ionic + Capacitor resuelven necesidades distintas y no deben tratarse como equivalentes exactos.
Para rendimiento: mide el producto y el usuario real. El framework no compensa una arquitectura de carga deficiente, imágenes pesadas, demasiados scripts, caché incorrecta o APIs lentas.

La pregunta final no debería ser «¿cuál framework gana?», sino:

¿Qué combinación de framework, renderizado, arquitectura, entrega y capacidades del equipo nos permite construir el producto correcto, con buen rendimiento y el menor coste sostenible de evolución?

Lecturas relacionadas

Referencias

React y Next.js

Angular

Vue y Nuxt

Astro y Qwik

Mobile

Rendimiento y accesibilidad

Nota editorial

Índice

Arquitectura · 19 de octubre de 2026 · Daniel Murillo

Decisión de arquitectura frontend: React, Angular, Vue y el rendimiento

Cómo elegir framework, renderizado y estrategia mobile sin confundir popularidad con encaje. Una guía por escenario para 2026.

No existe un framework frontend universalmente superior. La decisión correcta depende del producto, el equipo, la experiencia que necesita ofrecer, la estrategia de publicación, los requisitos de SEO, la necesidad de mobile y el coste de mantenerlo durante años. La tecnología importa, pero importa más elegir una arquitectura que encaje con el problema y ejecutarla bien.

1. Antes de comparar frameworks: separar las decisiones

En muchas discusiones se comparan React, Angular, Vue, Astro o Next.js como si fueran alternativas exactamente equivalentes. No lo son. Hay varias capas:

Biblioteca o framework de UI: React, Angular y Vue.
Framework de aplicación y renderizado: Next.js, Nuxt, Angular SSR, Astro y Qwik City.
Estrategia de renderizado: CSR, SSR, generación estática (SSG), regeneración/revalidación y renderizado híbrido.
Herramientas de construcción y entrega: Vite, compiladores, bundlers, CDN, adaptadores de despliegue y pipelines CI/CD.
Estrategia mobile: React Native/Expo, Ionic con Capacitor, u otras soluciones nativas o multiplataforma.

2. Las preguntas que deberían decidir la arquitectura

Antes de elegir tecnología, conviene responder:

¿Qué estamos construyendo? Una landing, un blog, un e-commerce, un dashboard, una SPA interna o una plataforma empresarial son problemas diferentes.
¿Qué tan importante es el SEO? Para páginas públicas que deben posicionar, el HTML inicial, los metadatos, la indexabilidad y el rendimiento importan mucho.
¿Cuánta interactividad real necesita el usuario? Una página con texto, imágenes y un formulario no necesita necesariamente enviar un runtime grande de JavaScript al navegador.
¿Habrá aplicación mobile? ¿Se necesita compartir lógica, componentes, diseño o incluso experiencia entre web y móvil?
¿Qué tamaño tendrá el producto? ¿Cuántas rutas, dominios funcionales, equipos, permisos, integraciones y ciclos de vida se esperan?
¿Quién lo mantendrá? La experiencia del equipo y su capacidad para contratar, revisar código, probar y operar la aplicación son criterios arquitectónicos, no detalles secundarios.
¿Cómo se publicará? ¿Hosting estático detrás de una CDN, servidor Node, funciones serverless, contenedores o plataforma gestionada?
¿Qué significa «rápido»? Puede significar carga inicial, interactividad, navegación posterior, tiempo de compilación, velocidad de desarrollo o tiempo de respuesta del servidor. Son métricas distintas.

Una buena decisión documenta las prioridades y sus compromisos, en vez de declarar que un framework es «el más rápido» sin especificar qué se midió.

3. CSR, SSR, SSG e híbrido: elegir el renderizado por ruta

El renderizado no es una decisión binaria de «usar SSR o no». Un mismo producto puede usar distintas estrategias según la ruta.

Estrategia	Cómo funciona	Ventajas	Costes y límites	Casos típicos
CSR (Client-Side Rendering)	El navegador carga JavaScript y construye la UI.	Interacciones ricas; despliegue estático posible; modelo natural para herramientas autenticadas.	El contenido puede tardar más en aparecer si depende mucho del bundle o de APIs; SEO y previews requieren más cuidado.	Dashboards, herramientas internas, aplicaciones muy interactivas.
SSR (Server-Side Rendering)	El servidor genera HTML por petición y el cliente puede hidratarlo.	Contenido inicial visible; útil para páginas personalizadas o datos actuales; favorece previews y rastreo.	Coste y latencia de servidor; complejidad de caché; hidratación; cuidado con estado por usuario y APIs exclusivas del navegador.	Catálogos, páginas personalizadas, portales públicos dinámicos.
SSG (Static Site Generation)	El HTML se genera en build.	Muy rápido y barato de servir desde CDN; alta disponibilidad y caché sencilla.	Cambios de contenido pueden requerir rebuild o revalidación; no es ideal para contenido altamente personalizado sin otra capa.	Landing pages, documentación, blogs y páginas de marketing.
Híbrido / ISR / revalidación	Se combinan páginas estáticas, SSR y actualización de contenido.	Ajusta coste, frescura y rendimiento según cada ruta.	Más decisiones sobre caché, invalidación y consistencia.	E-commerce, sitios de contenido grandes y productos con zonas públicas y privadas.
Islas / hidratación parcial	La mayor parte es HTML; solo componentes concretos reciben JavaScript.	Reduce JavaScript enviado cuando la página es principalmente contenido.	Hay que definir límites entre contenido estático e interactividad; no sustituye automáticamente una aplicación compleja.	Marketing, blogs, documentación y páginas de producto.
Resumability	La aplicación retoma en el cliente el estado y trabajo preparado en servidor, evitando la hidratación tradicional completa.	Puede reducir el trabajo inicial del navegador.	Modelo de programación y ecosistema distintos; hay que validar madurez y encaje del equipo.	Sitios y aplicaciones donde el coste de arranque cliente es crítico.

4. React, Angular y Vue: comparación de alto nivel

Criterio	React	Angular	Vue
Naturaleza	Biblioteca de UI; necesita decisiones adicionales para completar la arquitectura.	Framework integral con convenciones y herramientas oficiales.	Framework progresivo con una curva de entrada amable y APIs oficiales para crecer.
Modelo de UI	Componentes funcionales, JSX y Hooks.	Componentes, templates, inyección de dependencias, servicios y APIs del framework.	Componentes de archivo único, templates y Composition API u Options API.
Reactividad	Estado y actualización declarados mediante Hooks y el modelo de React.	Signals, RxJS y mecanismos propios del framework, según el caso.	Reactividad fina con `ref`, `reactive`, `computed` y `watch`.
Arquitectura	Flexible; requiere acordar routing, datos, formularios, estado y convenciones.	Más prescriptiva; estructura y patrones comunes vienen definidos por el framework.	Flexible, con buenas herramientas oficiales; el equipo debe fijar convenciones al crecer.
TypeScript	Muy buen soporte; la calidad arquitectónica depende de cómo se diseñe el proyecto.	Integración central y profunda con TypeScript.	Muy buen soporte, especialmente con Composition API y `<script setup>`.
Ecosistema	Muy amplio, especialmente para web y mobile con React Native.	Ecosistema amplio y conjunto oficial integrado; menor necesidad de elegir piezas externas para funciones comunes.	Ecosistema sólido; Nuxt, Pinia, Vue Router y Vite cubren buena parte de las necesidades.
SSR / SSG	Normalmente se elige un framework como Next.js o una configuración específica.	SSR integrado en las herramientas modernas de Angular.	Nuxt es la opción habitual para SSR, SSG y aplicaciones Vue completas.
Mobile	React Native con Expo permite crear aplicaciones nativas usando React.	Ionic/Capacitor permite empaquetar una app web y acceder a capacidades nativas.	Ionic Vue con Capacitor permite un enfoque similar basado en Vue.
Riesgo principal	La libertad puede producir arquitecturas inconsistentes si no hay acuerdos.	La amplitud del framework puede sentirse pesada en proyectos pequeños o equipos sin experiencia.	Puede ser menos común en ciertos mercados o empresas; disponibilidad de talento debe evaluarse localmente.

4.1 React: flexibilidad y un ecosistema enorme

Esa misma flexibilidad implica que el equipo debe tomar y mantener decisiones sobre:

Routing y estructura de rutas.
Obtención, caché e invalidación de datos.
Formularios y validación.
Estado local frente a estado compartido.
Autenticación, permisos y límites de módulos.
Estrategia SSR/SSG y despliegue.
Pruebas, convenciones, accesibilidad y observabilidad.

4.2 Angular: convenciones, integración y consistencia

Es especialmente competitivo en:

Aplicaciones empresariales con formularios complejos, roles y flujos de negocio.
Sistemas con muchos módulos y equipos.
Organizaciones que valoran convenciones, consistencia y una evolución controlada.
Proyectos TypeScript donde interesa que el framework cubra gran parte de las necesidades comunes.

4.3 Vue: equilibrio entre ergonomía y capacidad

Su reactividad se construye alrededor de APIs como:

ref() para valores reactivos.
reactive() para objetos reactivos.
computed() para valores derivados.
watch() / watchEffect() para observar cambios y reaccionar cuando corresponda.
Composables para encapsular y reutilizar lógica.

No necesita copiar exactamente los Hooks de React para ser comparable. Ambos permiten reutilizar lógica, pero la semántica de reactividad es distinta.

5. Una landing page: no siempre hace falta React, Angular o Vue

Opciones a considerar

Opción	Cuándo encaja	Observaciones
HTML semántico + CSS + JavaScript mínimo	Landing muy sencilla, estable y con pocas interacciones.	La solución más directa puede ser la mejor. No hace falta un framework por defecto.
Astro	Landing, marketing, blog, documentación, portfolio y sitios de contenido.	Renderiza HTML por defecto y permite añadir islas interactivas con React, Vue, Svelte, Preact y otras integraciones.
Qwik / Qwik City	El rendimiento de arranque y la cantidad de trabajo JavaScript en el cliente son criterios centrales.	Usa resumability en lugar de reproducir la hidratación tradicional completa. Tiene un modelo distinto que el equipo debe evaluar.
Next.js	Landing que comparte arquitectura con una aplicación React, necesita rutas dinámicas, contenido personalizado o un backend cercano.	Flexible y potente, pero no necesariamente la opción más simple para una página casi estática.
Nuxt	Landing o sitio de contenido dentro de un ecosistema Vue, con SSR/SSG.	Alternativa completa cuando Vue ya es la elección del equipo.
Angular SSR	La landing es parte de una plataforma Angular más amplia o la organización ya estandarizó Angular.	Tiene sentido por continuidad de plataforma; puede ser más de lo necesario para una landing independiente.

5.1 Astro: contenido primero, JavaScript cuando haga falta

Un enfoque razonable para una landing sería:

HTML semántico y contenido accesible.
CSS optimizado y fuentes/imágenes correctamente dimensionadas.
Formularios con validación y estados de error claros.
Carga diferida para componentes secundarios.
React, Vue o Preact solo para widgets que realmente lo necesitan.
Metadatos, canonical, Open Graph, sitemap y datos estructurados cuando apliquen.
Analítica y scripts de terceros limitados y medidos.

5.2 Qwik: resumability y coste de arranque

Recomendación para una landing

Astro como primera opción si la página es principalmente contenido y SEO/rendimiento son prioritarios.
HTML/CSS/JS sin framework si el alcance es realmente pequeño y estable.
Next.js o Nuxt si la landing forma parte de una plataforma React/Vue o requiere renderizado dinámico más integrado.
Angular SSR si la continuidad con una plataforma Angular es una ventaja real.
Qwik como candidato que merece una prueba técnica cuando el rendimiento de arranque sea crítico y el equipo acepte evaluar un modelo menos convencional.

La recomendación debe validarse con una prueba representativa y métricas reales, no solo con demos.

6. Aplicaciones web pequeñas y medianas

Para una aplicación pequeña o mediana —por ejemplo, un portal de clientes, una agenda, un catálogo con autenticación o un panel administrativo— hay varias rutas válidas.

React + Vite o React + Next.js

Vite + React puede ser una opción simple para una SPA autenticada donde SEO no sea importante.
Next.js aporta routing, renderizado en servidor/estático, Server Components y mecanismos integrados de carga de datos y caché.
No todo componente debe ser de cliente en Next.js. Mantener en el servidor lo que no necesita interactividad reduce trabajo cliente, pero requiere comprender bien las fronteras servidor/cliente.

Vue + Vite o Vue + Nuxt

Vue + Vite es adecuado para una SPA o una aplicación web que no necesita SSR.
Nuxt encaja cuando se requiere SSR, SSG o una estrategia híbrida.
Para estado global, Pinia es la recomendación habitual para proyectos nuevos; Vuex no debería ser la opción automática por inercia.

Angular

Angular puede resolver aplicaciones medianas con una estructura consistente y tooling integrado.
SSR tiene sentido cuando existen páginas públicas indexables, se necesita HTML inicial o la experiencia del primer render lo justifica.
Para un panel interno autenticado, SSR puede no aportar suficiente valor para compensar la complejidad operativa.

7. Aplicaciones grandes y empresariales

7.1 Arquitectura por funcionalidades, no por tipo de archivo solamente

Ejemplo conceptual:

src/
  app/
    core/                 # configuración global y servicios transversales
    shared/               # UI y utilidades verdaderamente reutilizables
    features/
      customers/
        components/
        pages/
        data-access/
        domain/
        customers.routes.ts
      billing/
        components/
        pages/
        data-access/
        domain/
        billing.routes.ts
  environments/

7.2 Angular en escenarios empresariales

Prácticas recomendadas:

Lazy loading por rutas y límites de dominio.
Componentes pequeños y con responsabilidades claras.
Servicios y adaptadores para aislar APIs.
Formularios reactivos cuando el flujo de validación lo requiera.
Signals para estado reactivo local/derivado; RxJS para flujos asíncronos cuando corresponda.
Evitar lógica de negocio compleja dentro de templates o componentes.
Pruebas unitarias, de integración y end-to-end según riesgo.
Mantener al día dependencias y migraciones del framework.

7.3 React en escenarios empresariales

Hay que decidir y documentar, como mínimo:

Estructura por dominio y propiedad de cada módulo.
Routing y carga diferida.
Estrategia de datos remotos y caché.
Estado de UI, estado de servidor y estado persistente.
Formularios, validación y accesibilidad.
Límites entre Server Components y Client Components si se usa Next.js.
Sistema de diseño y reglas de composición.
Testing, linting, tipado y convenciones de imports.

7.4 Vue en escenarios empresariales

7.5 Monolito modular antes de microfrontends

8. Reactividad y reutilización de lógica: Hooks, Signals y Composition API

Estos modelos se parecen en el objetivo —componer UI y reutilizar lógica—, pero no son intercambiables.

Concepto	React	Angular	Vue
Estado local	`useState`, `useReducer`	`signal()` y otras APIs según el caso	`ref()`, `reactive()`
Valor derivado	Cálculo durante render; `useMemo` cuando aporta valor	`computed()`	`computed()`
Efectos / sincronización externa	`useEffect` y otros Hooks según la necesidad	`effect()`; también APIs del ciclo de vida y RxJS	`watch()`, `watchEffect()` y hooks del ciclo de vida
Reutilizar lógica	Custom Hooks	Servicios, funciones, Signals y RxJS	Composables
Estado global	Context o librerías externas cuando se necesitan	Servicios, Signals, RxJS o librerías según el caso	Pinia o composables para casos simples

Ejemplos mínimos:

React

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  const doubled = count * 2;

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      {doubled}
    </button>
  );
}

Angular

import { computed, signal } from "@angular/core";

const count = signal(0);
const doubled = computed(() => count() * 2);

count.update((value) => value + 1);

Vue

<script setup lang="ts">
import { computed, ref } from "vue";

const count = ref(0);
const doubled = computed(() => count.value * 2);
</script>

<template>
  <button @click="count++">{{ doubled }}</button>
</template>

9. Mobile: compartir tecnología no significa compartir toda la UI

Camino	Modelo	Ventajas	Límites
React Native + Expo	UI con componentes nativos; React y JavaScript/TypeScript.	Ecosistema mobile fuerte, herramientas de desarrollo y publicación integradas con Expo; comparte lógica y conocimientos con React web.	La UI web no se reutiliza directamente; algunas capacidades requieren módulos nativos o desarrollo específico.
Ionic + Angular + Capacitor	UI web en una WebView, con acceso a capacidades nativas mediante plugins.	Reutiliza conocimiento Angular, HTML/CSS y lógica web; útil para equipos web-first y aplicaciones de negocio.	La experiencia y rendimiento dependen del tipo de UI y del uso de la WebView; no es lo mismo que renderizar controles nativos.
Ionic Vue + Capacitor	Enfoque híbrido equivalente, usando Vue.	Aprovecha Vue y el ecosistema Ionic; acceso a cámara, geolocalización y otras capacidades mediante plugins compatibles.	Mismas consideraciones generales de WebView e integración nativa.
PWA	Aplicación web instalable con capacidades dependientes del navegador y sistema operativo.	Una sola entrega web, distribución sencilla y menor coste inicial.	Las APIs y capacidades disponibles varían según plataforma; no siempre sustituye una app publicada en tiendas.
Nativo	Swift/SwiftUI para iOS y Kotlin/Jetpack Compose para Android, entre otras opciones.	Máximo control sobre APIs y experiencia de cada plataforma.	Mayor coste si se mantienen implementaciones separadas.

React Native y Expo

Angular o Vue con Capacitor

Decisión mobile

Si la app es central para el producto y necesita una experiencia nativa cuidada: evaluar React Native + Expo y alternativas nativas.
Si es una app de negocio basada en formularios, catálogos, operaciones y contenido web, y el equipo es web-first: evaluar Ionic + Capacitor.
Si solo se necesita una experiencia móvil razonable y distribución sencilla: valorar primero una web responsive o PWA.
Si mobile es una posibilidad futura, no asumir que compartir framework equivale a compartir el frontend completo. Diseñar desde el principio una API estable y lógica de dominio separable.

10. CSS, diseño, gráficos, mapas y librerías de terceros

CSS y sistemas de diseño

Tailwind CSS: útil cuando el equipo quiere componer estilos desde utilidades y mantener un sistema visual coherente mediante tokens y configuración.
Bootstrap: útil cuando se busca un sistema conocido de grid, componentes y estilos con convenciones predefinidas.
CSS Modules, Sass o CSS estándar: alternativas válidas cuando el alcance o la organización de estilos lo justifican.
Librerías de componentes: conviene evaluar accesibilidad, soporte de teclado, theming, compatibilidad con SSR, tamaño del bundle y mantenimiento.

Gráficas y visualización

Opciones como Apache ECharts, Chart.js, D3 y otras librerías pueden integrarse en distintos frameworks. Algunas tienen wrappers específicos para React, Angular o Vue. Antes de elegir, revisar:

Volumen de datos y complejidad de visualización.
Interacción, zoom, exportación y accesibilidad.
Renderizado en servidor y dependencias de window/DOM.
Tamaño del bundle y posibilidad de importar módulos selectivos.
Licencia, mantenimiento y experiencia del equipo.

Mapas

Regla de dependencias

11. Buenas prácticas comunes, independientemente del framework

Arquitectura y código

Organizar por dominios o funcionalidades cuando el proyecto crece.
Mantener componentes pequeños, con responsabilidades explícitas.
Separar presentación, acceso a datos y reglas de negocio cuando ayude a probar y mantener el sistema.
Evitar estados duplicados y valores derivados almacenados innecesariamente.
Definir contratos tipados para APIs y errores.
Mantener un sistema de diseño y patrones de accesibilidad.
No crear una abstracción genérica hasta entender qué variaciones reales existen.

Rendimiento

Medir Core Web Vitals y rendimiento real en dispositivos representativos.
Optimizar imágenes, fuentes y recursos críticos.
Usar carga diferida para rutas y componentes no críticos.
Limitar scripts de terceros, analítica y widgets externos.
Evitar enviar JavaScript para contenido que no lo necesita.
Definir una política de caché coherente con la frescura requerida.
No confundir tamaño del bundle, tiempo de build, rendimiento del servidor y experiencia del usuario.

SEO y contenido

HTML semántico y contenido principal accesible sin depender de interacciones innecesarias.
Títulos, descripciones, canonical, Open Graph, sitemap y robots configurados correctamente.
URLs estables y enlaces rastreables.
Datos estructurados solo cuando sean apropiados y fieles al contenido.
Verificar el HTML generado y no confiar exclusivamente en que el buscador ejecute JavaScript.
Probar previews de redes sociales, paginación, redirecciones y páginas de error.

Calidad y entrega

TypeScript en proyectos donde aporte seguridad y mantenibilidad.
Lint, formato, pruebas unitarias, integración y end-to-end según el riesgo.
Pipeline CI que ejecute validaciones antes de publicar.
Entornos reproducibles, secretos fuera del código y dependencias revisadas.
Despliegues reversibles, monitoreo de errores y métricas de frontend.
Revisar accesibilidad con pruebas automáticas y manuales.
Documentar decisiones relevantes mediante ADRs (Architecture Decision Records).

12. Cómo comparar rendimiento sin caer en benchmarks engañosos

Para una comparación útil, construir prototipos equivalentes y medir varias dimensiones:

Dimensión	Qué medir
Carga inicial	LCP, FCP, CLS, TTFB y tamaño transferido.
Interactividad	INP, tiempo de ejecución de JavaScript y respuesta a interacciones representativas.
Navegación	Tiempo entre rutas, recursos descargados y experiencia tras la primera carga.
Renderizado servidor	TTFB bajo carga, CPU, memoria, throughput y errores.
Desarrollo	Tiempo para completar las mismas tareas, complejidad de pruebas y cambios posteriores.
Mantenibilidad	Claridad de límites, facilidad para incorporar un desarrollador y coste de actualización.
Operación	Coste de hosting, CDN, funciones/servidores, observabilidad y soporte.

Protocolo recomendado

Definir escenarios idénticos: landing de contenido, listado con filtros, formulario complejo y dashboard.
Usar versiones estables comparables y documentar las configuraciones.
Comparar la misma estrategia de renderizado cuando se evalúa el framework; luego comparar estrategias distintas como una segunda prueba.
Probar build de producción, no solo servidor de desarrollo.
Medir en dispositivos y redes representativos, incluyendo móviles de gama media.
Ejecutar suficientes repeticiones y reportar mediana y percentiles, no solo la mejor corrida.
Registrar bundle inicial, scripts ejecutados, solicitudes, memoria, CPU y resultados de Web Vitals.
Publicar el código, comandos, versiones y metodología para que otros puedan reproducir los resultados.

13. Matriz de decisión orientativa

Escenario	Primera opción a evaluar	Alternativas razonables	Por qué
Landing de contenido con SEO y carga rápida	Astro	HTML/CSS/JS, Next.js, Nuxt	Prioriza HTML y evita JavaScript innecesario por defecto.
Blog o documentación	Astro	Generador estático, Next.js, Nuxt	Contenido, SEO, CDN y mantenimiento sencillo.
Landing dentro de una plataforma React	Next.js o Astro según el grado de integración	HTML estático	Mantiene coherencia cuando comparte rutas, componentes o datos; Astro si es independiente y principalmente contenido.
SPA autenticada pequeña/mediana	React + Vite, Vue + Vite o Angular	Según experiencia del equipo	SSR suele ser opcional si SEO no importa.
Aplicación pública dinámica con SEO	Next.js, Nuxt o Angular SSR	Otras soluciones SSR maduras	Permiten generar HTML inicial y combinar estrategias por ruta.
Plataforma empresarial con múltiples equipos	Angular si sus convenciones encajan; React si el equipo ya lo domina	Vue/Nuxt con estándares claros	La gobernanza, experiencia y arquitectura pesan más que una clasificación abstracta.
Aplicación móvil con UI nativa	React Native + Expo	Desarrollo nativo	Permite construir apps iOS/Android con componentes nativos.
Aplicación de negocio web-first en tiendas móviles	Ionic + Capacitor con Angular o Vue	React + Capacitor, según necesidades	Reutiliza gran parte del enfoque web y conecta con capacidades nativas.
Experiencia móvil sencilla	Responsive/PWA	Capacitor	Menos complejidad si no se requieren capacidades nativas profundas.
Rendimiento inicial extremo como requisito diferencial	Prototipo con Astro o Qwik	Otras opciones con optimización cuidadosa	Evalúa JavaScript enviado, reactividad necesaria y complejidad real del producto.

14. Recomendación final: elegir para el producto y para el equipo

Una decisión razonable puede resumirse así:

Para una landing o un sitio de contenido: empieza evaluando Astro o incluso HTML/CSS/JS sin framework. El contenido y la entrega deben ser rápidos; añade interactividad solo donde sea necesaria.
Para una aplicación web pequeña o mediana: React, Angular y Vue son opciones válidas. Elige CSR si encaja con el producto y SSR/SSG si hay una razón concreta. En React, Next.js es una opción integral; en Vue, Nuxt; en Angular, la solución SSR soportada por la versión actual.
Para una aplicación empresarial grande: prioriza convenciones, módulos, calidad de herramientas, testing, migraciones y experiencia del equipo. Angular aporta integración y consistencia; React aporta flexibilidad y un ecosistema enorme, pero exige acuerdos explícitos; Vue también puede escalar con Nuxt, Pinia y convenciones bien mantenidas.
Para mobile: decide si necesitas UI nativa, una app web empaquetada o una PWA. React Native + Expo e Ionic + Capacitor resuelven necesidades distintas y no deben tratarse como equivalentes exactos.
Para rendimiento: mide el producto y el usuario real. El framework no compensa una arquitectura de carga deficiente, imágenes pesadas, demasiados scripts, caché incorrecta o APIs lentas.

La pregunta final no debería ser «¿cuál framework gana?», sino:

¿Qué combinación de framework, renderizado, arquitectura, entrega y capacidades del equipo nos permite construir el producto correcto, con buen rendimiento y el menor coste sostenible de evolución?