An Angular Roadmap – The Past, Present, and Future of Angular

Aggiornamenti Angular: Cosa c’è di nuovo nella versione 11

A partire da novembre 2020, la versione 11.0.0 di Angular è ora disponibile. Mentre questa release porta molti aggiornamenti alla piattaforma, le caratteristiche più significative includono build più veloci con TypeScript 4.0, test harness dei componenti e aggiornamenti di ESLint.

Paleolithic JavaScript – SproutCore

In principio, c’era SproutCore. Era il primo framework JavaScript completo che mirava a rendere facile la costruzione di applicazioni web a pagina singola di qualità desktop. Non è che questo non fosse possibile prima. Quando Google ha rilasciato Gmail, ha mostrato al mondo che le applicazioni web potevano davvero sostituire le complesse applicazioni desktop. Google ha persino reso pubblico il toolkit Closure, un insieme di librerie e un compilatore di ottimizzazione che ha usato per costruire Gmail.

Il problema era che gli strumenti Closure di Google non erano molto adatti agli sviluppatori. Si basavano pesantemente su Java, il che alienava gli sviluppatori web che erano abituati a lavorare con JavaScript, PHP, Ruby e Python. Gmail era una grande dimostrazione di ciò che era possibile, ma lo sviluppo di applicazioni simili era ancora fuori portata per molti.

Alcuni sviluppatori coraggiosi sono riusciti a mettere insieme incredibili applicazioni a pagina singola usando una combinazione di jQuery, nastro adesivo e speranza. Mentre queste applicazioni sembravano incredibili per gli utenti finali, per gli sviluppatori che ci lavoravano, le applicazioni si trasformavano rapidamente in enormi mucchi di debiti tecnici che facevano temere al team di sviluppatori di andare al lavoro la mattina.

Come risultato, alcuni sviluppatori intraprendenti hanno iniziato a lavorare su framework che avrebbero portato applicazioni simili a Gmail a portata di mano degli sviluppatori web di tutto il mondo. SproutCore è stato il primo di questi framework a decollare. È venuto con un set completo di widget che ha reso possibile costruire applicazioni web complesse senza nemmeno toccare HTML o CSS.

Questo finì per essere grande per gli ex sviluppatori desktop che erano stati trascinati a calci e urlanti sul web. Molti altri framework sono spuntati con obiettivi simili; GWT e Cappuccino erano i più importanti. Questi framework evitavano persino JavaScript trasponendo altri linguaggi in JS. Di nuovo, questo era ottimo per gli sviluppatori desktop. Ma lasciava gli appassionati sviluppatori web fuori al freddo e li faceva sentire come se le loro abilità HTML, CSS e JavaScript duramente conquistate non avessero valore.

Questo ha lasciato un’apertura per un framework che abbracciasse veramente il web, invece di cercare di ingessarlo e fingere che fosse qualcos’altro. Un paio dei primi framework (Backbone e Knockout) apparvero e ottennero un discreto successo. Anche Ember è apparso in questo periodo. Ha preso SproutCore, l’ha ridotto all’osso e ha cercato di ricostruirlo in qualcosa di veramente web-friendly. Ember voleva essere il Six Million Dollar Man del mondo JavaScript: ricostruito meglio, più forte e più veloce.

Nessuno di questi framework ha raggiunto la popolarità. Il mondo stava aspettando qualcosa di meglio. Nel 2010, quel qualcosa di meglio è apparso: si chiamava Angular.

L’età dell’oro di Angular

Anche prima che la versione 1.0 di Angular fosse rilasciata, Angular prese d’assalto il mondo dello sviluppo front-end. Finalmente avevamo un framework JavaScript facile da usare che trattava l’HTML come un cittadino di prima classe. Sviluppatori e designer potevano ora lavorare insieme per costruire incredibili applicazioni a pagina singola. Questo arrivò come un sollievo per i designer, che erano stati infastiditi e offesi perché i vecchi framework avevano trattato HTML e CSS come strumenti per barbari, strumenti che nessuno sviluppatore civilizzato avrebbe dovuto toccare.

