⚛️ Frontend TECH RADAR 2026

Frontend Frameworks Comparison 2026

Análisis técnico de React 19, Angular 21, Astro 5, Svelte 5 y Vue 3.5 en proyectos de producción y rendimiento web.

Alberto Escobar Gallardo Software Architect & AI Engineering Specialist | AI Coding Agents Adoption Lead

11 de agosto de 2026 • 42 min de lectura

#Frontend#Astro#Angular#React#Vue#Svelte#Signals#SSG

🎨 Comparativa de frameworks frontend 2026

Estado del arte: landing pages vs. eShops vs. portales privados

Contexto: Comparativa técnica basada en Core Web Vitals reales (CrUX dataset), bundle size análisis (bundlephobia), y experiencia de producción. Angular 22 estable, Angular 23 en RC. TypeScript 5.x como estándar universal.

📋 Índice

Ecosistema 2026 — Estado del arte
Caso A — Landing pages y páginas públicas
Caso B — eShops y tiendas públicas
Caso C — Portales privados y apps internas
Caso D — Apps médicas, financieras y de campo (offline-first y PWA)
Caso E — Dashboards de alta frecuencia y fintech (real-time WebSockets y Canvas)
Métricas comparativas globales
Librerías UI y component frameworks
Matriz de decisión final

1. Ecosistema 2026

Estado del arte — ¿Dónde está cada framework hoy?

📖 Glosario de conceptos clave

📖 SSR (Server-Side Rendering)

El servidor genera el HTML completo antes de enviarlo al navegador. El usuario ve contenido inmediatamente aunque JS tarde en cargar. Clave para SEO y Core Web Vitals.

📖 SSG (Static Site Generation)

HTML generado en build time, no en cada request. Se sirve desde CDN — latencia mínima, sin servidor necesario. Ideal para contenido que no cambia frecuentemente.

📖 CSR (Client-Side Rendering)

El navegador descarga JS y construye el HTML en cliente. Malo para SEO y LCP inicial, pero óptimo para apps altamente interactivas tras carga inicial.

📖 Hydration & Islands Architecture

Hydration es el proceso de activar el HTML estático en cliente. Islands Architecture solo hidrata componentes interactivos, reduciendo el JS al mínimo.

📖 RSC (React Server Components)

Componentes que se ejecutan en servidor y nunca envían JS al cliente, reduciendo el tamaño del bundle final.

📖 Core Web Vitals (LCP, INP, CLS)

Métricas clave de rendimiento y experiencia de usuario que afectan directamente al SEO en motores de búsqueda.

📖 Signals & Resumability

Signals actualiza solo el DOM dependiente sin diffing global. Resumability (Qwik) reanuda el estado desde HTML con 0ms de hidratación.

Framework	Versión 2026	Estrategia render	SSR	SSG	TypeScript	Mantenedor
Next.js	15.x / 16.0	SSR/SSG/RSC/CSR	✅	✅	✅ Nativo	Vercel
Angular	22 (23 RC)	SSR/CSR/SSG	✅	✅	✅ Obligatorio	Google
Nuxt	4.x	SSR/SSG/CSR	✅	✅	✅ Nativo	Nuxt Labs
Astro	5.x	SSG/SSR/Islands	✅	✅	✅ Nativo	Astro
SvelteKit	2.x / 3.x	SSR/SSG/CSR	✅	✅	✅ Nativo	Svelte team
React Router	v7	SSR/SSG/CSR	✅	✅	✅ Nativo	Remix team
Remix	3.x (Experimental)	SSR puro	✅	❌	✅ Nativo	Remix team
React + Vite	React 19	CSR puro	❌	❌	✅	Meta
Vue + Vite	Vue 3.5	CSR puro	❌	❌	✅	Evan You
Qwik	2.x	Resumability	✅	✅	✅	Builder.io

Tendencias clave 2026

Tendencia                           Impacto
──────────────────────────────────────────────────────
✅ Signals como primitiva reactiva  Angular 17+, Vue, Svelte, Qwik
✅ React Compiler                   Respuesta de Meta a Signals (memoización aut.)
✅ RSC mainstream                   Next.js 15.x / 16.0 por defecto
✅ Edge rendering                   Cloudflare Workers, Vercel Edge
✅ TypeScript 5 obligatorio         Todos los frameworks principales
✅ Vite como bundler universal      Mayoría de frameworks (Astro, Nuxt, SvelteKit, React+Vite)
⚠️ Next.js usa Turbopack propio     Next.js migró de Webpack a Turbopack (no Vite)
⚠️ React dominante pero cuestionado Svelte/Solid ganan tracción DX
⚠️ Angular renaissance             Signals + Standalone = menos boilerplate

📖 Signals: Primitiva reactiva que actualiza solo los componentes que consumen un valor cuando este cambia. Más eficiente que el Virtual DOM diffing de React. Angular los adoptó en v17, Vue los tiene desde siempre (ref/computed), Svelte es signals por diseño. 📖 Edge Rendering: Ejecutar SSR en servidores distribuidos geográficamente (CDN edge nodes) en vez de un datacenter central. Latencia <50ms globalmente. 📖 Resumability (Qwik): Técnica donde el servidor serializa el estado JS completo en el HTML. El cliente “reanuda” sin re-ejecutar el JS — 0ms de hydration.

2. Caso A — Landing pages y páginas públicas

Caso A — Landing pages / páginas públicas / blogs / sitios de marketing

Requisitos clave: SEO máximo, Core Web Vitals verdes, carga <1s, poco o nulo JS interactivo, fácil gestión de contenido, CDN-ready.

📖 LCP (Largest Contentful Paint): Tiempo hasta que el elemento visual más grande es visible. Google penaliza >2.5s. Es la métrica más importante para percepción de velocidad. 📖 CLS (Cumulative Layout Shift): Cuánto se mueve el layout mientras carga. Anuncios/imágenes sin dimensiones fijas lo disparan. Penaliza SEO y UX. 📖 TTI (Time to Interactive): Tiempo hasta que la página responde a input del usuario. Con mucho JS, TTI puede ser 5s aunque LCP sea 1s. 📖 CDN (Content Delivery Network): Red de servidores distribuidos globalmente. Un HTML estático en CDN llega desde el nodo más cercano al usuario — latencia <20ms vs 200ms desde datacenter único.

Ranking para landing pages / páginas públicas

Posición  Framework             Estrategia      Por qué
──────────────────────────────────────────────────────────────────────
🥇 1º    Astro 5.x              SSG + Islands   0KB JS por defecto, HTML puro
🥈 2º    Next.js 15.x / 16.0    SSG + RSC       Ecosistema enorme, RSC reduce JS
🥉 3º    SvelteKit 2.x/3.x      SSG             Bundle mínimo, sintaxis simple
   4º    Nuxt 4                 SSG             Vue ecosystem, buen DX
   5º    Angular 22             SSG (NgOptImg)  Válido pero over-engineered aquí
   6º    React + Vite           CSR             ❌ Malo para SEO sin SSR wrapper

Métricas Core Web Vitals reales (sitio marketing típico, misma página)

Framework	LCP	CLS	INP	JS bundle inicial	Lighthouse Score
Astro	0.6s	0.01	40ms	~0 KB	98–100
Next.js SSG	0.8s	0.02	55ms	~85 KB	95–98
SvelteKit SSG	0.7s	0.01	45ms	~15 KB	96–99
Nuxt SSG	0.9s	0.02	60ms	~95 KB	93–97
Angular 22 SSG (zoneless)	1.0s	0.02	60ms	~85–100 KB	91–95
React + Vite CSR	2.8s	0.08	120ms	~150 KB	65–75

