Elegir stack de UI no es elegir “un framework”, es elegir un modelo de ejecución, un modo de escalado organizacional y un TCO (Costo Total de Propiedad) para los próximos 2–5 años. Las decisiones caras en corporativo rara vez fallan por sintaxis; fallan por gobernanza, convivencia con legado, SSR/hidratación, latencia, dependencia del ecosistema y capacidad de escalar equipos.
1) La decisión correcta empieza por el “costo dominante”
Antes de comparar tecnologías, define qué te duele más (uno o dos dominantes, no diez):
- SSR + performance inicial (producto público / SEO / CWV)
- Formularios complejos y workflows (LOB/backoffice)
- UI avanzada basada en librerías JS (mapas, editores, visualización)
- Gobernanza multi-equipo (consistencia vs deriva)
- Micro-frontends (despliegue independiente por dominio/squad)
- Talento y rotación (capacidad real de contratación)
A partir de aquí, la elección deja de ser “React vs Angular vs Blazor” y pasa a ser “qué stack reduce mi costo dominante”.
2) SSR moderno e hidratación (estado actual, 2025–2026)
React: RSC implica elegir un meta-framework
React Server Components (RSC) cambian el paradigma: parte del árbol se renderiza en “servidor” antes del bundling, reduciendo JavaScript cliente y permitiendo modelos híbridos. Sin embargo, en producción RSC depende de integración a nivel bundler/framework: no es “SSR out-of-the-box” desde React puro, sino una capacidad que se materializa a través de un meta-framework/bundler que implemente el pipeline (por ejemplo, Next.js App Router y equivalentes).
Angular: SSR con hidratación no destructiva
Angular incorporó hidratación no destructiva: el cliente reutiliza el DOM SSR, evitando re-render completo y reduciendo el costo de arranque/“flicker”.
Blazor: render modes híbridos (incluye Auto)
Blazor Web Apps permite elegir render modes por componente (SSR estático vs interactividad Server/WASM/Auto). Esto elimina la falsa dicotomía “Server o WASM para toda la app” y habilita estrategias mixtas por pantalla/componente.
3) Blazor Server: el factor crítico es la latencia (y es TCO operativo)
Si consideras Blazor Server, debes tratar la latencia como requisito no funcional explícito: Blazor Server mantiene el estado UI en servidor y se comunica con el navegador mediante SignalR.
- Con latencia alta o red inestable, la UX se degrada porque muchas interacciones dependen del round-trip (percepción de “UI pesada”).
- El costo aparece como TCO operativo: dimensionamiento, escalado, reconexión, observabilidad de circuitos/errores, y experiencia en geografías remotas.
Decisión práctica
- Usuarios internos con red controlada y cercanía al datacenter: Blazor Server puede ser muy eficiente.
- Usuarios distribuidos o conectividad variable: necesitas mitigaciones (edge, regiones, estrategia híbrida/Auto, o inclinarte hacia modelos más client-centric según el caso).
4) Reactividad y estado: la granularidad importa (performance y mantenibilidad)
Angular: Signals integradas
Angular Signals apuntan a reactividad con dependencias granulares y un modelo oficial en el core.
React: Hooks + arquitectura de estado (decisión del equipo)
React provee primitives (Hooks), pero el resultado depende de lo que estandarices: estado local/global, “server state”, cachés e invalidación. Si no hay arquitectura de referencia, la deriva aparece rápido (especialmente en equipos grandes).
Blazor: actualización explícita y diseño de componentes
Blazor suele depender de patrones de componentes y actualizaciones explícitas; la “granularidad” es principalmente una responsabilidad de diseño (cómo particionas componentes y estado compartido).
5) Formularios complejos: donde se decide gran parte del corporativo
Si tu producto es form-heavy (validación async, cross-field, workflows, estados intermedios, guardado parcial), la elección debe optimizar consistencia y DX real:
- Angular tiende a destacar por su enfoque integral y predecible para formularios complejos.
- React puede ser excelente, pero requiere estandarizar librerías y patrones internos (si no, el mantenimiento se fragmenta).
- Blazor encaja muy bien cuando modelos y validaciones viven en .NET; el costo crece si necesitas widgets JS sofisticados (interop).
6) Interoperabilidad con ecosistema JS: dependencia real del roadmap
Este punto define muchas migraciones que “parecían simples” y terminaron caras.
- React/Angular: consumo directo del ecosistema JS/TS para mapas, editores, visualización y componentes avanzados.
- Blazor: si tu UI depende fuerte de librerías JS, el costo de JS interop puede ser material (wrappers, lifecycle, testing, performance). La interoperabilidad existe y debe presupuestarse como parte del diseño.
7) Gobernanza y “costo inicial”: aquí Angular tiene una ventaja subestimada
Decir “Angular cuesta más al inicio” es correcto, pero incompleto. Parte de ese costo se amortiza porque Angular incluye un workflow que estandariza cómo se genera y mantiene código.
Angular: CLI + Schematics como mitigación
Angular CLI usa schematics para generar código consistente y aplicar transformaciones controladas. Esto reduce variabilidad entre equipos y acelera onboarding, porque la estructura base se repite de forma predecible.
React: la gobernanza es obligatoria (no opcional)
En React, si no defines arquitectura de referencia (estructura, reglas, tooling, librerías permitidas, estrategia SSR/meta-framework), el costo se mueve del “inicio” al “mantenimiento” como deriva de dependencias y patrones.
Blazor: gobernanza en .NET y operación
Blazor encaja bien en organizaciones .NET por cohesión, pero su TCO depende de operación (si Server) y de interop (si JS-heavy).
8) Micro-frontends: si es requisito, decide temprano
Si necesitas micro-frontends con despliegue independiente, Module Federation es una base común en el ecosistema JS.
- React/Angular: suelen tener el camino más maduro (tooling, prácticas, experiencia de industria).
- Blazor: existen retos cuando se buscan múltiples instancias/aislamientos “clásicos” en una misma página.
9) TCO resumido (tendencia, no dogma)
- Angular: alto al inicio; tiende a bajar por estandarización y tooling integrado (CLI/schematics).
- React: bajo al inicio; tiende a subir si no hay gobernanza (decisiones dispersas + dependencia de meta-framework para SSR moderno).
- Blazor: medio; muy atractivo en .NET, pero sensible a latencia/operación si Server (SignalR) y a interop si el roadmap depende de ecosistema JS.
10) Cómo cerrar la decisión (PoC comparable + métricas actuales)
Si el objetivo es decidir, evita PoCs “demo”. Usa un PoC de 5 días con el mismo alcance:
- Login (idealmente OIDC) + autorización por roles
- 2 pantallas CRUD (list/detail)
- 1 formulario complejo (validación async + cross-field)
- Un componente “difícil” del roadmap (grid avanzado / mapa / editor)
- Testing mínimo: unit + integration + e2e (flujo crítico)
- Métricas: tamaño de artefactos, tiempos de interacción, esfuerzo CI, observabilidad
Conclusión
Blazor, Angular y React pueden resolver el 90% de los problemas de UI. La diferencia real está en cómo lo hacen y en cuánto cuesta sostenerlo:
- Blazor Server funciona muy bien cuando la latencia, la estabilidad de red y el escalado están validados; incorpora el costo operativo de una UI mantenida en servidor por SignalR como parte del TCO.
- React es una opción sólida si la estrategia incluye SSR moderno (RSC) y se adopta un meta-framework; la gobernanza (estándares y arquitectura de referencia) es el factor que vuelve el enfoque sostenible a escala.
- Angular es especialmente competitivo en entornos multi-equipo: CLI y schematics reducen variabilidad, aceleran estandarización y tienden a mejorar el TCO en el tiempo, incluso si el costo inicial es mayor.
Hasta aquí por hoy. Gracias por acompañarme.