La prima cosa che sembrava magica agli sviluppatori che provavano Angular per la prima volta era il data binding bidirezionale. Prima di questo, la maggior parte degli sviluppatori aveva visto questo tipo di data binding solo in framework desktop come WPF e Windows Forms. Era fantastico essere in grado di legare moduli e altri elementi dell’interfaccia utente agli oggetti del modello JavaScript. Mentre il data binding bidirezionale potrebbe causare problemi di prestazioni se usato in modo eccessivo, i team che lo hanno usato con giudizio hanno scoperto che Angular ha permesso loro di creare complesse applicazioni front-end molto più velocemente che mai.

Angular ha dimostrato di essere popolare per più di un semplice collegamento di dati agli elementi HTML. Le direttive Angular hanno fornito un modo semplice per creare componenti HTML + CSS riutilizzabili. Anche se altri framework JavaScript hanno fornito questo prima di Angular, Angular è stato il primo a diventare estremamente popolare. I componenti riutilizzabili erano stati a lungo in uso nei framework lato server. I controlli utente ASP.NET e i modelli parziali in Rails e Django sono solo alcuni
esempi.

Finalmente, Angular ha reso popolare la dependency injection nel mondo dello sviluppo front-end. L’iniezione di dipendenze è stata a lungo popolare nelle applicazioni aziendali, che è forse il motivo per cui non ha preso piede nel mondo JavaScript. Gli sviluppatori front-end sono stati a lungo contrari a ciò che vedono come modelli di progettazione del software aziendale inutilmente complessi. Questa preoccupazione non è senza merito. Vi è mai capitato, nel corso della scrittura di un’applicazione, di dire a voi stessi “Quello di cui ho davvero bisogno qui è una “SimpleBeanFactoryAwareAspectInstanceFactory?”

L’iniezione di dipendenza, però, ha dimostrato il suo valore. E Angular ha reso l’iniezione di dipendenza facile da usare per un pubblico che non l’aveva usata molto in passato. Avete bisogno di un client HTTP? O forse vorresti fare qualche animazione? Nessun problema. Angular aveva dei servizi integrati per quelli. Bastava chiederli, e Angular li avrebbe iniettati nei tuoi componenti. Non c’è bisogno di istanziare nulla da soli.

O forse volevate usare gli oggetti window o location del browser senza rendere impossibile il test unitario dei vostri componenti fuori dal browser? Angular vi ha coperto anche lì, con i suoi servizi integrati $window e $location. A runtime, avresti ottenuto gli oggetti del browser che ti aspettavi. E quando si eseguono test unitari lato server in Node.js, si possono passare servizi finti nei componenti per assicurarsi che si comportino come previsto in vari scenari.

Se tutto questo non fosse abbastanza, Angular rendeva anche semplice registrare e iniettare i propri servizi. Per gli sviluppatori che erano abituati a legare tutti i loro dati al DOM e sperare per il meglio, questo era fantastico. Se stavate scrivendo una nuova applicazione front-end che richiedeva API che sarebbero costate un sacco di soldi alla vostra azienda se sovrautilizzate, probabilmente avreste preferito essere in grado di scrivere test in anticipo per assicurarvi che la vostra applicazione non cercasse di fare qualcosa come chiamare l’API Twilio 800 milioni di volte.

Così creereste un servizio Twilio che viene iniettato a runtime. Al momento dei test, creereste un finto servizio che registra il costo di ogni chiamata API che la vostra applicazione sta cercando di fare. Scrivereste dei test che coprono gli scenari d’uso comuni e assicurate che questi scenari non portino la vostra azienda a ricevere una fattura a 7 cifre. Nel complesso, la maggior parte degli sviluppatori ha trovato che le direttive Angular combinate con l’iniezione di dipendenze hanno reso possibile scrivere applicazioni front-end modulari e testabili utilizzando tecniche di ingegneria del software collaudate. Molti team di sviluppo hanno deciso che questo si traduceva in un felice stato di cose, e hanno deciso di andare all-in su Angular.