📖 INP (Interaction to Next Paint): Reemplazó a FID en 2024. Mide responsividad de TODAS las interacciones, no solo la primera. <200ms = bueno.

Bundle size comparativo (gzip, hello world + router)

Astro       ~0 KB     ▏                  (0 JS sin componentes interactivos)
Svelte      ~15 KB    ██▏
Next.js     ~85 KB    █████████
Nuxt        ~95 KB    █████████▌
Angular 22  ~85–100 KB █████████▌        (zoneless default v21+ — sin zone.js)
React+Vite  ~150 KB   ███████████████

⚠️  Angular 14–16 + NgModules + zone.js pesaba ~140–155 KB
    Angular 22 zoneless + standalone + @defer: ~85–100 KB (-40% respecto legacy)
    zone.js eliminado: -33 KB minificado / -12 KB gzip

Veredicto landing pages

🏆 Astro es el ganador claro para landing pages, portfolios, documentación, blogs y sitios de marketing. 0 KB de JS por defecto junto con Islands solo donde se necesita interactividad garantiza un Lighthouse de 100 de forma consistente. Next.js es una opción válida si el equipo ya trabaja con React y quiere uniformidad con otras aplicaciones. Evitar Angular y React+Vite puro — el exceso de JS innecesario perjudica el SEO y los Core Web Vitals.

3. Caso B — eShops y tiendas públicas

Caso B — eShops / tiendas públicas / catálogos de producto

Requisitos clave: SEO crítico (fichas producto indexadas), Core Web Vitals verdes, interactividad media-alta (carrito, filtros, búsqueda), datos dinámicos (stock, precios), integraciones (Stripe, Algolia, CMS), alta conversión.

📖 ISR (Incremental Static Regeneration): Regenera páginas estáticas en background cada X segundos sin rebuild completo. Perfecto para fichas de producto — HTML estático servido desde CDN pero datos frescos cada 60s. 📖 PPR (Partial Prerendering): Característica Next.js 15.x/16.0. Combina HTML estático (shell de la página) con partes dinámicas en streaming. La ficha de producto carga instantánea, el precio/stock llega en stream. 📖 Headless Commerce: Arquitectura donde el frontend es independiente del backend de tienda (Shopify Storefront API, Medusa, Commerce Layer). El framework solo consume APIs — máxima flexibilidad. 📖 Hydration cost: En eShops con 50+ componentes por página (header, filtros, carrito, recomendaciones), el coste de hidratar todo el JS puede ser 3-5s en móvil gama media.

Ranking para eShops

Posición  Framework             Estrategia           Por qué
────────────────────────────────────────────────────────────────────────────
🥇 1º    Next.js 15.x / 16.0    ISR + PPR + RSC      Estándar industria, Shopify lo usa
🥈 2º    Nuxt 4                 ISR + SSR            Vue DX excelente, Nuxt Commerce
🥉 3º    Astro 5.x              SSG + Islands        Para catálogos simples / bajo JS
   4º    SvelteKit 2.x/3.x      SSR + ISR            Bundle pequeño, buen perf
   5º    React Router v7        SSR / pre-render     Excelente para carrito/checkout
   6º    Angular 22             SSR + NgOptImg       Válido en enterprise, más setup

Métricas para ficha de producto típica (móvil, 3G rápido)

Framework	LCP	TTI	Bundle JS	ISR	Headless DX	Score conversión
Next.js 15.x / 16.0 PPR	0.9s	1.8s	~95 KB	✅	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Nuxt 4	1.1s	2.2s	~105 KB	✅	⭐⭐⭐⭐	⭐⭐⭐⭐
Astro 5.x	0.7s	1.0s	~20 KB	✅	⭐⭐⭐	⭐⭐⭐⭐
SvelteKit 2.x/3.x	1.0s	1.9s	~25 KB	✅	⭐⭐⭐	⭐⭐⭐⭐
React Router v7	1.2s	2.0s	~90 KB	✅	⭐⭐⭐⭐	⭐⭐⭐⭐
Angular 22 (zoneless)	1.2s	2.2s	~90–105 KB	✅	⭐⭐⭐	⭐⭐⭐

Integraciones clave eCommerce 2026

Integración          Next.js   Nuxt    Astro   SvelteKit   Angular
────────────────────────────────────────────────────────────────────
Shopify Storefront   ✅⭐⭐⭐⭐⭐  ✅⭐⭐⭐⭐  ✅⭐⭐⭐   ✅⭐⭐⭐       ✅⭐⭐
Medusa (OSS)         ✅⭐⭐⭐⭐⭐  ✅⭐⭐⭐   ✅⭐⭐⭐   ✅⭐⭐⭐       ✅⭐⭐
Stripe               ✅⭐⭐⭐⭐⭐  ✅⭐⭐⭐⭐  ✅⭐⭐⭐   ✅⭐⭐⭐       ✅⭐⭐⭐
Algolia (búsqueda)   ✅⭐⭐⭐⭐⭐  ✅⭐⭐⭐⭐  ✅⭐⭐⭐   ✅⭐⭐⭐       ✅⭐⭐
Contentful / Sanity  ✅⭐⭐⭐⭐⭐  ✅⭐⭐⭐⭐  ✅⭐⭐⭐⭐  ✅⭐⭐⭐       ✅⭐⭐

Veredicto eShops

🏆 Next.js 15.x / 16.0 es el estándar de facto para eCommerce en 2026. PPR + ISR + RSC resuelven exactamente el problema del eShop: contenido mayoritariamente estático con partes dinámicas (precio, stock, carrito). Shopify, Vercel Commerce y la mayoría de agencias digitales lo utilizan. Nuxt 4 es una excelente alternativa si el equipo prefiere Vue. Astro solo se recomienda para catálogos sencillos con poca interactividad y sin carrito complejo.

4. Caso C — Portales privados y apps internas

Caso C — Portales privados / áreas de cliente / apps internas de empresa

Requisitos clave: SEO irrelevante (detrás de auth), interactividad alta, estado global complejo, formularios avanzados, tablas de datos, dashboards, larga vida útil del proyecto, equipos grandes, mantenibilidad.

📖 SPA (Single Page Application): App que carga una sola vez y navega sin recargar página. Ideal para apps privadas — sin necesidad de SSR/SEO, máxima interactividad. 📖 Estado global: Datos compartidos entre múltiples componentes de la app (usuario logado, permisos, carrito, notificaciones). Requiere gestión explícita: NgRx, Zustand, Pinia, etc. 📖 Code splitting: División del bundle JS en chunks que se cargan bajo demanda. Angular y Next.js lo hacen automáticamente por ruta — la app interna no carga todo el JS al inicio. 📖 Tree shaking: Eliminación de código JS no usado durante el build. TypeScript + bundlers modernos eliminan librerías enteras si no se importan. 📖 NgRx: Librería de gestión de estado para Angular basada en Redux (acciones, reducers, selectores). Verboso pero predecible — estándar en proyectos Angular enterprise. 📖 Monorepos (Nx, Turborepo, pnpm workspaces): Herramienta estándar en 2026 para portales privados. Permiten compartir código (interfaces, UI components) entre múltiples apps internas con builds cacheados y consistencia de dependencias.

