Conlaccento

Un blog sul web making di Antonio Trifirò

Web Components: da dove vengono, dove sono, dove andranno

Non ho mai usato un Web Component in un progetto vero: li conosco, ne ho letto, ne ho parlato con colleghi, ma quando c’era da decidere cosa mettere in produzione, la scelta è sempre caduta su un framework come WordPress, React, Vue, Astro, mai <my-component>.

Tuttavia, negli ultimi mesi, mi è capitato di curiosare, aprendo gli strumenti sviluppatori su GitHub, e nel DOM ho trovato cose come <tab-container>, <relative-time>, <details-dialog>. Stessa cosa su YouTube con componenti come <ytd-app>, <ytd-watch-flexy> e decine di altri custom element: da anni la piattaforma è costruita così, con Polymer prima e con Web Component “puri” adesso. Vado su Web Awesome (l’ex Shoelace) e scopro che una libreria che vedo consigliata da un pezzo si regge tutta su questa tecnologia. Poi apro State of HTML 2025 — la survey annuale che fotografa cosa pensano e usano le persone che fanno frontend — e vedo che oltre metà degli intervistati (52,6%) ha usato i Custom Element in un progetto, e che il giudizio complessivo sulle diverse feature dei Web Component pende chiaramente in positivo (24% di sentimento positivo contro 7% di negativo, in media).

E mi chiedo: cos’è, esattamente, che mi sono perso?

Questo post non è un annuncio di conversione, e non è una tesi. È il tentativo di leggere questa tecnologia con gli occhi del 2026 — da dove vengono, dove sono, dove andranno — appoggiandomi alle voci di chi ci ragiona da anni. Le mie conclusioni, se ci sono, restano piccole.

Cosa sono, in due righe

Un Web Component è un elemento HTML che ti fai tu. La specifica ha tre pezzi principali:

  • Custom Elements: la possibilità di definire nuovi tag (<my-button>) con il loro comportamento in JavaScript.
  • Shadow DOM: uno spazio DOM isolato dentro l’elemento, in cui il CSS della pagina non entra e da cui il tuo CSS non esce.
  • <template>: un pezzo di HTML dichiarato ma non renderizzato, pronto da clonare quando serve.

Un esempio minimo, giusto per fissare l’idea:

<script>
  class HelloBadge extends HTMLElement {
    connectedCallback() {
      this.innerHTML = `<span>Ciao, ${this.getAttribute('nome')}!</span>`;
    }
  }
  customElements.define('hello-badge', HelloBadge);
</script>

<hello-badge nome="Antonio"></hello-badge>

Standard W3C, supportati da tutti i browser moderni. Nessun build step, nessun npm install obbligatorio. Il progetto Polymer di Google — il primo tentativo serio di portarli nel mainstream — è del 2013. Sono con noi da parecchio.

Da dove vengono: l’autopsia di una promessa

Se i Web Component esistono da più di dieci anni e sono supportati da tutti i browser, perché nel 2026 stiamo ancora a chiederci se abbiano preso piede? Le voci più oneste ne danno tre spiegazioni intrecciate.

Il tempismo sbagliato

Sono arrivati in ritardo, seppure leggero. Nel 2013 React aveva un anno di vita ma la mindshare stava già scivolando lì; Angular era in tumulto ma dominava le aziende; Vue sarebbe arrivato di lì a poco. I framework si portavano dietro un ecosistema — routing, gestione dello stato, tooling, community — che i Web Component, nati come primitivi di piattaforma, non hanno mai avuto ambizione di replicare.

Il problema è proprio questo, e lo descrive bene Lea Verou in Web Components are not Framework Components — and That’s Okay: li abbiamo confrontati con la cosa sbagliata. Nessuno si stupisce che i mattoni non facciano concorrenza a un condominio prefabbricato — eppure con i Web Component è stato quello il paragone dominante per un decennio.

La “tassa” per chi lavora con i framework

