Quelle che apriamo nel browser, da tempo, sono molto più che semplici pagine come potrebbero essere quelle di una pubblicazione. E le grandi software house hanno messo a punto sistemi per offrire possibilità sempre più avanzate.
L’architettura Angular creata da Google è la più diffusa e al momento anche la più evoluta. Avendo a disposizione Vincenzo Giacchina, autore del libro Apogeo appena uscito in argomento, abbiamo approfondito la sua quotidianità di programmatore e le tematiche attorno ad Angular. Ecco la nostra intervista.
Apogeonline: La tua carriera è iniziata in giovanissima età. Come hai scoperto Angular e come mai hai deciso di dedicarti a questo progetto invece che ad altri?
Vincenzo Giacchina: La passione per l’informatica mi è nata presto e altrettanto presto ho incontrato le realtà aziendali. Lo sviluppo di applicazioni, all’inizio della mia carriera, riguardava ambienti Linux embedded in C. Intorno al 2008 la mia curiosità si è spostata verso il mondo web ed il linguaggio JavaScript, che fino a quel momento avevo sottovalutato.
La comprensione delle dinamiche relative all’interazione con il browser, l’uso di JavaScript vanilla e le difficoltà di cross-browsing hanno catturato totalmente il mio interesse; da quel momento non ho più abbandonato lo sviluppo web.
La scoperta del framework Angular è avvenuta nel 2014 in Beeweeb, un’azienda con la quale ho collaborato per circa un anno a Roma. In quell’occasione ho ereditato il portale dell’Auditorium Parco della Musica, un complesso multifunzionale a Roma progettato dall’architetto Renzo Piano. Il progetto era stato realizzato in AngularJS. Ho trovato fin da subito un feeling con la logica progettuale imposta dal framework e a onor del vero non c’erano alternative importanti per applicazioni single page caratterizzati dal pattern MVC. Da quel momento non ho più trovato la necessità di valutare seriamente alternative ad Angular.
L’evoluzione di Angular, per quanto si tratti di un framework relativamente recente, è piuttosto intricata. Che cosa dobbiamo sapere del suo passato per usarlo al meglio oggi?
Angular è un framework completamente differente dalla versione precedente. Quest’ultima versione non è retrocompatibile con la precedente, ulteriore conseguenza della scelta di voler dividere nettamente i due ambienti di sviluppo. Detto questo, chi ha fatto uso di AngularJS (versione precedente) rispetto a chi si avvicina ad Angular per la prima volta, avrà il vantaggio dell’esperienza.
Aver già lavorato in SPA e aver già chiari concetti logici strutturali, quali ad esempio l’uso di direttive, pipe, service e injection non è poi poca cosa. A parte l’esperienza pregressa nello sviluppo di applicazioni, lo sviluppatore non deve scoraggiarsi nell’approcciare da zero il nuovo Angular. Il veterano di AngularJS ha sì il vantaggio dell’esperienza, ma dovrà anche dimenticare molte nozioni che sono totalmente cambiate. Questa è l’informatica.
Che vantaggi ci sono nell’uso di TypeScript come linguaggio privilegiato per lo sviluppo in Angular rispetto a scelte come JavaScript e Dart?
Nel libro ho scelto, forse più come imposizione, TypeScript come linguaggio di riferimento rispetto agli altri due. Dart non si è capito che fine farà; non mi sento di definirlo linguaggio morto ma non scommetterei neanche su una sua capillare diffusione. Per quanto riguarda JavaScript, rimane quello l’ambito di sviluppo. TypeScript è un superset di JavaScript, una sua evoluzione, non è poi così lontano da quello che un utilizzatore JavaScript è abituato a vedere. Lo sviluppo stesso di Angular è in TypeScript e la documentazione ufficiale fa riferimento a TypeScript come linguaggio principale.
I vantaggi nell’uso di TypeScript in Angular possono essere riassunti con i vantaggi del linguaggio stesso. TypeScript rispetto a JavaScript è staticamente tipizzato; ciò consente una maggiore sicurezza e robustezza nella scrittura del codice e nella rilevazione degli errori che, rispetto a JavaScript, non verrano elaborati in runtime, ma piuttosto in fase di compilazione. Non dimentichiamo che TypeScript rimane totalmente compatibile con JavaScript e questo consente di poter integrare qualsiasi progetto del secondo all’interno del primo. La tipizzazione dinamica che caratterizza JavaScript rimane inoltre un anello debole in progetti di grosse dimensioni.
TypeScript è un’iniziativa di Microsoft mentre Angular arriva da Google. Microsoft è stata nota molti anni fa per la sua strategia embrace-extend-extinguish: aderisci a un progetto altrui, amplialo in modo da diventarne arbitro in virtù di una superiore potenza di fuoco, accompagnalo all’irrilevanza se è fastidioso per i tuoi scopi. Come vedi il legame tra TypeScript e Angular alla luce del passato?
Non so se anche TypeScript rientra nella strategia a cui tu fai riferimento, probabilmente si, ma penso sia davvero una mossa ben riuscita. Microsoft sta prendendo spazio nuovamente nel mondo legato al browsing. Il suo nuovo browser ha buoni feedback e finalmente sembra aver prestato maggiore attenzione verso gli sviluppatori e gli standard. In tutto questo, la scelta di non provare a sviluppare una vera alternativa a JavaScript ma svilupparne una sua evoluzione è stata un’altra scelta azzeccata.
Le tempistiche mi suggeriscono che la scelta del team Angular di optare per TypeScript sia stata più una scelta di merito che altro. TypeScript nasce prima del nuovo Angular e, ancora prima di affidarsi totalmente a TypeScript, il team di Angular aveva optato per altre alternative. La collaborazione tra Microsoft e Google nasce intorno alle fine del 2015 probabilmente per interessi comuni. Google opta per TypeScript e la collaborazione gli offre probabilmente una parola in più nello sviluppo di TypeScript, per cui non è costretta ad allontanarsi dal tanto amato mondo JavaScript. Microsoft, dal canto suo, migliora notevolmente lo sviluppo di TypeScript grazie al diretto rapporto con Angular e soprattutto punta, grazie al framework, ad una diffusione maggiore. A mio parere questa collaborazione si sta rivelando vincente; vedremo in futuro se rimarrà così salda, io scommetto di si.
Nel libro parli anche di Ionic 2, che permette di tramutare in app le web application messe in piedi grazie ad Angular. Quali sono i suoi vantaggi, e i suoi limiti?
Ionic 2 ha già un grosso background in termini di utilizzatori e applicazioni realizzate. È probabilmente il framework più usato nella realizzazione di app ibride. I suoi vantaggi sono molto più rilevanti dei suoi limiti. Il vantaggio più grosso è il legame all’ambiente di sviluppo web: HTML5, CSS3 e JavaScript. La scelta di consentire lo sviluppo di applicazioni ibride tramite il web permette di concentrarsi sull’obiettivo senza dover dedicarsi allo studio di nuovi ambienti di sviluppo. Inoltre aver basato la sua infrastruttura su Angular lo ha reso ancora più potente.
I limiti di Ionic 2 sono quelli di qualsiasi applicazione ibrida, ma ogni anno la distanza tra ibrido e nativo si accorcia e, grazie al suo supporto delle Progressive Web App, sembra quasi che il futuro sia sempre più legato al mondo del web che ad altro. Lo sviluppo di applicazioni mobile tramite Ionic 2 non deve spaventare o creare dubbi ormai anacronistici sulle applicazioni ibride; ha già dimostrato che non è più il tempo per dubbi sul suo utilizzo.
Qual è il progetto che immagini di realizzare con Angular e deve ancora vedere la luce?
Lavorando come dipendente non posso saperlo a priori, probabilmente sarà una nuova startup. Sono molti i progetti che in questi anni hanno visto la luce e sono stati realizzati tramite Angular. Ho utilizzato Angular in tantissimi contesti differenti: social network, aggregatori, portali ed ecommerce, sempre con successo. Ho già notizia di una nuova startup nel mondo del turismo naturalistico associato al food, chiamata Tripendipity, che ha in Angular e Ionic 2 le tecnologie principali alla base dello sviluppo.
Rispetto a prima, adesso anche il cliente si esprime con fermezza sulla tecnologia da usare e molti richiedono Angular come specifica principale; vuoi perché Google è sinonimo di garanzia, vuoi perché anche nel mondo dello sviluppo si sta diffondendo la moda della tecnologia del momento, Angular. Non importa se la motivazione sia l’una o l’altra; a me basta che lo scopo ultimo sia realizzare buon software.
Il frontend delle applicazioni è un terreno complesso su cui confluiscono design, programmazione, interfaccia utente e aspettative di ogni tipo. Perché Angular spicca rispetto alla concorrenza? E che cosa vedi nel futuro del progetto?
È vero, il fronted è un terreno complesso e proprio per questo Angular ha avuto così successo. Non aiuta semplicemente lo sviluppo del frontend in termini di realizzazione del layout più accattivante, ma impone una logica MVC nell’organizzazione del codice. Questi due aspetti racchiudono in sé forse l’aspetto più interessante agli occhi di uno sviluppatore.
Sul web c’è sempre stata troppa approssimazione: anni di jQuery hanno fatto sì che venisse scritta una caterva di codice usa e getta senza nessun criterio, né di riutilizzo né di vera efficenza. Le alternative ad Angular ad oggi non inglobano questo concetto, altre si limitano alla view ed altre ancora impongono troppi vincoli; invece reputo Angular esattamente un vero framework e non qualcosa che ci si avvicina.
Per il futuro vedo una maggiore diffusione. La comunità ha risposto piuttosto bene alla nuova versione rispetto allo scetticismo iniziale dovuto al refactoring. Diciamo che non sempre la community ha scelto di supportare lo strumento migliore in termini di reale efficienza. Purtroppo quello che sopravvive non è sempre lo strumento migliore ma quello maggiormente supportato; nel cado di Angular sembra che entrambi gli aspetti coincidano.
Sviluppare applicazioni con Angular accompagna chi inizia e contemporaneamente mostra nozioni utili anche per persone già dentro la materia. In pratica è come se lo avessi scritto pensandoti come lettore…
È assolutamente così. L’occhio di riguardo va sicuramente verso il lettore che conosce la tecnologia, ma mi rivolgo anche a un neofita del web. Ho cercato di trattare tutti gli argomenti legati allo sviluppo in Angular, affinché il lettore non si sentisse smarrito durante la lettura.
È chiaro, come ho specificato più volte durante la stesura, che un libro tecnico non può consentire da solo al lettore di padroneggiare una tecnologia, soprattuto oggi che la tecnologia attuale consiste sempre in un’armonia di software che lavorano all’unisono.
Approfondire la lettura tramite Internet è assolutamente propedeutico all’apprendimento del tema trattato. Il lettore più preparato troverà ugualmente soddisfazione nella lettura, poiché potrà confrontarsi con se stesso e approfondire ulteriormente le proprie nozioni.
Nella stesura ho cercato di essere il meno accademico possibile proprio per questo. Spero che la mia visione di come un libro tecnico debba essere pensato corrisponda il più possibile a quella desiderata dal lettore.