Asesor de Pila UI
Elegir la pila es la decisión de UI con mayor apalancamiento en un proyecto: determina la calidad de accesibilidad, la flexibilidad de temas, el tamaño del bundle y cuán "plantillado" se ve el resultado. Tómate el tiempo para decidir deliberadamente, una vez, y escríbelo.
Instantánea de conocimiento: noviembre de 2026. Las bibliotecas evolucionan rápido — antes de instalar, confirma la versión mayor y API actuales (ver Verificación de frescura). Prefiere lo que ya está en el proyecto por encima de lo listado aquí.
Paso 1 — Lee primero el proyecto
Revisa package.json / pubspec.yaml / Package.swift / build.gradle en busca de bibliotecas UI existentes, sistema de estilo (versión de Tailwind, CSS-in-JS), versión del framework y cualquier archivo components.json (shadcn), DESIGN.md o archivos de tokens. No introduzcas una segunda biblioteca de componentes junto a una existente — extiende la existente o envuélvela. Si el proyecto ya usa un competidor de alguna recomendación aquí, menciónalo pero no cambies dependencias sin que te lo pidan.
Paso 2 — Responde cinco preguntas
- Plataforma(s): solo web, solo móvil, o ambas desde un solo código base.
- Propiedad: fuente copiada que posees y puedes reestilizar libremente (modelo shadcn) vs. una dependencia versionada con una API de temas (modelo MUI/Mantine). Copiar = máxima libertad de diseño + tú la mantienes. Dependencia = más rápida, consistente, actualizaciones gratuitas, más difícil de hacerla distintiva.
- Tipo de producto: marketing/landing (expresivo, con mucho movimiento), producto UI/dashboard (denso, consistente, amigable con el teclado), contenido (tipografía primero), app móvil de consumo (sensación nativa, gestos).
- Nivel de accesibilidad: sector público / empresa / UE (Ley de Accesibilidad Europea) → elige primitivas con accesibilidad probada (React Aria, Base UI, Radix) y no construyas widgets interactivos desde cero.
- Sistema de estilo: Tailwind v4 (predeterminado para nuevos proyectos web), CSS Modules/vanilla-extract, o CSS-in-JS; en RN: NativeWind vs Unistyles vs Tamagui.
Paso 3 — Opciones por defecto (cuando nada más condiciona)
| Situación | Opción por defecto | Por qué |
|---|---|---|
| React/Next.js producto UI | shadcn/ui (primitivas Base UI — la opción por defecto desde julio de 2026; Radix y React Aria también compatibles) + Tailwind v4 | Tú posees el código, gran accesibilidad, enorme ecosistema de registros, las herramientas de IA lo conocen bien |
| React, widgets críticos para accesibilidad / complejos (rangos de fecha, comboboxes, arrastrar y soltar, i18n) | React Aria Components (o la variante React Aria de shadcn / HeroUI v3, que se basa en ella) | Comportamiento más riguroso de accesibilidad + i18n |
| React, con todo incluido, sin Tailwind | Mantine | Más de 100 componentes + hooks + formularios + fechas, documentación sólida |
| React, aspecto enterprise/Material o cuadrículas de datos pesadas | MUI v9 (+ MUI X Data Grid/Date Pickers/Charts) | Maduro, completo; más difícil de hacerlo distintivo |
| Admin empresarial (especialmente equipos CN/APAC) | Ant Design | Conjunto enorme de componentes, patrones densos en datos |
| Vue / Nuxt | Nuxt UI v4 (gratuito, construido sobre Reka UI + Tailwind v4) o shadcn-vue | |
| Svelte / SvelteKit | shadcn-svelte (sobre Bits UI) | |
| Solid | Kobalte / solid-ui (port shadcn) / Ark UI | |
| Angular | Spartan UI (similar a shadcn) o Angular Material / PrimeNG | |
| Primitivas agnósticas del framework | Ark UI (máquinas de estado Zag.js; React/Vue/Solid/Svelte) | |
| Marketing / landing page con estilo | shadcn + Motion + piezas seleccionadas de Magic UI / Aceternity / Animate UI / React Bits | Usa 1–3 efectos distintivos, no un collage |
| React Native / Expo (app nueva) | Expo + Expo Router + NativeWind v5 + React Native Reusables (shadcn para RN) o HeroUI Native; @expo/ui para controles verdaderamente nativos SwiftUI/Compose; Reanimated 4 + Gesture Handler para movimiento | |
| React Native, enfoque en rendimiento estilo StyleSheet | Unistyles 3 + tus propios componentes | |
| React Native + web desde un solo código base | Tamagui (compilador, universal) o Expo + NativeWind con react-native-web | |
| Flutter | Material 3 (incorporado) / Cupertino; forui o shadcn_ui para un look no Material | |
| iOS nativo | SwiftUI componentes del sistema (Liquid Glass en iOS 26+ viene gratis con los controles estándar) | Pelea contra la plataforma lo menos posible |
| Android nativo | Jetpack Compose Material 3 (APIs expresivas en la línea material3 1.5) |
Los detalles, alternativas y compensaciones por plataforma viven en las referencias — lee la que coincida:
references/web-react.md— Primitivas React, kits con estilo, ecosistema shadcn y registros, herramientas Tailwindreferences/web-other.md— Vue, Svelte, Solid, Angular, Astro, HTML plano/componentes webreferences/mobile.md— React Native/Expo, Flutter, SwiftUI, Compose, Kotlin Multiplatformreferences/motion.md— Bibliotecas de animación por plataforma y cuándo CSS/nativo es suficientereferences/building-blocks.md— Iconos, fuentes, gráficos, tablas, formularios, notificaciones, fechas, DnD, virtualización, editores, menús de comandos, carruseles, mapas, 3Dreferences/inspiration.md— Dónde buscar referencias (Mobbin, Refero, etc.) y herramientas de diseño con IA
Paso 4 — Registra la decisión
Escribe la elección en el proyecto (DESIGN.md o sección "Pila UI" del README): biblioteca + versión, enfoque de estilo, conjunto de iconos, biblioteca de movimiento, fuente y por qué. Las sesiones futuras (y otros agentes) lo leerán en lugar de volver a decidir.
Verificación de frescura (haz esto antes de instalar)
npm view <pkg> version time.modified repository.url # versión actual + última publicación
npm view <pkg> deprecated # aviso de obsoleto, si lo hay
# Flutter: https://pub.dev/packages/<pkg> (me gusta, puntos pub, última publicación)
# Swift: revisa el tag de la última release en el repositorio
Señales para evitar una biblioteca: sin lanzamiento en 12+ meses con problemas críticos abiertos, README dice "no mantenido/archivado", dependencias pares fijadas a React/RN antiguo, sin tipos TypeScript, problemas de accesibilidad ignorados. Ejemplos conocidos retirados/en riesgo: react-beautiful-dnd (obsoleto → usa @atlaskit/pragmatic-drag-and-drop o dnd kit), @base-ui-components/react (renombrado → @base-ui/react), APIs de Chakra v2 (v3 es una reescritura sobre Ark UI/Panda), APIs de gestos de Reanimated 2/3 (useAnimatedGestureHandler eliminado en v4).
Si hay MCPs de documentación disponibles (por ejemplo, Context7, shadcn MCP, el Figma MCP para consultas de sistema de diseño), úsalos para leer la documentación actual en lugar de confiar en la memoria.
Antipatrones
- Dos bibliotecas de componentes en una misma app (MUI + shadcn) → enfoque, espaciado y tematización inconsistentes.
- Construir desde cero diálogos, menús, comboboxes, selectores de fecha, notificaciones, tooltips → errores de accesibilidad (trampa de foco, escape, aria, bloqueo de desplazamiento, colisión). Usa primitivas.
- Instalar una biblioteca de "componentes animados" completa → copia solo las 1–3 piezas que necesitas.
- Usar un kit UI web dentro de React Native mediante webviews, o forzar componentes Material en usuarios iOS.
- Dejar el tema predeterminado de la biblioteca sin tocar → el problema de "todas las apps shadcn se ven igual". Cambia como mínimo: fuente, radio, color de acento, temperatura neutra y densidad (consulta las habilidades de design-system-builder y color-theory).