Il declino di Angular? L’ascesa di React

Mentre le cose andavano bene nel mondo di Angular, non era tutto rose e fiori. Gli sviluppatori cominciavano a incorrere in gravi problemi di prestazioni quando cercavano di legare troppi oggetti modello a troppi elementi DOM. Alcune applicazioni rallentavano fino a scoppiare. Chiamate dirette a $digest e altri stratagemmi di magia nera iniziarono a diventare necessari per ottenere prestazioni accettabili. Più o meno nello stesso periodo, è apparso un nuovo sfidante: React. All’inizio, React non sembrava rappresentare un pericolo troppo grande per Angular. Dopo tutto, questi strambi di React si erano presi la briga di inventare JSX, che assomigliava molto ad un modo per mescolare markup nel tuo codice. Non ci eravamo presi la briga di inventare i linguaggi di template per la ragione esplicita di evitare di mescolare markup e codice?

Come si è scoperto, l’approccio di React era abbastanza popolare nella comunità di sviluppo front-end. Non ha raggiunto la popolarità a razzo, tuttavia. Angular era ancora dominante, e sembrava che sarebbe rimasto così. Finché la popolarità di Angular non ha ricevuto un bel calcio nei denti da una fonte inaspettata: il team Angular stesso.

L’introduzione di Angular 2

Angular 2 è stato annunciato per la prima volta alla conferenza ng-europe nel 2014. I piani del team Angular sono arrivati come uno shock per la comunità Angular, per non dire altro. La reazione degli sviluppatori Angular fu rapida e negativa… e non senza ragione. Angular 2 si sarebbe sbarazzato di molti concetti familiari da Angular 1, introducendo un nuovo linguaggio di template incompatibile (e oh, a proposito) sarebbe anche programmato utilizzando un linguaggio completamente nuovo.

AngularJS

Anche se sia Angular 1 che Angular 2 si chiamavano ‘Angular’, in realtà erano framework molto diversi con poche cose in comune. Per aiutare a prevenire la confusione, il team di Angular ha iniziato a riferirsi alla vecchia versione di Angular come ‘AngularJS’, e la nuova versione semplicemente come ‘Angular’. Questo ha un senso intuitivo dal momento che AngularJS è stato scritto in JavaScript, e Angular no. Per mantenere chiara la distinzione tra i framework, mi riferirò ad Angular 1 come AngularJS da questo punto in avanti.

Come risultato di tutto questo, gli sviluppatori di AngularJS hanno perso fiducia nel futuro del framework. Hanno minacciato di passare ad un nuovo framework per i progetti futuri, e questo è esattamente ciò che molti di loro hanno fatto. React è stato il più grande beneficiario dell’esodo di massa da AngularJS.

Anche se React non ha fatto tanto quanto AngularJS, in un certo senso questo è stato positivo. Se stai usando una libreria di viste che non cerca di includere tutto più il lavello della cucina, è molto più difficile per gli sviluppatori di quella libreria tirarti fuori il tappeto da sotto i piedi in futuro. All’inizio, usare React era un po’ una sofferenza rispetto ad AngularJS. Dovevi mettere insieme un patchwork di librerie solo per coprire le funzionalità che AngularJS forniva fuori dalla scatola.

Molti team vedevano questo come un buon modo per ridurre il rischio, perché era improbabile che gli sviluppatori di tutte quelle librerie decidessero di fare cambiamenti incompatibili all’indietro allo stesso tempo, che è essenzialmente ciò che Angular aveva fatto.

L’emergere di Vue

Per aggravare i problemi di AngularJS, un altro framework chiamato Vue è apparso più o meno nello stesso periodo in cui si stava verificando il dramma di Angular 2. Vue era ispirato da AngularJS, ma mirava a semplificarlo e a sbarazzarsi di ciò che il creatore di Vue vedeva come complessità inutile (quindi Vue sembrava molto familiare agli sviluppatori AngularJS esistenti). Vue ha fornito un rifugio sicuro per molti sviluppatori AngularJS che non volevano passare a React.

