Il tag <video> del tuo browser gestisce play, pausa, volume e sottotitoli senza che tu debba scrivere una riga di JavaScript per farlo funzionare. Nessuno ci pensa più, ormai fa parte dell’arredamento del web. Eppure questo è l’esatto principio su cui si basano i Web Components: prendere un comportamento complesso chiuso dentro un elemento HTML che si porta dietro tutto quello che gli serve e renderlo disponibile per qualsiasi cosa tu voglia costruire.
Il motivo per cui ti trovi davanti a questo termine ha però, probabilmente, poco a che fare con la curiosità tecnica e molto con un problema concreto. Ti trovi davanti o un progetto che deve convivere con più framework contemporaneamente, o ad uno che deve durare più a lungo di quello che stai usando oggi. Qualcuno, guarda caso, ha tirato fuori i Web Components come soluzione.
Sorvolando le info che trovi ovunque (le quattro specifiche W3C, un frammento di codice con connectedCallback, la promessa che sia tutto più riutilizzabile), in questo articolo ci concentriamo sulla domanda che ci facciamo ogni volta che scegliamo una tecnologia per un progetto: quali problemi dobbiamo risolvere?
É in quest’ottica che ti parleremo della tematica.
Cosa sono i Web Components
Fondamentalmente, i Web Components ti aiutano quando hai bisogno che un pezzo di interfaccia si comporti allo stesso modo ovunque lo metti, senza che il resto della pagina ci metta lo zampino e senza che lui rovini il resto della pagina. Fanno esattamente questo, usando strumenti che il browser conosce già da sé.
Servono tre tecnologie:
- I Custom Elements ti lasciano registrare un nuovo tag HTML (il nome vuole un trattino, tipo
card-prodotto, giusto per non litigare con quelli che esistono già) insieme a una classe JavaScript che decide cosa succede quando quel tag compare, quando sparisce, quando uno dei suoi attributi cambia. - Lo Shadow DOM isola markup, CSS e comportamento del componente dal resto della pagina. Il tuo stile non si mescola con quello del sito, e viceversa. Chi ha passato ore a inseguire un CSS che si applicava dove non doveva sa già perché, da solo, questo vale il prezzo del biglietto.
- Gli HTML Template tengono pronta una struttura di markup che il browser non mostra subito, ma clona ogni volta che serve un altro componente identico nella forma, diverso nei dati.
Messe insieme, queste tre tecnologie forniscono un tag che si porta dietro aspetto, comportamento e isolamento. Questo tag vive nel browser: lo stesso principio del tag video di prima, applicato a un elemento che decidi tu, senza bisogno di framework per farlo esistere.
Il come, a questo punto, (spero) dovrebbe essere chiaro. Ora andiamo al perché.
Perché usarli? E soprattutto, perchè NO?
Ogni framework nuovo promette la stessa cosa: componenti riutilizzabili, sviluppo più veloce, codice più pulito. Per la durata del progetto in cui lo usi, la verità è che mantiene quasi sempre quella promessa. Le falle iniziano a vedersi quando il progetto sopravvive al framework o cambia il contesto in cui deve esistere.
Ad esempio, pensa al restyling di un sito web. Un componente scritto in React parla React, punto. Il prossimo progetto lo fai in Vue? Quel componente resta dov’è, non lo porti con te. Un cliente ti chiede, un paio d’anni dopo, di riprendere un pezzo di interfaccia e riusarlo su un sito costruito con altri strumenti? Va rifatto, non adattato: era stato costruito dentro le regole di un framework, mica dentro lo standard che ogni browser legge a prescindere.
Per chi lavora su più progetti, con clienti e stack diversi, non è un dettaglio da poco. Il design system che costruisci oggi, il modulo di prenotazione per uno studio, la scheda prodotto per un e-commerce: se dipendono da un framework, restano prigionieri di quel singolo progetto. Scritti come Web Components, li porti sul lavoro successivo anche se è su WordPress e il primo era in React. Un po’ lo stesso discorso di fondo che facciamo quando confrontiamo Bricks ed Elementor in base al progetto: lo strumento giusto dipende da cosa deve durare, non da cosa va “di moda”.
C’è poi un aspetto di cui si parla meno: i framework cambiano versione, passano di moda, a volte i maintainer li abbandonano senza troppi complimenti. Un componente costruito sullo standard HTML si appoggia a specifiche che i browser mantengono con una lentezza quasi istituzionale, proprio per garantire che quello che scrivi oggi funzioni ancora tra qualche anno, senza una migrazione forzata alla prima riscrittura dell’API.
I framework restano la scelta giusta in tantissimi progetti, questo va detto. Quello che ci interessa in questa sede è semplicemente riconoscere che il problema di durata e portabilità esiste davvero, e non è assolutamente da sottovalutare.
Un esempio in cui i Web Components ti aiutano
Il caso più diretto è quello del design system che deve sopravvivere al singolo progetto. Se costruisci per più clienti, con stack diversi, e ti ritrovi a ridisegnare lo stesso identico modulo di prenotazione ogni volta perché il framework di turno lo impone, i Web Components ti facilitano il lavoro e di molto. Li scrivi una volta, li porti dove serve, indipendentemente dal motore che gira sotto al cofano.
Stesso discorso per chi costruisce widget destinati a finire su siti che non controlla. Il banner dei cookie, la chat di supporto, il modulo di recensioni che un fornitore consegna come snippet da incollare: qui i Web Components sono quasi obbligati, perché nessuno può sapere in anticipo se il sito di destinazione gira su React, su un tema WordPress o su qualcosa scritto a mano nel 2015. Deve funzionare ovunque. Questa è la tecnologia che glielo garantisce.
Menzione a parte per le migrazioni graduali: un progetto legacy che non puoi permetterti di riscrivere tutto insieme, ma che vuoi modernizzare un pezzo alla volta. Un Web Component convive tranquillamente accanto al codice vecchio, senza obbligarti a un big bang che nessun budget approverebbe mai.
Se il componente deve vivere più a lungo, o in più posti, di quanto viva il contesto tecnico in cui nasce, allora ti conviene assolutamente usare i Web Components.
Un esempio in cui perdi tempo
Ci sono ovviamente anche molte casistiche in cui l’utilizzo dei Web Components si traduce in una potenziale perdita di tempo. Un sito vetrina, gestito con un CMS, che deve solo mostrare informazioni e raccogliere qualche contatto: qui i Web Components sono una soluzione a un problema che quel progetto non ha. Se ti basta un CMS ben configurato, aggiungere un livello di tecnologia in più significa solo più manutenzione, per un beneficio che nessuno probabilmente noterà mai.
Lato styling, che sulla carta sembra un dettaglio e nella pratica è il motivo per cui più di un progetto si è impantanato, lo Shadow DOM isola gli stili, il che è un vantaggio quando il tuo obiettivo è evitare conflitti, ma diventa un ostacolo quando devi far dialogare quel componente con un design system esterno o con variabili CSS globali che il resto del sito usa normalmente.
Ci sono soluzioni (le CSS custom properties, il selettore ::part), ma richiedono competenze che un piccolo progetto raramente si può permettere di avere nel team. Lo sappiamo perché ci siamo passati: la prima volta che abbiamo provato a far combaciare uno stile globale con un componente incapsulato, abbiamo perso più ore a litigare con lo Shadow DOM che a costruire il componente stesso.
Fai poi attenzione a valutare il team di lavoro. Se chi lavora al progetto non ha già dimestichezza con Custom Elements e Shadow DOM, la curva di apprendimento va messa in conto e, su un progetto piccolo, raramente si ripaga. In quel caso, molto meglio restare su strumenti che il team conosce già bene, anche se meno eleganti sulla carta.
Components o Frameworks?
Te lo stai chiedendo eh? Lo so, lo so…
A questo punto, di solito la tentazione è mettere i Web Components e un framework come React o Vue sui due piatti della bilancia e chiedersi chi vince. Ma è la domanda sbagliata. É un po’ come chiedersi se sia meglio un furgone o un’auto sportiva senza sapere cosa devi fare. Ti sfido a fare un trasloco con uno spider.
I framework vincono quando il progetto ha bisogno di velocità di sviluppo, di un ecosistema enorme di librerie già pronte, di uno stato applicativo complesso da gestire (form con decine di campi interdipendenti, dashboard con dati che cambiano in tempo reale). Hanno anni di community alle spalle, strumenti di debug maturi e trovare uno sviluppatore che li conosce è più facile che trovarne uno esperto di Web Components puri.
I Web Components vincono quando quello che stai costruendo deve durare più a lungo del framework di turno oppure deve funzionare in contesti che non controlli. Non sono un sostituto di React, sono spesso un complemento: si può benissimo costruire un componente riutilizzabile con i Web Components e usarlo dentro un’applicazione React, esattamente come useresti un tag <video> qualsiasi. La sovrapposizione non è un problema da risolvere, è già la soluzione in tantissimi progetti reali.
La domanda che vale la pena farsi, quindi, non è quale tecnologia sia superiore in astratto, ma piuttosto: questo pezzo di interfaccia deve sopravvivere al framework che sto usando oggi o è destinato a vivere e morire con questo stesso progetto? Nel primo caso, i Web Components meritano un posto. Nel secondo, probabilmente stai solo complicandoti la vita per un principio.
E quindi? Li uso o non li uso?
Come avrai capito, i Web Components non sono la “rivoluzione” che qualche articolo del 2018 prometteva, ma non sono nemmeno la moda passeggera che alcuni liquidano con un’alzata di spalle.
Sono uno strumento con un compito preciso: far durare il codice più a lungo del contesto che lo ha generato.
Se il tuo progetto ha davvero bisogno di questo, vale la pena impararli. Se non ce l’ha, va benissimo continuare a costruire con quello che già conosci: così ti risparmi pure la telefonata in cui devi spiegare al CEO cos’è lo Shadow DOM senza far sembrare che te lo sei inventato tu.