Chi costruisce framework moderni ha vissuto i Web Component come un peso, non come un aiuto. Una delle critiche più taglienti arriva da Ryan Carniato (creatore di Solid): in Web Components Are Not the Future parla di hidden tax, una tassa nascosta pagata in codice extra e overhead di runtime, che ricade sugli utenti finali. Anche Rich Harris (Svelte) ha espresso frustrazioni simili sull’attrito che i Web Component introducono quando cerchi di integrarli in un framework moderno.

Le lamentele concrete che tornano sono, grosso modo, sempre le stesse: namespace globale (il primo che registra un nome vince, e non puoi avere due versioni dello stesso componente sulla stessa pagina); event handling contro-intuitivo per chi arriva da React; costo di runtime che si somma a quello del framework, invece di sostituirlo.

DX povera, esperienza vissuta

E poi c’è il motivo per cui non li ho usati io: la developer experience. Scrivere un componente serio in vanilla, senza librerie come Lit, richiede boilerplate, attenzione ai lifecycle, gestione manuale del template. Il thread su Hacker News If Web Components are so great, why am I not using them? è, in questo senso, un termometro onesto: tante persone hanno provato, hanno annusato l’attrito, sono tornate al framework che conoscevano. Lo stesso State of HTML 2025 mette il dito nella piaga e nomina i due punti dolenti più ricorrenti: la difficoltà a stilizzarli (lo Shadow DOM incapsula quello che c’è dentro, e far entrare stili dall’esterno richiede meccanismi ad hoc come le CSS custom properties, cosa che è al contempo una buona prassi per mantenere l’agnosticità) e l’integrazione con i framework JavaScript.

Non è una critica alla tecnologia in sé — è che usarli in pratica è più faticoso che usare un framework che già padroneggi. E nei progetti reali quella fatica pesa quanto le questioni tecniche di fondo.

Sullo styling: un fraintendimento dentro al fraintendimento

Vale la pena aprire una parentesi tecnica proprio sullo styling, perché è il punto della faccenda che viene raccontato male più spesso — me compreso, fino a poco fa. Il confine dello Shadow DOM ha una regola precisa: blocca i selettori del CSS globale, ma non l’ereditarietà.

In pratica, se nel foglio di stile della tua pagina hai:

p { color: red; }              /* NON arriva al <p> dentro lo shadow DOM */
body { font-family: Georgia; } /* SÌ, arriva per ereditarietà */
:root { --accent: green; }     /* SÌ, leggibile con var(--accent) */

il <p> dentro il componente è in Georgia (font-family è una proprietà ereditata, e l’ereditarietà attraversa il confine), non è rosso (il selettore p non entra), e diventa verde se il CSS interno del componente usa var(--accent).

Da qui il pattern moderno: un buon Web Component espone un’API di CSS custom properties (--sl-color-primary, --sl-border-radius, ecc.) che tu setti dall’esterno per personalizzarlo. Web Awesome è un esempio pulito di questo approccio. Lo Shadow DOM, insomma, è meno un muro e più una membrana selettiva: decide cosa lasciar passare.

Ed è qui che il fraintendimento sullo styling contiene un fraintendimento più profondo. L’impermeabilità selettiva non è un difetto di design, è la ragione per cui i Web Component sono davvero portabili: se il CSS della pagina non può raggiungerli con selettori mirati, allora funzionano allo stesso modo dentro un sito WordPress, un’app Astro, un template Salesforce, una pagina statica. Quello che sembra un limite di stilizzazione è, in un altro senso, la garanzia della loro agnosticità — e quindi della loro riutilizzabilità su stack diversi. Toglierlo li farebbe assomigliare a un componente React qualsiasi.

Il nodo accessibilità (che la piattaforma sta sciogliendo)

Non posso glissare sul tema accessibilità: i problemi, qui, non sono stati solo di percezione, sono stati — e in parte sono ancora — concreti.

Il nodo storico più noto riguarda le relazioni ARIA tra light DOM e Shadow DOM: attributi come aria-labelledby, aria-describedby, aria-controls non attraversano il confine. Non puoi collegare un elemento della pagina a uno dentro lo shadow, e viceversa. A questo si somma una gestione del focus con i suoi angoli bui. Lo State of HTML 2025 non fa sconti: l’accessibilità è tra i pain point più citati per i Web Component, con 1.017 menzioni nella survey.

