UI library
Come scegliere una libreria UI: cinque criteri misurati
Licenza, dipendenze, stati accessibili, manutenzione e costo di uscita: cinque criteri che puoi verificare oggi, con i comandi e i punti esatti da controllare.
In sintesi
- La licenza si legge sul singolo record, non sulla home page della libreria.
- Le stelle misurano l'attenzione, non la manutenzione: guarda date e release.
- Il costo di uscita dipende dal tipo di installazione: pacchetto npm o codice nel repository.
Una libreria UI si sceglie con cinque criteri verificabili: licenza, dipendenze, stati accessibili, manutenzione e costo di uscita. La popolarità non è uno di questi criteri.
1. Licenza: leggi il record, non la home page
La licenza decide se puoi spedire il componente in un prodotto chiuso. shadcn/ui, MUI, Mantine, Radix UI e Base UI dichiarano tutti MIT nel file LICENSE del repository. Verifica la licenza del singolo record, perché un catalogo può mescolare MIT, Apache-2.0 e licenze custom. Fonte: file LICENSE dei rispettivi repository, letti il 1 novembre 2026.
npm view @mui/material version license dist.unpackedSizeIl comando stampa versione, licenza e dimensione del pacchetto non compresso. Non è la dimensione nel bundle, ma è un primo filtro confrontabile tra candidati.
2. Dipendenze: quante cose installi per un bottone
Apri il package.json della libreria e conta le dipendenze dirette. Una primitiva headless con due dipendenze è più facile da sostituire di un framework con venti. Controlla anche i peer: un peer su una major di React non ancora supportata dal tuo progetto blocca l'aggiornamento prima ancora del codice.
3. Stati accessibili: la preview non basta
Prova da tastiera: Tab raggiunge il controllo, il focus è visibile, Invio attiva, Esc chiude. Poi cerca gli stati disabled, loading ed errore nel codice, non solo nella preview. La checklist in 12 punti è in componenti React accessibili.
4. Manutenzione: date, non stelle
Guarda l'ultima release, la data dell'ultimo commit e quante issue sono state chiuse negli ultimi 90 giorni. Le stelle misurano l'attenzione, non la manutenzione. Fonte: pagina Releases e cronologia del repository, letta il 1 novembre 2026.
5. Costo di uscita: il codice è tuo o resta nel pacchetto?
Una libreria npm resta una dipendenza: aggiorni con un comando, ma se cambia API devi adattarti. Un componente copiato da un registry vive nel tuo repository: lo modifichi, ma gli aggiornamenti diventano un diff manuale. Il confronto tra i due approcci è in copy-paste o headless.
I cinque criteri in una tabella
| Criterio | Domanda | Dove verificarlo | Segnale di allarme |
|---|---|---|---|
| Licenza | Posso spedirlo in un prodotto chiuso? | File LICENSE del repository e campo license su npm | Licenza custom o assente |
| Dipendenze | Quante cose installo per un bottone? | package.json e output di npm view | Peer che bloccano l'aggiornamento |
| Stati | Focus, disabled, loading ed errore esistono? | Preview, codice e tastiera | Solo il caso normale nel codice |
| Manutenzione | Quando è uscita l'ultima release? | Releases e cronologia del repository | Ultimo commit oltre 12 mesi |
| Uscita | Il codice resta mio se cambio libreria? | Tipo di installazione: npm o registry | API chiusa e nessuna migrazione |
La limitazione del catalogo
EneUI conta i record, non la qualità. Una libreria con 5.000 componenti può avere focus ring assenti e nomi incoerenti; il catalogo non lo sa. Usa i numeri per restringere la lista, non per chiudere la decisione.
Dove continuare
Per il vocabolario leggi UI kit, component library o design system; il confronto misurato è in librerie React 2026. Nel catalogo puoi partire dai 111.985 componenti, aprire un record come Keyline e confrontare una categoria come chart.
Domande frequenti
Qual è il criterio più importante?
La licenza viene prima: se non puoi usare il codice in produzione, gli altri quattro criteri non contano. Subito dopo viene il costo di uscita, perché è l'unico che paghi quando la libreria cambia.
Le stelle GitHub contano nella scelta?
No. Le stelle misurano l'attenzione, non la manutenzione. Guarda la data dell'ultima release e il ritmo di chiusura delle issue.
Meglio componenti pronti o primitive headless?
Se devi spedire una schermata entro una settimana, i componenti pronti fanno risparmiare tempo. Se il design system è il prodotto, le primitive headless lasciano il controllo su markup e stile, ma richiedono più lavoro.
Come verifico l'accessibilità in dieci minuti?
Naviga la pagina con Tab e Maiusc+Tab: il focus deve essere visibile e nell'ordine giusto. Poi apri il codice e cerca disabled, aria-invalid, role e gestione di Esc. Se manca uno di questi stati, la preview non basta.
Una libreria con 10.000 componenti è migliore di una con 50?
No. Il numero misura la copertura del catalogo, non la coerenza. Una libreria piccola con API stabile e stati completi costa meno di una grande che devi ripulire.