Component library di terze parti: una scorciatoia costosa

Una component library di terze parti è un set preconfezionato di componenti UI (bottoni, modal, tabelle, form) installato via npm e usato in tutto il prodotto per spedire più in fretta. La categoria include Material UI, Chakra UI, Ant Design, Mantine, Radix UI, e la variante copia-e-possiedi resa popolare da shadcn/ui.

Per un prototipo del weekend, lo scambio è giusto. Per un prodotto che intendi fatturare nel 2027, è la scorciatoia più costosa del frontend moderno.

Perché ti danneggia più di quanto ti aiuti

I componenti spediscono più rapidamente al giorno uno. Costano di più al giorno 365. Lo studio Forrester Total Economic Impact 2024 su Figma Dev Mode ha quantificato il valore di riuso del design system interno in oltre 4 milioni di dollari per un'organizzazione composita, con 10 milioni previsti l'anno successivo, tutto generato rendendo il sistema più facile da usare, non aggiungendo più componenti (fonte). La leva sta nel sistema, non nei pezzi.

Le librerie di terze parti invertono questa matematica. Compri velocità al prezzo di tre problemi strutturali: esposizione agli upgrade (qualcun altro decide quando si rompe il tuo prodotto), uniformità del brand (il tuo dropdown è uguale a ogni altro dropdown Material UI), e attrito di personalizzazione (ogni override è una battaglia contro i default della libreria).

I numeri reali emergono su scala. Un caso documentato: un prodotto Vue con oltre 3.200 istanze di componenti agganciate a Vuetify. La libreria ha rilasciato una major version con breaking change; l'aggiornamento ha richiesto settimane di riscritture manuali e una somma significativa (fonte). I team riportano di riscrivere da zero dopo due anni perché applicare i breaking change è diventato economicamente impossibile.

Perché le soluzioni ovvie non funzionano

La risposta standard è wrap tutto. I team costruiscono wrapper attorno alla libreria per localizzare il dolore degli upgrade. Sulla carta funziona. In pratica i wrapper perdono. Una prop della libreria che non hai esposto diventa una feature request lo sprint dopo. Un breaking change su un componente figlio si propaga comunque attraverso il wrapper. In 18 mesi lo strato di wrapper è di per sé un progetto di manutenzione, e la tassa dell'astrazione la paghi due volte: una a ogni lettura, una a ogni upgrade.

L'altra soluzione ovvia è usare shadcn/ui perché possiedi il codice. È più vicino al giusto, ma parziale. shadcn risolve il problema delle dipendenze (niente upgrade hell), non il problema del sistema. Token, governance, audit di accessibilità, linguaggio del motion, theming, riuso multi-prodotto: niente di tutto questo arriva nella scatola. Quello che copi sono comunque 100 file di componenti con le decisioni di qualcun altro. La prima volta che ti serve un date range picker che si adatti al tuo brand e al tuo livello di accessibilità, lo scrivi comunque tu.

Cosa funziona davvero

Tre pattern, in ordine di costo.

1. Usa primitive senza stile, non componenti già stilati

Radix UI, React Aria Components, Base UI: forniscono la gestione della tastiera, il wiring ARIA, il focus trap e i casi limite che richiedono mesi per essere fatti bene. Non spediscono decisioni visuali. Scrivi il CSS una volta, in token, e resta tuo. È il punto di partenza giusto per ogni prodotto che intende vivere più di due anni. Un confronto recente dettaglia come Base UI e Radix differiscano come fondazione.

2. Costruisci il sistema, non i componenti

Un design system non è una component library. È uno strato di token (colore, spaziatura, tipografia, raggi, ombre, motion), un modello di theming (light, dark, alto contrasto), un livello di accessibilità (minimo WCAG 2.2 AA, 2.1 AA per la finestra di compliance dell'European Accessibility Act in vigore da giugno 2025), e un pattern di governance (chi aggiunge, chi deprecata, chi versiona). I componenti sono la parte più economica. La maggior parte dei team costruisce prima i componenti e il sistema mai. Inverti l'ordine. Abbiamo trattato il lato a monte nel nostro pezzo sugli audit di design system.

3. Tratta shadcn come uno starter, non come destinazione

Se parti da un kit copia-e-possiedi, copia ciò che è genuinamente generico (un button, una checkbox, uno switch). Sostituisci lo styling con i tuoi token al giorno uno, non al giorno 90. Cancella i componenti che non usi entro il primo sprint, o si calcificano. Esegui un audit di accessibilità su ogni componente copiato entro il primo mese: costruito su Radix non ti assolve dall'audit. Il punto di possedere il codice è possederlo davvero.

Come si presenta nella pratica

Lo Studio gira su un design system CSS-only: 57 componenti, oltre 140 token, zero runtime JavaScript, usato in più progetti consumer. Abbiamo scelto CSS-only perché ogni prodotto che spediamo deve renderizzare lato server con Core Web Vitals in verde, e una component library con runtime JS pesa su ogni pagina. Abbiamo scelto i nostri componenti perché ogni progetto che serviamo ha un brand che non possiamo eguagliare facendo override sui default di Material UI.

Il trade-off è reale e lo nominiamo: costruire un sistema in questo modo costa circa 6-12 settimane di lavoro focalizzato prima che il primo prodotto ci spedisca sopra. I team che devono validare un'idea questo mese non dovrebbero farlo. Dovrebbero spedire su Tailwind più tre componenti shadcn e ricostruire dopo. I team che costruiscono un prodotto che si aspettano di fatturare nel 2028 dovrebbero farlo ora. Dalla nostra esperienza, il break-even si trova intorno al terzo progetto consumer o al primo rebrand maggiore, quale arriva prima.

La domanda della component library è in realtà una domanda di durata. Quanto a lungo questa UI deve vivere, quante superfici deve coprire, quante volte il brand itererà prima del sunset? Se la risposta è settimane, una superficie, mai: spedisci su una libreria. Se la risposta è anni, più superfici, più volte: costruisci il sistema.

La scorciatoia delle terze parti è costosa solo quando la percorri oltre il punto per cui era stata progettata.