Chi ne parla con cognizione da anni è Adrian Roselli, consulente di accessibilità e autore di Basic Custom Control Requirements — una lista di requisiti minimi per qualunque controllo personalizzato, in cui riassume tutto in una frase: “just because a thing implies it is accessible does not mean it is”. Lo stesso Roselli, in Don’t Use Web•dev for Accessibility Info, ha mostrato come anche la guida ufficiale di Google per un <tool-tip> accessibile contenesse violazioni WCAG garantite. Il livello di attenzione richiesto è alto, le trappole sono vere.

La buona notizia è che lo standard ha risposto. ElementInternals + ARIAMixin permettono oggi a un custom element di esporre nativamente ruolo e stati ARIA (supportato in tutti i browser dal 2023); i form-associated custom elements li fanno finalmente partecipare ai form come un <input> nativo. E dove le relazioni ARIA tra interno ed esterno sono critiche, diversi design system scelgono deliberatamente di saltare lo Shadow DOM e stare nel light DOM: perdi l’isolamento stilistico, guadagni relazioni ARIA pulite.

È un nodo che si sta sciogliendo, ma che richiede ancora occhio.

Dove sono, oggi: più usati di quel che sembra

E qui arriva la parte contro-intuitiva. Se lasci da parte l’aspettativa “Web Component = sostituto di React”, e ti chiedi “chi li sta usando davvero?”, la risposta è: tanti, ma nell’ombra.

  • GitHub ne ha una cinquantina in produzione, e non ha mai adottato un framework SPA. The New Stack racconta come le tab, i dialog, i metadati in ogni pagina siano Web Component nativi.
  • Salesforce costruisce l’intero suo Lightning Web Components come un livello sottile sopra la specifica dei Custom Elements.
  • Adobe Spectrum, il design system aziendale, è distribuito anche come libreria di Web Component per essere framework-agnostico.
  • Web Awesome (l’evoluzione di Shoelace, di Cory LaViska, oggi sotto Font Awesome) è una libreria di componenti pensata per girare con qualunque framework — o senza — perché è costruita sugli standard.

E i numeri sull’uso reale, non solo sulla percezione, vanno nella stessa direzione. Il Web Almanac 2024 di HTTP Archive — il rapporto annuale che scansiona milioni di siti reali e ne racconta lo stato tecnico, ed è l’ultima edizione a includere un capitolo sul markup (la 2025 ha scelto altri temi) — registra che l’adozione dello Shadow DOM è passata dallo 0,39% del 2022 al 2,51% del 2024. Il tag <template> è passato dallo 0,05% allo 0,28%. Sembrano percentuali piccole, ma sul volume del web sono numeri grossi, e la traiettoria pare chiara: stanno crescendo, non morendo.

La risposta più netta a Carniato è arrivata proprio da Cory LaViska con un pezzo intitolato Web Components Are Not the Future — They’re the Present: non un futuro promesso, ma un presente silenzioso.

Il fraintendimento originale

Quando metti in fila queste voci — Carniato che li critica, LaViska che li difende, GitHub che ci costruisce sopra un’intera piattaforma — sembra di sentire persone che parlano di due cose diverse. E in un certo senso è così.

Nolan Lawson (in Web components are okay) e Lea Verou dicono, con parole diverse, la stessa cosa: i Web Component non sono i sostituti dei framework. Sono un’altra cosa. Sono primitivi per stabilità, longevità, indipendenza dallo stack.

Se li giudichi come “una versione peggio di React”, fallisci il giudizio prima ancora di iniziare — perché non è quello che sono. Sono lo strumento giusto quando la domanda è di natura diversa:

  • Questo componente deve durare dieci anni e sopravvivere a due riscritture del frontend?
  • Deve essere consumabile da team con stack diversi, senza dover mantenere una versione React, una Vue, una Svelte?
  • Sto costruendo un design system che deve stare in piedi anche quando il framework di oggi non sarà più di moda?

