Un cartone animato realizzato da un ex ingegnere software di Google, intitolato “Benvenuti in Google”, ha fatto il giro del web qualche tempo fa. L’immagine mostrava due strade divergenti, nessuna delle quali percorribile: la strada principale era contrassegnata come deprecata (“non pensarci nemmeno”), mentre l’altra era indicata come in costruzione (“Pericolo”) e anch’essa non utilizzabile.
Questa era la scelta senza via d’uscita che due milioni di sviluppatori frontend si trovarono ad affrontare nel 2014, quando Google decise inaspettatamente di deprecare il suo popolare framework JavaScript, AngularJS, a favore di Angular 2, che presentava un’architettura radicalmente diversa, un nome confuso, nessun percorso di aggiornamento e non era nemmeno completamente rilasciato.
Di conseguenza, molti sviluppatori optarono per alternative come React o Vue.js.
Le lezioni del fiasco di Google con Angular
Come Google ha gestito l’aggiornamento di Angular fornisce lezioni preziose su come non aggiornare un pacchetto software, come ha spiegato Stephen Fluin, ex Developer Advocate di Google, durante un intervento al convegno All Things Open la scorsa settimana. “L’incertezza uccide la motivazione”, ha affermato Fluin. “Quando togli tutto ciò che gli sviluppatori conoscono e amano, si sentiranno demotivati.”
Fluin, attualmente alla guida della relazione con gli sviluppatori per Buildkite, ha lavorato per Google dal 2016 al 2021 sul progetto Angular e ha condiviso che “le cose erano un po’ complicate all’epoca. Era un po’ una marcia della morte. Non avevamo idea di quando sarebbe uscito Angular 2, e i fondamenti centrali di Angular continuavano a cambiare.”
Da AngularJS ad Angular 2
Google aveva buone ragioni per aggiornare Angular. Il team di AngularJS era stato spostato dalla divisione infrastrutture di Google, a quella pubblicitaria, per sfruttare meglio il software. Per sostenere operazioni di quella portata, Angular aveva bisogno di maggiore rigore.
La versione originale di AngularJS, lanciata nel 2009 come progetto secondario dall’ingegnere Google Miško Hevery, intendeva estendere le capacità di HTML. AngularJS si era rapidamente diffuso tra gli sviluppatori web esterni, che lo trovavano più semplice da usare rispetto al Google Web Toolkit (GWT).
Hevery aveva costruito AngularJS 1.3 con un modello di controller tradizionale, gestendo tutti gli input degli utenti, la logica e il trasporto dei dati tramite l’oggetto JavaScript $scope. Angular 2, annunciato alla conferenza ng-europe del 2014, rappresentava un cambiamento architetturale significativo, spostandosi verso un modello a componenti, dove ogni template HTML possedeva le proprie proprietà di classe. Dopo un’esperienza poco felice con il linguaggio Dart di Google, il team riscrisse completamente Angular in TypeScript, senza alcuna compatibilità con le versioni precedenti.
Questo cambiamento era difficile da digerire e l’intervento introduttivo alla ng-europe sembrava più spaventare gli sviluppatori Angular che ispirarli. Ogni funzionalità scartata veniva rappresentata da una grafica con lapidi (“RIP Controllers”) accompagnata dal suono di una campana. “Quella presentazione è ancora infame oggi per quello che ha fatto alla comunità”, ha detto Fluin, “Tutte queste cose che conoscevate e amavate di AngularJS sono scomparse. Nessuno sapeva che questo stava per accadere.”
Un cambiamento difficile da accettare
Generando confusione, molti sviluppatori passarono a utilizzare React e Vue.js, entrambi già in uso e abbraccianti il modello a componenti. Nel State of JS 2016, React risultò il framework frontend più popolare, con il 53% degli sviluppatori JavaScript che lo utilizzavano, mentre solo il 13% optava per Angular 2.
Angular 2 fu finalmente rilasciato nel settembre 2016, seguito da Angular 4 nel marzo successivo, mentre la versione 3 fu semplicemente saltata senza spiegazioni. Nel frattempo, AngularJS classico non fu formalmente ritirato fino alla fine del 2021, rimanendo aggiornato alla versione 1.5 nell’aprile 2016 introducendo componenti.
A rendere tutto più complicato, la nomenclatura dei framework ha creato confusione anche tra gli osservatori meno esperti: AngularJS è diverso da Angular 2? E il “2” nel nome di Angular è un numero di versione o un’indicazione di un cambiamento architetturale completo?
Lezioni apprese
Fluin consiglia: “Se stai cercando di portare i tuoi sviluppatori con te, fornire loro un percorso. Non basta eliminare il tuo vecchio prodotto senza avere il nuovo pronto.” Il comunicare il cambiamento al pubblico si rivelò un compito arduo per Google. “Abbiamo dovuto correggere le linee guida di comunicazione pubblica. Abbiamo dovuto formare esperti. Abbiamo dovuto sistemare il knowledge graph di Google”, la base di dati di Google sui fatti del mondo. “I nomi e la versioning sono importanti”, ha concluso Fluin, “di certo non in senso tecnico puro, ma per le persone che stai cercando di tenere aggiornate.”
Sebbene si possano attribuire le colpe ai dirigenti di Google per aver quasi rovinato Angular, il framework ha trovato un suo successo nel rispondere alle esigenze di Google, alimentando attualmente interfacce di applicazioni come Google Analytics e Gemini. Oggi, Angular ha stabilito un ciclo di aggiornamenti più prevedibile, con rilasci programmati due volte all’anno e il rispetto delle linee guida semantiche di versionamento.
Riflettendo su questi eventi, Fluin ha concluso che Google avrebbe potuto beneficiare di una rinomina totale di Angular 2, anche a costo di costruire una nuova base di utenti da zero. “Gli sviluppatori JavaScript amano sperimentare nuovi framework. Fingere di essere un nuovo framework potrebbe essere stata una mossa migliore,” ha detto Fluin a The Register.