Ranking para portales privados / apps internas

Posición  Framework             Estrategia    Por qué
──────────────────────────────────────────────────────────────────────────────
🥇 1º    Angular 22            SPA / CSR     Diseñado para esto. Opinado = consistencia
🥈 2º    Next.js 15.x / 16.0   SPA / CSR     Flexibilidad, RSC para dashboards con datos
🥉 3º    React + Vite          SPA / CSR     Libertad total, ecosistema enorme
   4º    Nuxt 4                SPA / CSR     Vue, buen DX, menos enterprise que Angular
   5º    SvelteKit 2.x/3.x     SPA / CSR     Bundle mínimo, curva baja, menos ecosystem
   6º    Astro 5.x             ❌            No diseñado para apps altamente interactivas

Por qué Angular 22 domina portales enterprise

Característica              Angular 22         React/Next.js      Vue/Nuxt
────────────────────────────────────────────────────────────────────────────
Estructura opinada          ✅ Sí (DI, módulos) ❌ Libre           ⚠️ Semi
TypeScript integrado        ✅ Obligatorio      ⚠️ Opcional        ⚠️ Opcional
Inyección de dependencias   ✅ Nativo           ❌ Librerías extra  ❌
Sistema de formularios      ✅ Reactivos+Template ⚠️ react-hook-form ⚠️ VeeValidate
Estado global               ✅ NgRx / Signals   ⚠️ Zustand/Redux   ⚠️ Pinia
Lazy loading rutas          ✅ Automático       ✅ Automático       ✅
CLI y generadores           ✅ ng generate      ⚠️ Manual          ⚠️ nuxi
Testing integrado           ✅ Karma/Jest+Jasmine ⚠️ Vitest/Jest   ⚠️ Vitest
Migraciones entre versiones ✅ ng update + schematics ⚠️ Manual     ⚠️
Equipos grandes (>10 devs)  ✅ Convenciones forzadas ⚠️ Requiere disciplina ⚠️

Métricas para portal privado (dashboard con 20 rutas, 50 componentes)

Framework	Bundle inicial	Lazy load por ruta	TTI inicial	DX formularios	Mantenibilidad
Angular 22 (zoneless+signals)	~90–105 KB	✅ Auto	1.4s	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Next.js 15.x / 16.0	~95 KB	✅ Auto	1.4s	⭐⭐⭐⭐	⭐⭐⭐⭐
React + Vite	~150 KB	⚠️ Manual	1.6s	⭐⭐⭐⭐	⭐⭐⭐
Nuxt 4	~105 KB	✅ Auto	1.5s	⭐⭐⭐⭐	⭐⭐⭐⭐
SvelteKit 2.x/3.x	~25 KB	✅ Auto	1.0s	⭐⭐⭐	⭐⭐⭐

Angular 22 — novedades relevantes para portales enterprise

Feature                     Desde    Impacto
────────────────────────────────────────────────────────────────
Signals (reactivity)        v17      Menos boilerplate, mejor perf
Standalone components       v15+     Sin NgModules obligatorios
Control flow @if/@for       v17      Sintaxis más limpia en templates
Deferred loading @defer     v17      Lazy load de componentes por viewport
Hydration incremental       v18      Mejor SSR para portales híbridos
Material 3 (M3)             v17+     Design system actualizado
Signal-based inputs/outputs v19+     API más simple que @Input/@Output
Angular 23 (RC)             2026 Q4  Reactivity model completo, mejoras de rendimiento SSR

📖 Zoneless Angular: Desde v18 experimental, v21 estable y DEFAULT, v22 madurez completa con Signals totalmente integrados. Elimina zone.js (~33KB min / ~12KB gzip) del bundle. Resultado: Angular 22 con zoneless + standalone components (default v17+) + signals (v19+) baja de ~155KB legacy a ~85–105KB (app real con router+forms+http). Hello world mínimo llega a ~50KB gzip. Mejora también TTI y startup time al eliminar el monkey-patching de APIs del navegador que zone.js hacía. 📖 Standalone components: Componentes Angular sin necesidad de declararse en NgModule. Simplifica la arquitectura y permite lazy loading más granular.

Veredicto portales privados

🏆 Angular 22 es el ganador para portales empresariales — su naturaleza prescriptiva es una ventaja, no una limitación, en equipos grandes y proyectos de larga duración. Next.js es una excelente opción si el portal también necesita partes públicas (SSR mixto público/privado). React + Vite es válido para startups o equipos pequeños que priorizan la flexibilidad. Evitar Astro — no está diseñado para aplicaciones con alta interactividad y gestión de estado complejo.

5. Caso D — Apps médicas, financieras y de campo (offline-first y PWA)

Caso D — Apps médicas / financieras / trabajo de campo

Requisitos clave: Sincronización transparente en segundo plano, persistencia local robusta con IndexedDB, soporte PWA instalable sin dependencia de red inicial, tolerancia a desconexiones de red prolongadas y resolución de conflictos (CRDTs).

📖 Offline-First: Arquitectura donde la aplicación guarda todos los datos localmente primero (IndexedDB/SQLite WASM) y se sincroniza con el servidor cuando hay conexión disponible. 📖 CRDT (Conflict-free Replicated Data Types): Estructura de datos que permite a múltiples dispositivos modificar el estado independientemente y fusionar cambios sin conflictos. 📖 Background Sync API: API del navegador que permite delegar al Service Worker la ejecución de peticiones HTTP diferidas aunque la pestaña esté cerrada.

Ranking para apps offline-first y PWA

Posición  Framework / Stack             Estrategia              Por qué
────────────────────────────────────────────────────────────────────────────────────────
🥇 1º    React 19 / Svelte + RxDB       IndexedDB + CRDT        RxDB / ElectricSQL proveen sync reactivo local-first
🥈 2º    Angular 22 + @angular/pwa      Service Worker Nativo   Manejo de assets offline e IndexedDB integrado con RxJS
🥉 3º    Vue 3.5 + Vite PWA + RxDB      IndexedDB + SW          Plugin Vite PWA maduro con Workbox + Pinia persistence
   4º    Next.js / Nuxt PWA             SSR / PWA Híbrido       Complicado por dependencias de hidratación de servidor

Comparativa de tecnologías offline-first

Solución	Motor Local	Sync Protocol	Cifrado Local	Manejo de Conflictos
RxDB	IndexedDB / Dexie	WebSockets / REST	✅ AES-256	✅ CRDT / Custom
ElectricSQL	SQLite WASM	Postgres Logical Sync	✅ SQLite Enc	✅ CRDT Nativo
WatermelonDB	IndexedDB	Custom Sync Engine	⚠️ Manual	⚠️ Manual
Angular SW + RxJS	Cache API / IDB	Service Worker Queues	⚠️ Manual	⚠️ Last-Write-Wins

Veredicto apps offline-first

🏆 React 19 o Svelte 5 combinados con RxDB o ElectricSQL representan la mejor opción para aplicaciones offline-first médicas o financieras. Angular 22 con @angular/pwa ofrece una experiencia out-of-the-box sólida si se trabaja dentro del ecosistema empresarial de Google con RxJS.

6. Caso E — Dashboards de alta frecuencia y fintech (real-time WebSockets y Canvas)

Caso E — Dashboards de alta frecuencia / trading / fintech

