Ciao, e benvenuto nella sesta puntata della nona stagione. Nella scorsa puntata le applicazioni a pagina singola avevano spostato l'intera complessità dentro il browser. Ma costruire un'applicazione intera con i vecchi strumenti, fatti di piccole modifiche puntuali alla pagina, era ingestibile. Serviva un'impalcatura, una struttura solida su cui costruire. E così, nei primi anni Dieci, arrivarono i framework, e con loro una stagione di fermento, entusiasmo e rivalità che qualcuno chiamò, con un po' di ironia, la guerra dei framework.
Chiariamo prima cos'è un framework, perché è il concetto centrale. Se una libreria come quella di cui abbiamo parlato è una cassetta di attrezzi che usi come vuoi, un framework è qualcosa di più impegnativo: è un'intera impalcatura, una struttura con le sue regole e il suo modo di fare le cose, dentro la quale tu costruisci la tua applicazione. Non è tu che usi lo strumento; è lo strumento che ti dà una forma e ti dice come organizzare il lavoro. In cambio di questa disciplina, ti risolve un'enormità di problemi difficili, dandoti un modo collaudato di costruire applicazioni complesse.
Il primo grande framework a imporsi portò un'idea potente per gestire la complessità delle applicazioni nel browser, e aprì la strada. Dimostrò che si poteva dare struttura e ordine a un'applicazione a pagina singola, invece di costruirla come un cumulo caotico di modifiche puntuali. Fu una boccata d'aria per chi si stava perdendo nella complessità, e conquistò rapidamente molti sviluppatori. Segnò l'inizio dell'era in cui costruire per il frontend significava, prima di tutto, scegliere e imparare un framework.
Ma la vera rivoluzione, quella che cambiò il modo di pensare di tutti, arrivò poco dopo, intorno al duemilatredici, da una grande azienda di social media. Portò alcune idee così potenti che, in una forma o nell'altra, dominano ancora oggi il pensiero del frontend. La prima e più importante è il pensiero a componenti: costruire l'interfaccia come un insieme di pezzi indipendenti e riutilizzabili, un pulsante, una scheda, un menù, ognuno autosufficiente, da comporre insieme come mattoncini. Ne parleremo a fondo nella prossima puntata, ma sappi che questa idea cambiò tutto.
La seconda idea rivoluzionaria di quel framework fu il modo dichiarativo di costruire l'interfaccia. Ti spiego la differenza, perché è profonda. Nel vecchio modo, imperativo, tu davi al browser una sequenza di istruzioni passo passo: trova questo elemento, cambialo così, aggiungi quello, rimuovi quell'altro. Dovevi gestire tu ogni singolo cambiamento. Nel modo dichiarativo, invece, tu descrivi semplicemente come dovrebbe apparire l'interfaccia dato un certo stato dei dati, e lasci che sia il framework a capire quali cambiamenti fare per arrivarci. Dici cosa vuoi vedere, non come ottenerlo. È un cambio di mentalità enorme, che semplifica moltissimo il ragionamento.
Poco dopo arrivò un terzo protagonista, un framework che si guadagnò l'affetto di molti per il suo approccio più graduale e accessibile. Non ti chiedeva di abbracciare tutto in una volta: potevi adottarlo un po' alla volta, aggiungendolo con delicatezza a ciò che già avevi. Questa gentilezza nell'avvicinare le persone lo rese molto amato, specialmente da chi trovava gli altri troppo impegnativi. E così si formò il panorama dei tre grandi protagonisti che, con altri, avrebbero animato la scena per anni: approcci diversi, filosofie diverse, comunità appassionate e a volte in competizione.
Voglio essere esplicito su una cosa, perché è importante e riprende un tema di tutto il podcast: non sto per dirti quale sia il migliore, e ti invito a diffidare di chi lo fa con troppa sicurezza. Ognuno di questi strumenti ha i suoi punti di forza, le sue filosofie, i contesti in cui brilla. Le comunità li difendono con passione, a volte con tifo da stadio, ma la verità è che sono tutti strumenti validi, scelti in base al progetto, al team, ai gusti. Riprendo la prima stagione: al di là delle mode e delle tribù, contano le fondamenta, che sono in gran parte comuni a tutti. Chi capisce i concetti profondi passa da un framework all'altro senza drammi.
C'è però anche un lato d'ombra di questa esplosione, che è giusto raccontare, e che generò un'espressione diventata famosa: la fatica da JavaScript. Con così tanti framework, strumenti e novità che uscivano di continuo, tutti in competizione e in rapida evoluzione, gli sviluppatori cominciarono a sentirsi sopraffatti. Appena imparavi una cosa, ne usciva un'altra che sembrava renderla obsoleta. C'era un senso di corsa continua, di non poter mai stare fermi. Questa sensazione di affaticamento, che riprende i temi della seconda stagione sul burnout, sarebbe diventata una compagna costante del frontendista, e ne parleremo ancora.
Per oggi ci fermiamo qui. Costruire applicazioni intere nel browser richiedeva un'impalcatura, e nei primi anni Dieci arrivarono i framework: strutture con le loro regole dentro cui costruire. Uno aprì la strada, un altro portò le idee rivoluzionarie del pensiero a componenti e del modo dichiarativo, un altro ancora conquistò con la sua gradualità. Sono tutti strumenti validi, e diffida di chi proclama vincitori. Ma questa abbondanza generò anche la fatica da JavaScript. Nella prossima puntata approfondiamo l'idea più influente di tutte: il pensiero a componenti e la gestione dello stato. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.