AngularJS è la prima versione della famiglia di frameworks JavaScript sviluppata da Google. Si tratta di un open source apparso per la prima volta nel 2010 che ora si appresta a terminare la sua vita operativa. La data di fine supporto del framework – momento in cui non verranno rilasciate nuove patch e nuovi aggiornamenti – è fissata al 31 dicembre 2021. Considerando la sua diffusione, soprattutto per i progetti di grandi aziende, AngularJS potrà essere assistito a pagamento da aziende private come ad esempio xlts.dev
I costi non sono pubblici, ma considerando il livello del team e il mercato di riferimento, possiamo certamente ipotizzare che non siano esattamente a buon mercato.
Ma perché tutto questo agitarsi se esiste una versione aggiornata di Angular? Semplicemente Angular (la versione corrente si chiama così) differisce parecchio da AngularJS.
AngularJS è basato su un’architettura Model View Controller, mentre in Angular Controllers e $scope sono stati sostituiti da Componenti e Direttive. Angular come AngularJS utilizza JavaScript, ma introduce anche un nuovo linguaggio di scripting, che lo rende ancora piú performante: il TypeScript. Questa novità ha riscosso molto successo all’interno della community degli sviluppatori front-end, tanto che nel 2020 Angular è stato il secondo framework più utilizzato in assoluto.
La differenza è sensibile, soprattutto in termini di velocità e performance. Angular permette di creare una struttura migliore per gestire e manutenere applicazioni “pesanti” ottimizzando le performances.
In soldoni, un’applicazione scritta in AngularJS non può essere aggiornata ad Angular.
Quindi ora cosa succede?
Succede che chi ha applicazioni scritte in AngularJS ha solo tre possibilità:
- Accettare il rischio di esporsi a potenziali attacchi informatici rimanendo con una versione del framework non più aggiornata;
- Rivolgersi a xlts.dev per farsi aggiornare a pagamento il framework;
- Riscrivere la propria applicazione con un altro framework.
Nessuno dei casi sopra elencati mette di buon umore perché comporta rischi e costi. La nostra esperienza fatta con un partner ci ha messi però nella condizione di poter valutare le varie soluzioni e con loro abbiamo scelto insieme di riscrivere l’applicazione. Il progetto è stato lungo e complicato ed ha comportato la riscrittura del codice e tutti i test di funzionamento, ma abbiamo garantito al nostro partner una nuova vita della sua applicazione, mitigando i rischi connessi al mantenimento del vecchio framework e contenendo i costi di sviluppo per la nuova.
La soluzione non può essere adottata in tutti i casi, ma per chi necessità di standard di sicurezza elevati o di particolari certificazioni della propria applicazione è quasi un passaggio obbligato, a meno di cambiare radicalmente framework.