Se la risposta a queste domande è sì, i Web Component sono un ottimo strumento. Se la domanda è “con cosa costruisco velocemente un’app oggi, con il mio team che già conosce React?”, i Web Component non sono la risposta — e va bene così.

Dove andranno: l’AI cambia qualcosa?

C’è una tesi che gira negli ultimi mesi e che mi ha incuriosito: l’AI potrebbe rilanciare i Web Component non perché siano più belli, ma perché sono più prevedibili. L’ho letta articolata soprattutto in due direzioni.

Matteo Antony Mistretta, in Why AI Hates Modern Frameworks (and Loves Web Standards), sostiene che “modern architectural complexity isn’t just a cognitive cost for developers — it’s a direct economic and latency tax on AI”. Il boilerplate dei framework consuma token; la molteplicità di pattern in competizione aumenta le allucinazioni; gli LLM funzionano meglio quando lavorano vicino agli standard nativi — HTML, CSS, JavaScript moderno — dove hanno visto milioni di esempi coerenti (da segnalare: Mistretta promuove un suo framework, quindi non è una voce disinteressata; l’argomento sui token e sulla varianza dei pattern però regge a prescindere.)

Joshua Briley, in Web component libraries in the AI era, racconta il fenomeno da un altro angolo: le librerie di componenti stanno passando da pacchetti npm a codice locale, di proprietà, leggibile dagli agenti AI. È il modello di shadcn/ui che si diffonde: il componente non lo installi, te lo scrivi in casa, l’AI lo può leggere e modificare direttamente. Uno spostamento culturale che rende gli standard nativi più appetibili.

A rafforzare l’argomento c’è anche un dato che arriva da un altro fronte: un’analisi sul code churn mostra che, con l’AI, il tasso di ricambio del codice — la percentuale di codice che viene riscritta o cancellata entro un mese — è quasi raddoppiato. Se il codice a livello applicativo diventa più volatile, appoggiarlo su fondamenta stabili diventa un argomento pratico, non ideologico: se il resto è instabile, mi conviene che almeno la base non lo sia.

Va detto, però, che tutto questo per ora resta un’ipotesi. L’inerzia dell’ecosistema è enorme: framework, tooling, tutorial, corsi, offerte di lavoro spingono da anni nella stessa direzione. E quando un modello genera codice senza istruzioni precise, tende a scegliere il pattern statisticamente più rappresentato — che oggi non è certo un Web Component. Che gli LLM da soli bastino a spostare quell’inerzia è una scommessa, non una certezza.

Non ho la risposta a questa domanda, non credo ce la possa avere nessuno, lo scopriremo tra qualche anno. Intanto registriamo la situazione e la monitoriamo.

Domande da porsi prima di scegliere

Invece di una checklist prescrittiva — non prendo posizione, non è quel tipo di post — chiudo con le domande che io stesso comincerò a farmi la prossima volta che dovrò decidere se un componente costruirlo con un framework o con Web Component nativi:

  • Questo componente deve sopravvivere al framework in cui vive oggi?
  • Devo distribuirlo a team con stack diversi?
  • Sto costruendo un design system che deve durare?
  • L’ergonomia del team e la velocità di sviluppo pesano più della portabilità?
  • Quanto è realistico, per il mio caso, il vantaggio della stabilità a lungo termine?

Le prime tre spingono verso Web Component. Le ultime due spesso rispondono per un framework. Nessuna delle due strade è sbagliata a priori — sono strumenti diversi per problemi diversi.

Per anni ho pensato ai Web Component come a una promessa non mantenuta. Rileggendoli oggi, con i numeri del Web Almanac in mano e i casi di GitHub e Salesforce sotto gli occhi, non credo più che lo sia stata. È stata una promessa fraintesa — venduta come alternativa ai framework, quando erano un livello sotto, un mattone diverso.

Continuo a non averli usati in nessun progetto mio. Ma la prossima volta che mi troverò a scegliere, non partirò più dal presupposto che “i Web Component non hanno preso piede”. Perché non è vero — sono solo in posti diversi da quelli in cui li stavo cercando.

Peace&Love! ✌️