Requisitos clave: Procesamiento y renderizado de miles de eventos por segundo (orderbooks, ticks bursátiles, telemetría IoT), prevención de cuellos de botella en el Virtual DOM diffing y latencia de renderizado <16ms (60 FPS constante).

📖 Orderbook: Tabla de libro de órdenes en tiempo real con cambios de oferta/demanda a frecuencias de milisegundos. 📖 Virtual DOM Bottleneck: Ocurre cuando re-renderizar miles de nodos React por segundo satura el hilo principal del navegador. 📖 Canvas 2D / WebGL Direct Rendering: Renderizar gráficos directamente en un elemento <canvas> puenteando la manipulación del DOM HTML.

Ranking para dashboards de alta frecuencia

Posición  Framework / Render Engine     Estrategia              Por qué
────────────────────────────────────────────────────────────────────────────────────────
🥇 1º    SolidJS / Svelte 5 + Canvas    Fine-grained Signals    Sin Virtual DOM, actualización directa de nodos/canvas
🥈 2º    Vanilla JS + WebGL / Canvas2D  Direct Buffer Update    0 overhead de framework, máximo rendimiento numérico
🥉 3º    React 19 + Refs desconectadas  Bypass React Re-render  Usar React solo para layout shell y canvas refs para data
   4º    Angular 22 + NgZone.runOutside  Zone Bypass + Canvas    Ejecución fuera de la detección de cambios de Angular

Rendimiento de renderizado en alta frecuencia (10.000 updates/seg)

Enfoque	FPS sostenido	CPU Usage	GC Pauses (Jank)	Facilidad DX
SolidJS + Canvas 2D	60 FPS	18%	Casi nulo	⭐⭐⭐⭐
Svelte 5 (Runes) + PixiJS	60 FPS	20%	Nulo	⭐⭐⭐⭐⭐
Vanilla JS + WebGL	60 FPS	12%	0 ms	⭐⭐
React 19 (State tradicional)	14 FPS	92%	Frecuentes	⭐⭐⭐⭐⭐
React 19 (Uncontrolled Canvas)	60 FPS	22%	Bajo	⭐⭐⭐

Veredicto dashboards de alta frecuencia

🏆 SolidJS o Svelte 5 ganan por su reactividad de grano fino (fine-grained reactivity) que no requiere Virtual DOM diffing. Para casos extremos de fintech o trading en tiempo real, desvincular el flujo de datos del framework hacia un Canvas 2D / WebGL nativo es la estrategia arquitectónica imperativa.

7. Métricas comparativas globales

Comparativa global de los 5 casos de uso

Framework	Landing SEO	eShop	Portal Privado	Offline PWA	Real-Time Fintech	Bundle	DX	Talento
Astro 5.x	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐	⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Next.js 15.x / 16.0	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Angular 22 (zoneless)	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
Nuxt 4	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
SvelteKit 2.x/3.x	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐
SolidJS / React 19	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐

Resumen visual por caso de uso

                    LANDING   eSHOP   PORTAL   OFFLINE PWA   REAL-TIME
                    ───────   ─────   ──────   ───────────   ─────────
Astro 5.x             🥇        🥉       ❌         ❌           ❌
Next.js 15.x / 16.0   🥈        🥇       🥈         ──           ──
Angular 22          ──        ──       🥇         🥈           ──
Nuxt 4              ──        🥈       ──         ──           ──
SvelteKit 2.x/3.x   🥉        ──       ──         🥇           🥇
SolidJS / React 19  ──        ──       🥉         🥇           🥇

Tamaño de bundle inicial por framework (gzip)

Astro       ~0–5 KB    ▏                  (sin JS si no hay islands)
Svelte      ~15 KB     ██▏
Next.js     ~85 KB     █████████
Angular 22  ~85–105 KB █████████▌         (zoneless default + standalone + @defer)
Nuxt        ~95 KB     █████████▌
React Router ~88 KB     █████████▏
React+Vite  ~150 KB    ███████████████

📖 Angular 22 bundle desglosado:

zone.js eliminado por defecto (v21+): -33 KB min / -12 KB gzip

Standalone components (sin NgModules): -10–15 KB adicionales

@defer bloques: carga diferida de componentes hasta que son visibles

Signals: menos código de change detection generado en build

Resultado total vs Angular legacy: de ~155 KB → ~85–105 KB (-40%)

⚠️ Angular 14–16 con NgModules + zone.js: ~140–155 KB (lo que muchos benchmarks aún comparan) ✅ Angular 22 optimizado con todas las features modernas: competitivo con Next.js y Nuxt

6. Librerías UI

Librerías UI & component frameworks 2026

📖 Design System: Conjunto de componentes, tokens de diseño (colores, tipografía, espaciado) y guías de uso que garantizan consistencia visual en toda la app. 📖 Web Components: Estándar nativo del navegador para crear componentes reutilizables independientes del framework (Custom Elements + Shadow DOM). Funcionan en Angular, React, Vue sin adaptadores. 📖 Shadow DOM: Encapsulación DOM de los Web Components — sus estilos CSS no se filtran hacia fuera ni reciben estilos externos. Máximo aislamiento. 📖 Headless UI: Librería que provee comportamiento y accesibilidad de componentes (modal, dropdown, tooltip) sin estilos visuales propios. Tú pones el CSS. Ejemplos: Radix UI, Headless UI, Ark UI. 📖 Accessibility (a11y): Grado en que una interfaz es usable por personas con discapacidades. WCAG 2.2 es el estándar. Componentes como modales, tooltips y selects tienen reglas ARIA complejas.

Categorías de librerías UI

Categoría                   Ejemplos                        Cuándo usar
────────────────────────────────────────────────────────────────────────────────
Design Systems completos    Material, Ant Design, Fluent     Apps enterprise consistentes
Component libraries CSS      Shadcn/ui, DaisyUI, Flowbite     Personalización máxima
Headless (solo behavior)    Radix UI, Headless UI, Ark UI     Design systems propios
Web Components frameworks   Lit, FAST, Stencil               Multi-framework, design tokens
Tailwind-based              Shadcn, Flowbite, Preline         Rapid prototyping

Tabla comparativa — librerías UI principales 2026

Librería	Framework	Componentes	Accesibilidad	Personalización	Tamaño	Mantenimiento
Angular Material (M3)	Angular only	~35	⭐⭐⭐⭐⭐	⭐⭐⭐	Medio	Google ✅
PrimeNG	Angular only	~90+	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Grande	PrimeTek ✅
Shadcn/ui	React/Next.js	~50	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	0 (copy-paste)	Community ✅
Radix UI	React	~30	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Pequeño	WorkOS ✅
Ant Design	React	~70+	⭐⭐⭐⭐	⭐⭐⭐	Grande	Alibaba ✅
MUI (Material)	React	~60+	⭐⭐⭐⭐	⭐⭐⭐	Grande	Community ✅
Vuetify 3	Vue/Nuxt	~80+	⭐⭐⭐⭐	⭐⭐⭐⭐	Grande	Community ✅
PrimeVue	Vue/Nuxt	~90+	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Grande	PrimeTek ✅
Lit + Shoelace	Web Components	~40	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Pequeño	Community ✅
FAST (Microsoft)	Web Components	~40	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Medio	Microsoft ✅
DaisyUI	Tailwind/Any	~50	⭐⭐⭐	⭐⭐⭐⭐⭐	~2KB	Community ✅
Flowbite	Tailwind/Any	~60	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Pequeño	Themesberg ✅

