Con gli anni, siti e applicazioni web sono diventati sempre più complessi e ricchi di feature. Insieme a questa tendenza, si è passati da un approccio particolare allo sviluppo (dove cioè ogni elemento viene sviluppato in maniera specifica ed indipendente) a quello a componenti, dove invece ogni elemento visivo è costituito da altri più piccoli, più specifici, con compiti minimali e ben definiti, e legati tra loro dalla logica funzionale.
Il web stesso, nativamente, mette a disposizione dei componenti, ma a parte qualche rara introduzione nel corso degli anni, si tratta sempre degli stessi elementi che si vedono dagli anni ’90: campi di input, pulsanti, link, checkbox, intestazioni… Se abbiamo necessità di qualche entità più sofisticata (ed è probabile che sia così), abbiamo la necessità di svilupparli per conto nostro.
Uno dei primi passi della creazione del design di un’applicazione oggi quindi consiste nella definizione dei “componenti” che lo andranno a comporre, insieme ai loro ruoli e funzionalità, in modo da delinearne un look & feel omogeneo e soddisfacente.
Fin qui, nulla di nuovo: si tratta di un approccio noto e attuato ormai da anni, e mai messo veramente in discussione. Che necessità abbiamo quindi di cambiare? Quali sono i pain point emersi in questi anni?
Il primo che viene in mente consiste nella riusabilità dei nostri componenti. Possiamo creare le nostre “librerie” di componenti, fatte su misura per un progetto, ma come possiamo includerle in un altro per ridurne i tempi di sviluppo (sia di codice, sia di design)?
I problemi che si possono presentare sono tra i più disparati:
- come si può usare solo una parte dei componenti della libreria senza includerla interamente?
- come posso permettere di stilizzare il componente senza che questo venga stravolto in aspetto e funzionalità?
- cosa si può fare se il nuovo progetto usa uno stack tecnologico differente?
- come si può rendere l’esperienza dello sviluppatore (DX) più agevole possibile nel suo utilizzo?
Una delle librerie di componenti che ha più avuto successo in passato è stata Bootstrap. Gran parte del suo successo è dovuta sicuramente alla sua completezza per tante tipologie di componenti largamente usati all’epoca (come accordion e carousel), ad un sistema di layout ben strutturato e all’uso di una libreria JavaScript pressoché onnipresente in ogni sito e applicazione come jQuery. Ma, da allora, col declino di jQuery come strumento ubiquo per lo sviluppo di applicazioni web, nessuna libreria di componenti ha mai raggiunto il successo di Bootstrap.
Da allora si sono viste tante librerie di componenti, ma quasi sempre specifiche per un framework. Ad esempio, non si può usare Ant Design in un progetto Vue, o Angular Material in un progetto React. L’adozione di queste librerie specifica in un’azienda conduce a due possibilità:
- si limita l’azienda all’adozione di un unico framework di frontend: questo si può adattare a piccolo-medie aziende di prodotto, ma non di consulenza;
- ci si adatta allo studio di una o più librerie per ogni framework usato.
L’obiettivo prefissato è quindi di avere una libreria di componenti che:
- sia agnostica del framework usato nell’applicazione;
- funzioni senza alterazioni del codice o della pipeline di compilazione;
- possa permettere la stilizzazione dei componenti, senza consentirne lo stravolgimento;
- possa essere integrata completamente o in parte;
- offra un’esperienza di sviluppo familiare ai frequenti utilizzatori di uno o l’altro framework.
La risposta a tutto questo viene dallo standard dei Web Component, propugnato in principio da Google nel lontano (!) 2011, e da allora ha avuto aggiornamenti e un lento ma costante supporto tra i browser, nonché utilizzo nel web. Nel 2021, tutti i principali browser supportano i Web Component, anche se in maniera variabile per le varie feature che si sono aggiunte agli standard.
La dicitura “Web Components” è in realtà un “termine ombrello” per indicare un insieme di tecnologie che tra loro si integrano per fornire dei componenti che siano come usabilità quanto più vicini agli elementi nativi del web.
Vantaggi
L’utilizzo dei Web Component apre la via ad una serie di possibilità.
- Sebbene sia tecnicamente possibile sviluppare Web Components in congiunzione con servizi e funzionalità esterne, si è naturalmente portati a creare elementi auto-contenuti e disaccoppiati, facilmente riusabili in altri contesti.
- Conseguenza di ciò è che anche il loro sviluppo è quantomai indipendente dagli stack tecnologici su cui verranno usati, e conseguentemente è possibile usarli pressoché senza conflitti di sorta.
- Inoltre, l’intrinseca indipendenza dei Web Component si estende anche agli altri componenti di libreria, per cui è semplice includerne solo una parte in modo da eliminare le parti non usate.
- Sono facilmente includibili in qualsiasi progetto: generalmente basta un unico file JavaScript e sono subito disponibili in tutta la pagina, micro-frontend inclusi.
- È possibile determinare il livello di personalizzazione stilistica dei componenti, consentendo di creare elementi white label che offrano l’aspetto e la funzionalità di base ma che possano essere facilmente adattati ai vari progetti.
Nuove sfide
Uno degli svantaggi “classici” riferiti ai Web Component si basa sul fatto che la tecnologia per realizzarli, così com’è definita dagli standard, è molto di “basso livello” e con una curva di apprendimento elevata per i novizi. Ma queste sono barriere già scavalcate dalla presenza di numerosi framework e librerie per lo sviluppo (come Lit, Stencil o anche wrapper come Angular Elements), e che non espongono a curve di apprendimento più ripide rispetto ad altri framework di sviluppo front-end.
Invece, tra i principali problemi c’è sicuramente da considerare il fatto che i Web Component siano una tecnologia ancora in divenire. I principî del web impongono che non ci saranno mai delle breaking change in questa evoluzione, ma sicuramente tante feature si aggiungeranno.
Una delle ultime ad aggiungersi è quella detta Declarative Shadow DOM, che risolve l’annoso problema del SEO per i Web Component. Questo infatti consente di effettuare il Server-Side Rendering (SSR) anche di Web Component. Rimangono ancora alcune questioni:
- il supporto a Declarative Shadow DOM è limitato per ora solo a Chrome (e derivati), anche se per fortuna questo include il crawler di Google;
- il tooling per eseguire il SSR coi Web Component è, al momento, scarso se non inesistente.
Per un recap completo di ciò che il futuro dei Web Component ha in serbo ci si può riferire a questa presentazione data alla conferenza Codemotion dello scorso novembre 2020 (in inglese; qui le slide).
In conclusione
Uno dei concetti di base che è bene apprendere quando si parla di Web Components è che, sebbene sia tecnicamente possibile sostituire interamente framework come Angular o React, il massimo del risultato viene ottenuto quando sono usati all’interno di essi al fine di condividere le parti in comune.
In Antreem il tema dei Web Component è assai “caldo” ed è attualmente in fase di sviluppo una libreria di componenti di nostro design. I punti salienti si focalizzano, oltre ovviamente sull’usabilità per l’utente, anche sulla developer experience e la facilità d’uso per gli sviluppatori.
Non mancheremo di tenere aggiornato il nostro blog sui prossimi sviluppi!