Ir al contenido
angel.library

Cómo elegir una biblioteca de UI

Una biblioteca UI puede aportar comportamiento accesible, estilos, tokens o bloques completos. Antes de comparar popularidad, identifica qué capa necesitas.

TipoAportaCosto habitual
headless/primitivescomportamiento y accesibilidaddiseñar apariencia
kit completocomponentes, tema y patronesadaptar identidad y overrides
bloques copiablespropiedad del códigomantenimiento propio
CSS frameworkutilidades o clases visualescomportamiento complejo aparte

Evalúa con un componente difícil, no con un botón:

  • navegación por teclado y lector de pantalla;
  • focus management en diálogo/menú;
  • theming, dark mode y contraste;
  • SSR/hidratación y tamaño cliente;
  • formularios, validación y estados;
  • TypeScript y composición;
  • frecuencia de releases y política de breaking changes;
  • licencia y posibilidad de salida.
caso piloto: combobox con búsqueda
→ 500 opciones
→ teclado completo
→ error y loading
→ mobile + zoom 200 %
→ tema del producto

Dos kits completos pueden traer resets, tokens, portales y modelos de estilo incompatibles. Si se combinan, define una capa interna que normalice componentes y evita que cada feature importe proveedores directamente.

export function PrimaryButton(props: ButtonProps) {
return (
<VendorButton
variant="solid"
color="brand"
{...props}
/>
)
}

No envuelvas cada componente por reflejo. Crea adaptadores donde el producto impone nombre, comportamiento o estilo estable. Una abstracción que solo reenvía todas las props añade trabajo sin aislar nada.

Construye primero un componente nativo simple y luego compara qué resuelve la biblioteca: roles, teclado, estado, portal, posicionamiento y animación. Así puedes revisar el resultado en vez de confiar en la etiqueta “accesible”.

Necesidad → tipo de biblioteca → piloto complejo → accesibilidad → integración → mantenimiento → salida. La mejor opción es la que reduce riesgo del producto, no la que tiene más componentes.