Questo non significa che gli sviluppatori AngularJS non stessero aspettando pazientemente la comparsa di Angular 2. Ma è chiaro che c’è stato un esodo di massa da AngularJS a React e Vue a causa dell’incertezza causata dai piani per Angular 2.

Risorgi dalle ceneri con Angular 2

Finalmente, Angular 2 è stato rilasciato. Come previsto, ha eliminato molti concetti familiari di AngularJS ma ha mantenuto alcuni dei pezzi migliori come i servizi e l’iniezione di dipendenze. Fortunatamente per la sanità mentale degli sviluppatori, Angular usa il semplice TypeScript e non un fork come originariamente previsto.

Per rendere le cose più confuse, il team di Angular ha mantenuto un fork del nuovo framework che utilizzava il linguaggio di programmazione Dart invece di TypeScript. Inizialmente, le versioni TypeScript e Dart erano sviluppate in sincronia, generate da una singola base di codice. Alla fine, le versioni TS e Dart di Angular hanno deciso di prendere strade separate, e Angular Dart ora esiste per conto proprio.

Anche con questa confusione, la popolarità di Angular ha cominciato a crescere di nuovo dopo il rilascio di Angular 2. È successo lentamente. Come spesso accade nello sviluppo del software, le tendenze si sono spostate. Gli sviluppatori si sono resi conto che un grande framework incluso nelle batterie potrebbe effettivamente essere utile. Dopo tutto, quando la tua applicazione cresce abbastanza, finisci per avere effettivamente bisogno di tutte quelle batterie.

Gli sviluppatori aziendali, in particolare, hanno iniziato a tornare ad Angular. Questo ha senso. Di solito, quando si inizia una web app aziendale, si sa che sarà complessa. Non ha senso iniziare con un piccolo MVP quando sai fin dall’inizio tutte le 87 cose che la tua applicazione dovrà fare.

Dov’è Angular 3?

Anche se Angular 2 non era perfetto, molti sviluppatori di applicazioni web complesse hanno cominciato a capire che il nuovo e migliorato Angular era adatto alle loro esigenze. Fortunatamente per loro, Angular aveva in serbo alcuni interessanti miglioramenti. Ancora più importante, il team di Angular ha dimostrato che poteva costantemente pubblicare nuove versioni del framework con pochi cambiamenti tra le versioni

In una mossa che sembrava strana al momento, il team di Angular ha deciso di saltare completamente la versione 3 e passare alla versione 4. Questo fu fatto per una buona ragione: il team che lavorava sul pacchetto router di Angular aveva già spinto in avanti e rilasciato la versione 3, mentre il resto di Angular era ancora alla versione 2.3. Hanno deciso di mantenere tutte le versioni del pacchetto Angular in sincronia andando avanti, e portare tutto alla versione 4 per il prossimo rilascio era il modo più semplice per raggiungere questo obiettivo.

Angular 4

Angular 4 ha avuto alcuni cambiamenti significativi, tra cui l’aggiunta della compilazione anticipata, che ha portato a piccoli bundle JavaScript di produzione e un tempo di caricamento delle applicazioni più breve. È stato aggiunto il supporto per il rendering lato server, che è stato una spinta per i team che volevano rendere la loro applicazione in anticipo per migliorare le prestazioni di caricamento iniziale. Molti altri miglioramenti sono stati aggiunti in tutto il framework, ma l’aggiornamento delle applicazioni da Angular 2 a 4 è stato veloce e indolore nella maggior parte dei casi.

Angular 4.3 e Angular 5

Angular 4.3 ha aggiunto un nuovo client HTTP che era più facile da usare del vecchio servizio HTTP. In Angular 5, il vecchio servizio HTTP è stato deprecato e sarà abbandonato nella prossima release. Nonostante questo inconveniente, c’è stato relativamente poco brontolio perché l’aggiornamento nella maggior parte dei casi è stato semplice. Angular 5 ha anche aggiunto un migliore supporto all’internazionalizzazione e ulteriori ottimizzazioni nella compilazione.