Librerías UI por caso de uso

Caso de uso              Recomendación principal        Alternativa
────────────────────────────────────────────────────────────────────────────
Portal Angular enterprise  Angular Material M3 + PrimeNG  Spartan UI (Shadcn para Angular)
Portal React/Next.js       Shadcn/ui + Radix UI           Ant Design, MUI
Portal Vue/Nuxt            PrimeVue                       Vuetify 3
eShop Next.js              Shadcn/ui (copy-paste=control)  Flowbite
eShop Vue/Nuxt             PrimeVue o DaisyUI             Vuetify
Landing cualquier fw       DaisyUI / Flowbite / Tailwind  Ninguna (CSS puro)
Design system corporativo  Lit + Shoelace (Web Components) FAST (Microsoft)
multi-framework            Lit + Shoelace                 FAST

Web Components — ¿cuándo tienen sentido?

📖 Stencil: Compilador que genera Web Components desde código TypeScript con API similar a React. Usado por Ionic Framework para sus componentes. 📖 Lit: Librería Google para crear Web Components con sintaxis declarativa. ~5KB, muy ligera. 📖 FAST (Microsoft): Framework Web Components de Microsoft, base de Fluent UI Web Components. Enfocado en accesibilidad y enterprise.

Escenario                                    ¿Web Components?
──────────────────────────────────────────────────────────────────────────
Organización con múltiples frameworks        ✅ SÍ — componente funciona en todos
Design system compartido entre Angular+React ✅ SÍ — Lit/FAST como base
App single-framework Angular                 ⚠️ Solo si ya tienes WC existentes
Startup con un solo equipo frontend          ❌ Overhead innecesario
Microfrontends con distintos frameworks      ✅ SÍ — aislamiento perfecto

📖 Microfrontends: Arquitectura donde distintos equipos desarrollan partes del frontend de forma independiente, potencialmente con distintos frameworks. Web Components como lenguaje común elimina fricciones.

Shadcn/ui — el paradigma copy-paste que cambió todo

Modelo tradicional          Modelo Shadcn/ui
────────────────────────    ────────────────────────────────────
npm install librería        npx shadcn add button
Actualiza → rompe estilos   Tú posees el código → control total
CSS difícil de override     Tailwind clases modificables directo
Bundle con todo incluido    Solo el código que usas
Versión fija del proveedor  Tu repo, tu versión, tus cambios

⚠️ Spartan UI: Port de Shadcn/ui para Angular c## 10. Frameworks de Web Components

Frameworks nativos para crear Web Components

📖 Custom Elements: API del navegador para definir tus propios tags HTML (<mi-boton>). Soportado al 100% en todos los navegadores modernos desde 2020. 📖 Shadow DOM: DOM encapsulado dentro del componente. Sus estilos CSS no se filtran hacia fuera ni reciben estilos externos — máximo aislamiento. 📖 Lit: Librería Google (~5KB) sobre Web Components nativos. Reactividad declarativa, templates con tagged literals, Signals en v3. Sin Virtual DOM. 📖 Stencil: Compilador (no librería) que genera Web Components estándar desde TypeScript+JSX. Output = WC puros sin dependencia de Stencil en runtime del consumer.

Comparativa de frameworks de Web Components 2026

Framework	Runtime	TypeScript	Reactividad	Output	Mantenedor	Caso ideal
Lit 3	~5 KB	✅	Signals	WC nativos	Google	Design systems
Stencil 4	~0 KB	✅	Decorators	WC compilados puros	Ionic	Librerías distribuidas npm
FAST 2	~12 KB	✅	Observable	WC nativos	Microsoft	Enterprise/Fluent UI
Shoelace/Web Awesome	~20 KB	✅	Lit-based	WC listos para usar	Font Awesome	UI kit agnostic
Vanilla WC	0 KB	⚠️ Manual	Manual	WC nativos	—	Componentes simples

Cuándo usar Web Components vs componentes de framework

Escenario                                    Recomendación
─────────────────────────────────────────────────────────────────────
Design system en Angular + React + Vue       ✅ Lit o Stencil — universales
Librería npm distribuible                    ✅ Stencil — 0KB en consumer
Microfrontends multi-framework               ✅ WC como contrato entre MFEs
App single-framework Angular                 ❌ Angular Components son mejores
App single-framework React                   ❌ React + Radix/Shadcn
Componente simple sin dependencias           ✅ Vanilla Custom Element
Icons / tokens diseño compartidos            ✅ WC mínimo sin Shadow DOM
Widget embebible en cualquier web            ✅ WC o Vanilla JS

Lit 3 — estándar de facto en Web Components

Ventajas                                  Limitaciones
──────────────────────────────────────    ───────────────────────────────
✅ ~5KB total                             ⚠️ SSR limitado (experimental)
✅ Sin build step necesario               ⚠️ Shadow DOM complica theming global
✅ Signals en v3                          ⚠️ Formularios nativos + Shadow DOM friction
✅ Interop con cualquier framework        ⚠️ Ecosistema menor que React/Angular
✅ Google lo usa en material.io           ⚠️ No hay router nativo
✅ TypeScript first

11. Vanilla JS, HTML y CSS

¿Cuándo tiene sentido no usar framework?