Angular 6 e 7

Angular 6 e 7 sono stati deludenti per alcuni sviluppatori. Non ci sono stati grandi cambiamenti, ma ci sono stati molti piccoli miglioramenti della qualità della vita, specialmente per gli strumenti della CLI di Angular. La diminuzione del numero di cambiamenti visibili non è un’indicazione che il team di Angular abbia smesso di innovare. Invece, mostra che il framework è maturo, quindi il team di sviluppo è ora libero di fare più lavoro dietro le quinte, correggendo i bug e migliorando le prestazioni.

La stabilità del framework dal rilascio di Angular 2 ha attirato alcuni sviluppatori di vecchia scuola AngularJS di nuovo nel mondo Angular. Ha anche attirato l’attenzione dei team di sviluppo aziendale. Quando si costruiscono applicazioni aziendali che possono vivere per decenni, è ideale utilizzare un framework che ottiene nuove versioni in un programma prevedibile, ma non cambia troppo rapidamente. Uno sviluppatore che ha usato solo Angular 2 potrebbe essere operativo e contribuire a un’app Angular 7 in pochi minuti.

Angular 8 e Angular Ivy

E questo ci porta ad oggi. Come abbiamo visto, Angular ha fatto molta strada. È passato dall’essere amato dagli sviluppatori web all’essere vituperato all’essere ammirato, anche se non è ancora amato di nuovo come lo era nei suoi primi giorni.

All’orizzonte abbiamo Angular 8. Una tonnellata di lavoro è stato fatto in Angular 8 per renderlo facile da usare con il sistema di costruzione Bazel, che è una notizia assolutamente incredibile per tutti gli sviluppatori che lo stanno usando al di fuori di Google. Leggi i cambiamenti di Angular 8.

Più eccitante, però, la squadra Angular è duramente al lavoro su un nuovo rendering chiamato Angular Ivy. È destinato ad essere un sostituto drop-in per l’attuale reso. Per la maggior parte, le app attuali non avranno bisogno di fare alcuna modifica per utilizzare Angular Ivy.

Se Angular Ivy è un sostituto drop-in, perché dovrebbe interessare agli sviluppatori? Due ragioni importanti: la velocità e la dimensione del bundle, due preoccupazioni molto importanti. Per alcuni anni, sembrava che gli sviluppatori web fossero diventati un po’ pazzi. I team spedivano bundle JavaScript che erano 5MB, 10MB, o anche più grandi, e pensavano che non ci fosse alcun problema con questo. Dopo tutto, le applicazioni funzionavano perfettamente sui MacBook Pro i7-powered degli sviluppatori, quindi dovrebbero funzionare bene per tutti, giusto?

Purtroppo, nel mondo reale, non tutti hanno l’hardware più recente e più grande. Centinaia di milioni di persone accedono a internet solo con vecchi telefoni Android con una potenza di calcolo leggermente superiore a quella di una patata, attraverso connessioni internet poco più veloci di una linea telefonica. Per questi utenti, un enorme bundle JavaScript impiega una vita a caricarsi, e ancora di più per il loro dispositivo per analizzarlo ed eseguirlo. Anche in casi meno estremi, ci sono innumerevoli utenti in tutto il mondo che non stanno usando l’hardware più recente e migliore. Per loro, le app JavaScript massicce sono utilizzabili (ma dolorose).

Angular Ivy

Il renderer Angular Ivy aiuterà in diversi modi:

1. È stato scritto con un occhio all’efficienza, quindi svolgerà gli stessi compiti eseguendo molte meno istruzioni della CPU. Questo migliorerà sia la durata della batteria che la sanità mentale degli utenti con dispositivi poco potenti.
2. Il renderer sarà scritto in modo molto più modulare rispetto al renderer attuale. Questo lo renderà molto più adatto al tree-shaking e all’eliminazione del codice morto. Come risultato, il vostro bundle JavaScript di produzione includerà solo il codice che è necessario per eseguire la vostra applicazione, invece di mettere insieme tutto più il lavello della cucina come spesso accade con il rendering attuale.
3. In aggiunta alla riduzione delle dimensioni del bundle e alla migliorata velocità di rendering, Angular Ivy ha altri miglioramenti della qualità della vita per gli sviluppatori Angular. I tempi di ricostruzione sono significativamente più veloci. Quindi se stai eseguendo la tua app in modalità di sviluppo e aspetti che le tue modifiche appaiano, ora passerai molto meno tempo ad aspettare.
4. Il controllo dei template è migliorato, il che significa che catturerai più errori in fase di compilazione invece che in fase di esecuzione. I bug dei template in fase di esecuzione sono fastidiosi, perché o ti mordono durante i test, o mordono i tuoi utenti quando cercano di usare la tua app.
5. Il compilatore di template Angular Ivy genererà un codice leggibile dall’uomo, cosa che l’attuale compilatore del View Engine non fa. Questo tornerà utile quando si cercherà di rintracciare difficili bug di template.

Il risultato netto: app più piccole, app più veloci, sviluppatori più felici e utenti più felici.

Angular 9

Ecco una panoramica di Angular 9.

I punti salienti includono:

• Caratteristiche integrate di Angular
• Sviluppo maturo con Angular
• Comprensione dei motori di visualizzazione di Angular
• Angular Ivy risolve problemi di lunga data
• Angular Ivy e Mobile
• Selector-less Directives
• Miglioramenti della diagnostica Angular
• Internazionalizzazione con Angular Ivy
• DI e Type-Safe in Angular 9
• Modifiche di iniezione di dipendenza in Angular Core
• Benchmark Angular (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Angular La versione 10.0.0 è stata rilasciata a fine giugno 2020. Un rilascio importante, Angular 10 include cambiamenti come un nuovo selezionatore di intervallo di date in Angular Material, l’aggiornamento delle versioni di TypeScript, aggiornamenti della versione della libreria e altro ancora.

Le nuove funzionalità includono:

• Interfaccia compilatore Ngtsc
• Configura timeout asincroni
• Relazione file di blocco stantio
• Calcolo pigro di basePaths
• Fusione di file di traduzione
• Mappatura esplicita

Angular 11

La versione 11.0.0 è stata rilasciata nel novembre 2020. La major release di Angular 11 fornisce aggiornamenti in tutta la piattaforma, compresa la CLI e il framework dei componenti.

Le caratteristiche significative includono:

• Compilazione più veloce con TypeScript 4.0
• Component Test Harnesses
• Aggiornamenti ESLint
• Anteprima aggiornata del servizio linguistico
• Aggiornamento del supporto Hot Module Replacement (HMR)
• Miglioramento dei rapporti e della registrazione
• Integrazione automatica dei font

Passato di Angular, Presente e Futuro

Se hai usato Angular dai suoi primi giorni fino ad ora, allora congratulazioni! Anche se ci sono stati molti momenti difficili, ci siamo ritrovati con un framework veloce, moderno e divertente da usare.

Se eri uno sviluppatore di AngularJS ma sei passato a React, Vue, o qualcos’altro, ti incoraggio a dare un’altra occhiata ad Angular. Vale il vostro tempo, anche se decidete di rimanere con quello che state usando ora.

E se non avete mai usato Angular, perché non fare un tentativo?

Abbiamo appena fatto un tour vorticoso attraverso il passato, il presente e il futuro di Angular. Senza dubbio, è stato un bel viaggio. Indipendentemente dal tuo background in Angular, spero che ti sia piaciuto il tour!

Con quale framework lavori e perché? Se hai domande o commenti, assicurati di inserirli qui sotto.

Cercate componenti UI indipendenti dal framework? GrapeCity ha un set completo di componenti UI JavaScript, tra cui griglie di dati, grafici, indicatori e controlli di input. Offriamo anche potenti componenti per fogli di calcolo, controlli di reporting e viste di presentazione migliorate. Abbiamo un profondo supporto per Angular (così come per React e Vue) e ci dedichiamo ad estendere i nostri componenti per l’uso nei moderni framework JavaScript.