📖 Vanilla JS: JavaScript puro del navegador sin librerías. En 2026 incluye nativamente: Fetch API, ES Modules, CSS Custom Properties, CSS Grid/Flexbox, Web Animations API, IntersectionObserver, Web Components. 📖 CSS Custom Properties: Variables nativas CSS (--color-primary: #333). Funcionan en runtime, se modifican con JS, respetan la cascada. Sin preprocesador necesario. 📖 ES Modules: Sistema de módulos nativo (import/export). Sin bundler para proyectos simples — el navegador resuelve imports directamente. 📖 Progressive Enhancement: La web funciona sin JS (HTML puro), JS añade capas de mejora progresiva. Máxima resiliencia y accesibilidad. 📖 Alpine.js: Librería ~7KB con directivas reactivas en HTML (x-data, x-bind). Para webs server-rendered que necesitan interactividad sin SPA. 📖 HTMX: Extiende HTML con atributos para AJAX/SSE/WebSocket sin escribir JS. El servidor devuelve HTML fragmentado, no JSON.

Casos donde Vanilla JS es la elección correcta

Caso de uso                               Vanilla JS    Framework
──────────────────────────────────────────────────────────────────────
Widget embebible en cualquier web         ✅ SÍ         ❌ demasiado peso
Script de terceros (analytics, chat)      ✅ SÍ         ❌ conflictos versión
Landing page sin interactividad           ✅ SÍ         ⚠️ Astro también válido
Prototipo rápido / proof of concept       ✅ SÍ         ⚠️ según duración
Microinteracción aislada (1 componente)   ✅ SÍ         ❌ overhead
CDN snippet / bookmarklet                 ✅ SÍ         ❌ imposible
Juego canvas / WebGL simple               ✅ SÍ         ❌ framework no ayuda
App con >10 rutas y estado compartido     ❌ NO         ✅ framework necesario
Equipo >3 personas, largo plazo           ❌ NO         ✅ mantenibilidad

Espectro de peso: misma funcionalidad contador reactivo

Vanilla JS puro    ~0.5 KB  ▏
Alpine.js          ~7 KB    █▏
Petite-vue         ~6 KB    █▏
Htmx               ~14 KB   ██▏
Preact             ~4 KB    ▏
Lit                ~5 KB    █▏
Svelte (compilado) ~15 KB   ██▏
React              ~45 KB   █████▏
Angular (mínimo)   ~90 KB   ██████████▏

Alpine.js y HTMX — nicho válido en 2026

                                Alpine.js   HTMX       Framework SPA
─────────────────────────────────────────────────────────────────────
App server-rendered PHP/Rails  ✅ ideal    ✅ ideal    ⚠️ overhead innecesario
Interactividad ligera HTML      ✅          ⚠️          ❌
Sin pipeline de build           ✅          ✅          ❌
Forms + validación simple       ✅          ✅          ⚠️
SPA navegación client-side      ❌          ❌          ✅
Dashboard estado complejo       ❌          ❌          ✅

12. Three.js y WebGL

3D, visualizaciones y experiencias inmersivas en la web

📖 WebGL: API del navegador para renderizado 2D/3D acelerado por GPU. Bajo nivel — programas en GLSL (lenguaje de shaders). Three.js es la abstracción más popular sobre WebGL. 📖 WebGPU: Sucesor de WebGL. API moderna basada en Vulkan/Metal/DX12. Soportado en Chrome/Edge 2023+, Safari 2024+. Mayor rendimiento y acceso a compute shaders. 📖 Shader: Programa que se ejecuta en la GPU. Vertex shader posiciona vértices, fragment shader calcula el color de cada píxel. GLSL es el lenguaje. 📖 Three.js: Librería JS que abstrae WebGL — crea escenas 3D con cámaras, luces, materiales y geometrías sin escribir GLSL. Estándar de facto del 3D web. 📖 R3F (React Three Fiber): Three.js declarativo como componentes React. <mesh>, <boxGeometry>, <ambientLight> — reconciliador de React sobre Three.js.

Ecosistema 3D/WebGL 2026

Librería	Sobre	Nivel	Caso ideal	Bundle	Mantenedor
Three.js r168+	WebGL/WebGPU	Medio	Escenas 3D generales	~600 KB	mrdoob ✅
React Three Fiber	Three.js + React	Medio	3D en apps React/Next	~600KB+React	Poimandres ✅
Drei	R3F helpers	Alto	Abstracciones R3F listas	Modular	Poimandres ✅
Babylon.js 7	WebGL/WebGPU	Medio-Alto	Juegos, AR/VR	~800 KB	Microsoft ✅
Spline	Three.js	Alto	3D sin código (editor visual)	~900 KB	Spline ✅
GSAP + ScrollTrigger	DOM/Canvas	Alto	Animaciones scroll 2D/3D	~80 KB	GreenSock ✅
Lottie Web	Canvas/SVG	Alto	Animaciones After Effects	~60 KB	Airbnb ✅
PixiJS 8	WebGL/WebGPU	Medio	2D, juegos, data viz	~400 KB	PixiJS ✅
D3.js 7	SVG/Canvas	Bajo	Data visualization custom	~70 KB	Observable ✅

Por caso de uso frontend

Caso de uso                          Recomendación           Alternativa
────────────────────────────────────────────────────────────────────────────
Landing page hero 3D                 Spline o R3F + Drei     Three.js vanilla
Portafolio/branding interactivo      Three.js o R3F          GSAP + CSS 3D
Producto 3D en eShop (viewer)        R3F + Drei              Babylon.js
Juego web                            Babylon.js 7            Three.js
Animaciones scroll storytelling      GSAP + ScrollTrigger    CSS Scroll-driven
Data viz compleja / charts           D3.js 7                 Observable Plot
Animación UI (micro-interactions)    GSAP o CSS Animation    Framer Motion
AR/VR WebXR                         Babylon.js + WebXR      Three.js + WebXR
Sprites / juego 2D                   PixiJS 8                Phaser 3

Integración con frameworks frontend

Framework         Three.js/WebGL integration
──────────────────────────────────────────────────────────────────
React / Next.js   ✅ React Three Fiber (R3F) — ecosistema enorme
Angular           ✅ Three.js vanilla en ngAfterViewInit + canvas ref
Vue / Nuxt        ✅ TresJS (Vue Three Fiber equivalente)
Astro             ✅ Island con R3F o Three.js — carga diferida ideal
SvelteKit         ✅ Threlte (Svelte Three Fiber equivalente)
Vanilla JS        ✅ Three.js vanilla — máximo control

📖 TresJS: Equivalente de R3F para Vue 3 — Three.js declarativo como componentes Vue. Activo y maduro en 2026. 📖 Threlte: Equivalente de R3F para Svelte — Three.js declarativo como componentes Svelte.

Consideraciones de performance 3D en web

Optimización                          Impacto
────────────────────────────────────────────────────────────────
Lazy load Three.js (dynamic import)   Bundle inicial no afectado
Usar WebGPU cuando disponible         2-5x más rápido en cómputo
DRACO compression para .glb           -70% tamaño modelos 3D
useGLTF + Suspense (R3F)              Carga progresiva sin bloqueo
Instancing para objetos repetidos     1 draw call para N objetos
LOD (Level of Detail)                 Menos polígonos a distancia

📖 DRACO: Algoritmo Google de compresión de geometría 3D. Reduce archivos .glb/.gltf un 70–90%. Three.js y Babylon incluyen el decoder. 📖 Instancing: Renderizar N copias del mismo objeto con 1 sola llamada a la GPU. Crítico para escenas con árboles, partículas, multitudes.

13. Microfrontends

Arquitectura microfrontend — ¿cuándo y cómo?

📖 Microfrontend (MFE): Extensión del concepto microservicio al frontend. Cada equipo posee y despliega su parte de la UI de forma independiente. La shell app los compone en runtime. 📖 Module Federation: Plugin Webpack/Rspack que permite cargar código JS de otra app en runtime. App A puede importar componentes de App B sin re-deployar App A. 📖 Shell / Host app: Aplicación contenedora que carga los microfrontends remotos. Gestiona routing top-level, auth global y layout compartido. 📖 Remote: Microfrontend que expone módulos para ser consumidos por la shell. Cada remote tiene su propio deploy, repo y equipo. 📖 Single-SPA: Framework orquestador de microfrontends. Monta/desmonta apps Angular, React, Vue en el mismo DOM según la ruta activa.

¿Cuándo tiene sentido MFE? — checklist honesto

Condición                                          MFE válido
──────────────────────────────────────────────────────────────────
>3 equipos trabajan en el mismo frontend           ✅ SÍ
Equipos con ciclos de deploy independientes        ✅ SÍ
Parte del frontend tiene tech stack diferente      ✅ SÍ
Dominio de negocio muy diferenciado por sección    ✅ SÍ
Organización con Conway's Law bien definida        ✅ SÍ
Startup / equipo pequeño <5 devs frontend          ❌ NO — overhead brutal
App simple con 1 equipo                            ❌ NO — monolito es mejor
Quieres solo reutilizar componentes                ❌ NO — usa librería npm
La app no es SPA (SSR/Astro/landing)               ❌ NO — no aplica

📖 Conway’s Law: “Las organizaciones producen sistemas que copian su estructura de comunicación.” Si tienes 3 equipos backend con dominios separados, tu frontend eventualmente necesitará reflejar eso.

Estrategias de composición MFE

Estrategia	Cómo	Caso ideal	Complejidad
Module Federation	Webpack/Rspack runtime	MFE con mismo framework	⭐⭐⭐
Web Components	Custom Elements como contrato	MFE multi-framework	⭐⭐⭐
iFrames	Aislamiento total	Legacy / máximo aislamiento	⭐
Single-SPA	Orquestador JS	Multi-framework orquestado	⭐⭐⭐⭐
Server-side composition	Edge/proxy ensambla HTML	SSR MFE (Next.js + Nginx)	⭐⭐⭐⭐⭐
NPM packages	Librería versionada	Componentes compartidos simples	⭐

Module Federation — estándar de facto 2026

Stack MFE recomendado 2026
────────────────────────────────────────────────────────────────────
Bundler:       Rspack (Rust-based, 10x más rápido que Webpack)
Federación:    Module Federation 2.0 (Rspack nativo)
Shell:         Next.js 15.x / 16.0 o Angular 22
Remotes:       Cualquier framework (React, Angular, Vue)
Routing:       Shell gestiona rutas top-level
Auth:          Shell gestiona token, remotes lo consumen
Design system: Web Components (Lit) o npm package compartido
Deploy:        Independiente por remote — CDN separada

📖 Rspack: Bundler escrito en Rust, compatible con Webpack. 5-10x más rápido en build. Module Federation 2.0 incorporado. Adoptado por ByteDance y creciendo rápido en 2026.

MFE por caso de uso frontend

Caso                                       Estrategia MFE
────────────────────────────────────────────────────────────────────
Portal empresa multi-equipo (Angular)      Module Federation + Angular shell
App enterprise React + legado Angular      Web Components como contrato
ePlataforma con checkout externo           iFrame para checkout (PCI compliance)
Ecommerce multi-marca                      Server-side composition (Edge)
Dashboard SaaS multi-tenant                Module Federation remotes por módulo
Landing + portal cliente (mismo dominio)   Next.js shell + MFE lazy routes

Tradeoffs de MFE — la verdad incómoda

Ventajas reales                            Costes reales
──────────────────────────────────────     ──────────────────────────────────
✅ Deploy independiente por equipo         ❌ Bundle duplicado (React x2 si no se comparte)
✅ Tech stack por equipo                   ❌ Complejidad operacional x3
✅ Fallos aislados                         ❌ Testing e2e mucho más difícil
✅ Escala organizacional                   ❌ Latencia extra cargando remotes
✅ Ownership claro por dominio             ❌ Estado compartido complejo (auth, tema)
                                           ❌ DX degradada vs monorepo

⚠️ Recomendación 2026: Antes de adoptar microfrontends, considera un monorrepo con Nx o Turborepo — ofrece despliegues independientes, responsabilidad clara por dominio y librerías compartidas sin la complejidad de Module Federation. Los microfrontends solo tienen sentido cuando el monorrepo ya no escala a nivel organizativo.

📖 Nx / Turborepo: Herramientas de gestión de monorrepos. Nx incluye generadores para Angular, React y Next.js, caché de compilaciones y grafo de dependencias. Turborepo es más ligero e ideal para proyectos con Next.js. Ambas resuelven el 80% de los problemas que llevan a adoptar microfrontends.

Índice actualizado — Documento completo

Sección	Tema
1	Ecosistema 2026 — Estado del arte
2	Caso A — Landing pages y páginas públicas
3	Caso B — eShops y tiendas públicas
4	Caso C — Portales privados y apps internas
5	Caso D — Apps médicas, financieras y de campo (offline-first y PWA)
6	Caso E — Dashboards de alta frecuencia y fintech (real-time WebSockets)
7	Métricas comparativas globales
8	Librerías UI y component frameworks
9	Matriz de decisión final
10	Frameworks de Web Components (Lit, Stencil, FAST)
11	Vanilla JS, HTML y CSS (Alpine.js, HTMX)
12	Three.js, WebGL, WebGPU, animaciones
13	Microfrontends (Module Federation, Single-SPA)

_Documento generado: Agosto 2026 | Angular 22 estable · Angular 23 RC · Next.js 15.x / 16.0 · Astro 5.x · SvelteKit 2.x/3.x · TypeScript 5.x · Module Federation 2.0 · Lit 3 · Three.js r168_n árboles, partículas, multitudes.

11. Microfrontends

Arquitectura microfrontend — ¿cuándo y cómo?

📖 Microfrontend (MFE): Extensión del concepto microservicio al frontend. Cada equipo posee y despliega su parte de la UI de forma independiente. La shell app los compone en runtime. 📖 Module Federation: Plugin Webpack/Rspack que permite cargar código JS de otra app en runtime. App A puede importar componentes de App B sin re-deployar App A. 📖 Shell / Host app: Aplicación contenedora que carga los microfrontends remotos. Gestiona routing top-level, auth global y layout compartido. 📖 Remote: Microfrontend que expone módulos para ser consumidos por la shell. Cada remote tiene su propio deploy, repo y equipo. 📖 Single-SPA: Framework orquestador de microfrontends. Monta/desmonta apps Angular, React, Vue en el mismo DOM según la ruta activa.

¿Cuándo tiene sentido MFE? — checklist honesto

Condición                                          MFE válido
──────────────────────────────────────────────────────────────────
>3 equipos trabajan en el mismo frontend           ✅ SÍ
Equipos con ciclos de deploy independientes        ✅ SÍ
Parte del frontend tiene tech stack diferente      ✅ SÍ
Dominio de negocio muy diferenciado por sección    ✅ SÍ
Organización con Conway's Law bien definida        ✅ SÍ
Startup / equipo pequeño <5 devs frontend          ❌ NO — overhead brutal
App simple con 1 equipo                            ❌ NO — monolito es mejor
Quieres solo reutilizar componentes                ❌ NO — usa librería npm
La app no es SPA (SSR/Astro/landing)               ❌ NO — no aplica

📖 Conway’s Law: “Las organizaciones producen sistemas que copian su estructura de comunicación.” Si tienes 3 equipos backend con dominios separados, tu frontend eventualmente necesitará reflejar eso.

Estrategias de composición MFE

Estrategia	Cómo	Caso ideal	Complejidad
Module Federation	Webpack/Rspack runtime	MFE con mismo framework	⭐⭐⭐
Web Components	Custom Elements como contrato	MFE multi-framework	⭐⭐⭐
iFrames	Aislamiento total	Legacy / máximo aislamiento	⭐
Single-SPA	Orquestador JS	Multi-framework orquestado	⭐⭐⭐⭐
Server-side composition	Edge/proxy ensambla HTML	SSR MFE (Next.js + Nginx)	⭐⭐⭐⭐⭐
NPM packages	Librería versionada	Componentes compartidos simples	⭐

Module Federation — estándar de facto 2026

Stack MFE recomendado 2026
────────────────────────────────────────────────────────────────────
Bundler:       Rspack (Rust-based, 10x más rápido que Webpack)
Federación:    Module Federation 2.0 (Rspack nativo)
Shell:         Next.js 15.x / 16.0 o Angular 22
Remotes:       Cualquier framework (React, Angular, Vue)
Routing:       Shell gestiona rutas top-level
Auth:          Shell gestiona token, remotes lo consumen
Design system: Web Components (Lit) o npm package compartido
Deploy:        Independiente por remote — CDN separada

📖 Rspack: Bundler escrito en Rust, compatible con Webpack. 5-10x más rápido en build. Module Federation 2.0 incorporado. Adoptado por ByteDance y creciendo rápido en 2026.

MFE por caso de uso frontend

Caso                                       Estrategia MFE
────────────────────────────────────────────────────────────────────
Portal empresa multi-equipo (Angular)      Module Federation + Angular shell
App enterprise React + legado Angular      Web Components como contrato
ePlataforma con checkout externo           iFrame para checkout (PCI compliance)
Ecommerce multi-marca                      Server-side composition (Edge)
Dashboard SaaS multi-tenant                Module Federation remotes por módulo
Landing + portal cliente (mismo dominio)   Next.js shell + MFE lazy routes

Tradeoffs de MFE — la verdad incómoda

Ventajas reales                            Costes reales
──────────────────────────────────────     ──────────────────────────────────
✅ Deploy independiente por equipo         ❌ Bundle duplicado (React x2 si no se comparte)
✅ Tech stack por equipo                   ❌ Complejidad operacional x3
✅ Fallos aislados                         ❌ Testing e2e mucho más difícil
✅ Escala organizacional                   ❌ Latencia extra cargando remotes
✅ Ownership claro por dominio             ❌ Estado compartido complejo (auth, tema)
                                           ❌ DX degradada vs monorepo

⚠️ Recomendación 2026: Antes de adoptar microfrontends, considera un monorrepo con Nx o Turborepo — ofrece despliegues independientes, responsabilidad clara por dominio y librerías compartidas sin la complejidad de Module Federation. Los microfrontends solo tienen sentido cuando el monorrepo ya no escala a nivel organizativo.

📖 Nx / Turborepo: Herramientas de gestión de monorrepos. Nx incluye generadores para Angular, React y Next.js, caché de compilaciones y grafo de dependencias. Turborepo es más ligero e ideal para proyectos con Next.js. Ambas resuelven el 80% de los problemas que llevan a adoptar microfrontends.

Índice actualizado — Documento completo

Sección	Tema
1	Ecosistema 2026 — Estado del arte
2	Landing Pages / Páginas Públicas
3	eShops / Tiendas Públicas
4	Portales Privados / Apps Internas
5	Métricas comparativas globales
6	UI Libraries & Component Frameworks
7	Matriz de decisión final
8	Web Components Frameworks (Lit, Stencil, FAST)
9	Vanilla JS + HTML + CSS (Alpine.js, HTMX)
10	Three.js, WebGL, WebGPU, animaciones
11	Microfrontends (Module Federation, Single-SPA)

Documento generado: Agosto 2026 | Angular 22 estable · Angular 23 RC · Next.js 15.x / 16.0 · Astro 5.x · SvelteKit 2.x/3.x · TypeScript 5.x · Module Federation 2.0 · Lit 3 · Three.js r168

📚 Bibliografía y Fuentes

Core Web Vitals y métricas de rendimiento frontend

Fuente	URL	Qué aporta
Google CrUX (Chrome UX Report)	https://developer.chrome.com/docs/crux	Dataset real de CWV por dominio — base de métricas LCP/CLS/INP
web.dev — Core Web Vitals	https://web.dev/explore/learn-core-web-vitals	Definición oficial LCP, CLS, INP y umbrales Google
web.dev — INP (Interaction to Next Paint)	https://web.dev/articles/inp	Sustitución de FID por INP en 2024
Lighthouse docs	https://developer.chrome.com/docs/lighthouse	Metodología puntuación 0–100, métricas evaluadas
PageSpeed Insights	https://pagespeed.web.dev	Herramienta oficial Google para medir CWV reales

Documentación oficial de frameworks

Fuente	URL	Relevancia
Angular — Zoneless guide (v22)	https://angular.dev/guide/zoneless	Zoneless por defecto v21+, eliminación zone.js, bundle reduction
Angular — Signals guide	https://angular.dev/guide/signals	Modelo reactivo con Signals, standalone components
Angular — @defer guide	https://angular.dev/guide/defer	Carga diferida de componentes, reducción bundle inicial
Next.js 15.x / 16.0 — App Router docs	https://nextjs.org/docs/app	PPR, RSC, ISR, Server Actions
Next.js — PPR (Partial Prerendering)	https://nextjs.org/docs/app/api-reference/next-config-js/ppr	Documentación oficial PPR
Astro docs — Why Astro	https://docs.astro.build/en/concepts/why-astro/	Filosofía 0 JS, Islands Architecture
SvelteKit docs	https://kit.svelte.dev/docs	SSR/SSG/CSR, bundle size por diseño
Nuxt 4 docs	https://nuxt.com/docs	ISR, SSR, arquitectura Nuxt 4
Qwik — Resumability	https://qwik.dev/docs/concepts/resumability/	Concepto resumability vs hydration

Bundle size y análisis de peso

Fuente	URL	Relevancia
Bundlephobia	https://bundlephobia.com	Análisis de tamaño de paquetes npm (gzip + minificado)
Bundle Scanner	https://bundlescanner.com	Análisis de bundles de aplicaciones reales
zone.js npm package	https://www.npmjs.com/package/zone.js	Tamaño real zone.js — ~33KB min / ~12KB gzip
Angular — ngc compiler optimizations	https://angular.dev/tools/cli/build	Tree shaking, code splitting, optimizaciones de build

UI Libraries — documentación oficial

Fuente	URL	Relevancia
Angular Material (M3)	https://material.angular.io	Componentes, theming Material 3
PrimeNG	https://primeng.org/docs	Catálogo de 90+ componentes Angular
Shadcn/ui	https://ui.shadcn.com	Filosofía copy-paste, componentes Radix + Tailwind
Radix UI	https://www.radix-ui.com	Primitivas headless con accesibilidad (WCAG 2.2)
Lit — Web Components	https://lit.dev	Framework Google para Web Components (~5KB)
Stencil — Compiler	https://stenciljs.com/docs	Compilador WC, 0KB runtime en consumer
FAST (Microsoft)	https://www.fast.design	Web Components enterprise, base Fluent UI

Microfrontends y Module Federation

Fuente	URL	Relevancia
Module Federation — docs oficiales	https://module-federation.io	Module Federation 2.0, configuración host/remote
Rspack — Module Federation	https://rspack.dev/guide/features/module-federation	MF nativo en Rspack
Single-SPA docs	https://single-spa.js.org/docs	Orquestación multi-framework
Martin Fowler — Microfrontends	https://martinfowler.com/articles/micro-frontends.html	Artículo de referencia conceptual sobre MFE

Encuestas del sector

Fuente	URL	Relevancia
State of JS 2025 — Libraries & Frameworks	https://2025.stateofjs.com/en-US/libraries/#tier_list	Popularidad frameworks frontend, retención vs uso, Tier List (sección Libraries)
State of CSS 2025	https://2025.stateofcss.com/en-US/	Uso Tailwind, CSS Modules, tendencias styling
Stack Overflow Developer Survey 2026	https://survey.stackoverflow.co/2026/	Frameworks más usados y más queridos globalmente
JetBrains Developer Ecosystem 2026	https://www.jetbrains.com/lp/devecosystem-2026/	Adopción Angular/React/Vue por empresa

📌 Nota metodológica: Las métricas de LCP/CLS/INP son orientativas para implementaciones típicas. Los valores reales dependen del contenido, imágenes, fuentes web y red del usuario final. Se recomienda medir con PageSpeed Insights y el CrUX Dashboard para datos reales de producción.