10 anni di Javascript in 20 minuti

Trascizione video

Il linguaggio Javascript si è modificato molto rapidamente, soprattutto negli ultimi anni. Ecco, con tutta probabilità ti sei perso qualche passaggio di questa evoluzione. Quindi benvenuto o benvenuta allo spiegone del mese di dicembre! Voglio racchiudere in un unico video tutta l’evoluzione del linguaggio javascript frontend, che va dal 2006 al 2016/2017. Quindi se ti sei perso qualcuno di questi passaggi, stai tranquillo perché li vediamo assieme. Rimbocchiamoci le maniche e iniziamo!

Ciao io sono Alberto Olla del sito imparareaprogrammare.it e prima di iniziare con lo spiegone ti volevo dire che mi è finalmente arrivato il libro di Raffaele Gaito sul Growth Hacking. Il Growth Hacking sono un insieme di test che puoi fare per far crescere il tuo business, quindi essenzialmente la tua app, la tua start up, il tuo sito internet e così via. Io ho conosciuto Raffaele ad un seminario che ha tenuto proprio qua a Cagliari. Mi sono appassionato del Growth Hacking quindi non vedo l’ora di leggere questo libro. Non mi ha pagato nessuno per fare questa pubblicità! Volevo semplicemente dirtelo perché se anche tu sei interessato, magari posso fare una sorta di spiegone di tutte le cose che sono scritte qua dentro, una roba tipo questa, per insegnarti cosa c’è scritto. Ok? Fammelo sapere se ti interessa. Ad ogni modo, iniziamo finalmente con lo spiegone del mese!

Javascript dal 2006 al 2016/17

L’obiettivo di questo spiegone è quello di riassumerti tutte quelle che sono state le maggiori scoperte e gli strumenti che la comunità Javascript, per quanto riguarda lo sviluppo frontend, ha fatto, a partire dal 2006 fino ad arrivare al 2016/17. Tutti questi strumenti non sono altro che dei pezzetti di un puzzle che poi se lo vai a ricomporre, va a formare quelli che sono i framework moderni. Quindi parliamo di Angular, di React, che non è un vero framework, ma questo lo scoprirai tra poco, e così via.

Quindi iniziamo da lontano e partiamo dal 2006!

Ora: jQuery è una libreria abbastanza importante, non tanto perché semplifica la scrittura dei codici Javascript ma bensì perché ti permette di scrivere un unico codice javascript che viene supportato da browser differenti. Infatti nel 2006 non tutti i browser avevano le stesse implementazioni di Javascript. Questo vuol dire che se scrivevi un codice Javascript puro che funzionava su Firefox, quello stesso codice poteva non funzionare su Internet Explorer e viceversa. Quindi con jQuery noi andiamo a scrivere un singolo codice, anche più semplificato tra l’altro, che funziona su browser differenti. Questo è importante.

2009: scoppia la bomba di Node.JS

Che come vedremo ha influenzato tantissimo quelli che sono gli strumenti che si sono creati. Quindi in tutto quello che è l’ecosistema del frontend di Javascript. E poi nello stesso anno viene rilasciata la versione ES5 di Javascript, quindi l’ECMAScript 5 che è la versione che tutti i programmatori conoscono, anche quelli odiano Javascript e che non lo possono vedere, conosceranno sicuramente la versione 5, che è quella più classica. Quindi procedurale, però rimane un linguaggio ancora molto discutibile. Poi, andiamo avanti!

2010: abbiamo il frontend framework di prima generazione.

Eccoli qua, dopo li approfondiremo e vedremo quali sono i concetti che stanno alla base.

2011: tac, nasce Bootstrap.

Quindi, Twitter pubblica Bootstrap, la prima libreria che ti consente in maniera molto semplice di creare interfacce responsive. Prima del 2011, pensa un po’, i programmatori frontend dovevano andare a scriversi a manina tutti quelli che erano le media query per andare a creare il template responsive. Nasce Bootstrap, grande vantaggio per tutti.

2013: si immettono le basi per quelli che sono i framework di seconda generazione

E poi 2015: finalmente arriva il nuovo standard Javascript: l’ECMAScript 2015, abbreviato sarebbe ES15.

Puoi notare che c’è una differenza perché prima veniva chiamato ES5 quindi con un numero 1-2-3-4-5, invece adesso hanno deciso di cambiare dicitura e hanno deciso di trasformarlo nell’anno di pubblicazione. Quindi, nel 2015 è stato pubblicato l’ECMAScript del 2015 o ES15 che tecnicamente risulta l’ES6. Ma non solo! Devi sapere che ogni anno d’ora in poi verrà pubblicato un aggiornamento di javascript. Quando parliamo di “aggiornamenti” della versione di Javascript non pensare che il linguaggio si rivoluzioni completamente.

2016/2017: ES6 e ES7

Ovviamente c’è stata una rivoluzione a partire dall’ES5 all’ES6 o ES2015, tuttavia nei successivi anni, quindi nel 2016 e nel 2017, sono state rilasciate le successive versioni, quindi l’ECMAScript 2016 e l’ECMAScript 2017 che vanno semplicemente ad aggiungere delle funzionalità per aiutare i programmatori a scrivere dei codici migliori. Quindi qua grande innovazione che però arriva soltanto nel 2015.

Bene, ti ho fatto vedere quello che più o meno era l’arco temporale. Adesso andiamo a vedere che cosa è successo durante tutto questo periodo di tempo. Andiamo per sbalzi. Io ti farò tantissimi nomi di tantissimi strumenti e librerie, quindi ti lascio il link nella descrizione se vuoi approfondire, perché ovviamente io non ho il tempo di approfondirli uno per uno. Ok? Scusa, ho un po’ di mal di gola quindi se ho una voce strana, è per quello. Allora, innanzitutto partiamo dal primo.

Il primo sarebbero gli Stylesheet Preprocessor.

In realtà, questo concetto, ovvero poter scrivere dei codici CSS come se stessimo scrivendo in un linguaggio di programmazione, quindi inserendo le variabili, inserendo dei cicli, dei Leif e così via, non hanno molto a che fare con javascript in sé. Tuttavia l’ho voluto citare per un motivo principale. Prima ti ho detto che gli sviluppatori javascript, quindi il 2006, andavano semplicemente ad utilizzare un editor di testo. Scrivevano il loro codice, lo buttavano sul server e avevano finito il lavoro.

Ma con gli Stylesheet Preprocessor si aggiunge un nuovo tassello, un nuovo strumento. Perché questi codici, dopo che vengono scritti, devono essere “preprocessati e convertiti” in un vero codice css. Per farlo, lo sviluppatore frontend deve aprire il terminale, quindi la consolle di comandi, chiamala come vuoi, e scrivere dei codici, quindi dei comandi che convertano i suoi codici LESS e i suoi codici SASS in un codice CSS. Ecco, questo è il momento in cui per la prima volta lo sviluppatore frontend del 2006, per intenderci, va ad utilizzare uno strumento diverso dall’editor e quindi apre il terminale. L’ho voluto inserire per questo. Adesso andiamo avanti.

Abbiamo anche il Template Engine.

I Template Engine sono un concetto quasi banale e scontato se parliamo di sviluppo backend. Tuttavia se parliamo di sviluppo frontend in Javascript non erano ancora nati. Nascono proprio in questo periodo e ci consentono di poter separare la logica del nostro codice Javascript da quello che è l’HTML. Ovviamente noi nell’HTML andiamo ad utilizzare una sorta di metalinguaggio, o comunque un pseudo linguaggio di programmazione che ha dei costrutti semplificati. Quindi ci permette di fare gli output, ci permette di fare i cicli, però non è Javascript. Cioè, non stiamo mischiando Javascript con l’HTML, stiamo utilizzando un qualcosa di diverso. Andiamo avanti!

Passiamo a JSCompiler.

Diciamo che questi nascono perché il linguaggio javascript in sé, diciamo in tutto quello che è il periodo prima del 2015, non veniva considerato molto bene e di buon occhio da parte di tutti quelli che sono gli sviluppatori che vengono da altri ambiti di sviluppo, ma anche dagli sviluppatori javascript in generale. Quindi cosa si è pensato di fare?

Hanno detto “mmh, sai che c’è, ma perché dobbiamo scrivere dei codici in Javascript quando il linguaggio javascript non ci offre degli strumenti opportuni per programmare? Quando noi possiamo scrivere in un altro linguaggio, e poi prendere questo nuovo linguaggio e convertirlo in un codice Javascript.” Coffeescript è stato uno dei primi. Dart, di Google mi pare. Elm, approccio funzionale. Typescript di Microsoft e quindi uno dei più famosi, attualmente almeno, perché va a fare una sorta di mix tra javascript e C#/java e ovviamente quindi abbiamo un javascript che ha una tipizzazione forte, quindi possiamo andare a definire i tipi di ogni variabile, di ogni parametro all’interno dei metodi e così via. Abbiamo le classi, abbiamo l’ereditarietà. Insomma abbiamo tanti strumenti aggiuntivi. Bene.

Parliamo anche dei Transpiler!

I Transpiler fanno una cosa differente dai Compiler. Ovvero, il Transpiler va a risolvere questo problema: prima abbiamo detto che jQuery era utile perché andava a “colmare” le differenze tra i vari browser. Ecco, queste differenze tra i vari browser ce l’abbiamo ancora. Infatti quando è uscita la versione ECMAScript 2015, la versione ECMAScript 2016 e 2017, non è che tutti i browser dall’oggi al domani hanno implementato tutte le funzioni di Javascript. Ci vuole del tempo.

Quindi che cosa succede se uno sviluppatore Javascript vuole scrivere dei codici andando ad utilizzare le potenzialità dell’ultima versione ES2017? Che ovviamente non tutti i browser le supportano. Di conseguenza nasce l’esigenza di prendere questi codici, che sono scritti andando ad utilizzare quelle che sono le funzioni più avanzate del linguaggio e convertirle in un vecchio codice, quindi nell’ES5. Nascono così i Transpiler che prendono il codice con le funzionalità aggiornate e lo trasformano, diciamo così, nella versione più vecchia e stabile, ovvero l’ES5. Ok, andiamo avanti e parliamo prima dei Module Loader e poi dei Package Manager.

Partiamo dai Module Loader e abbiamo CommonJS.

CommonJS non fa altro che aggiungere una nuova sintassi per poter fare l’import e l’export dei vari moduli, così da poterli definire e richiamare in varie parti del codice. Tuttavia, CommonJS viene utilizzato all’interno di Node, però Node è essenzialmente javascript lato server. Quindi può inserire tutte le nuove sintassi che preferisce. Ma se noi volessimo utilizzare la sintassi di CommonJS nel browser, come possiamo farlo? Ecco, tecnicamente non possiamo farlo perché è una sintassi che nessun browser supporta. A meno che non andiamo ad utilizzare Browserify che essenzialmente cosa fa: Va a prendere i nostri codici e i nostri moduli che abbiamo scritto in javascript che utilizzano la sintassi CommonJS e li trasforma in modo tale che i browser li possano capire. E quindi li possano eseguire facilmente. Fantastico!

Piccolo problema però. CommonJS non fa altro che includere nelle librerie in maniera sincrona e ovviamente quando ci spostiamo nel browser questo è un problema perché abbiamo 50 librerie e verranno richiamate una alla volta. Quindi la comunità javascript ha pensato “mmh, dobbiamo risolvere questo problema e come possiamo fare? Creiamo un nuovo metodo, ma questa volta un metodo che sia asincrono e che possa essere utilizzato all’interno del browser.”

E quindi eccolo qua: l’ADM. Asynchronous Module Definition. Perfetto! Per poterlo utilizzare ovviamente c’è una libreria Javascript che ci consente di farlo ed è Require.JS, che supporta, tra le altre cose, anche il CommonJS. Quindi Browserify muore, lo puoi cancellare dalla tua memoria e arriva il nuovo Require.JS. Fantastico! Ora cosa succede però?

Nel 2015 arriva lo standard javascript e lo standard Javascript dice “mmh, aspetta un momento, ma perché dobbiamo utilizzare degli strumenti esterni e non “nativi” del linguaggio per la definizione dei moduli, quando possiamo inventarcene uno noi?” E infatti così hanno fatto! Infatti nell’ES6 o ES2015 hanno inserito un nuovo standard, un nuovo formato per la definizione dei moduli. Eccolo qua! Ovviamente Require.JS non lo supporta, quindi eliminato Require.JS e arriva Webpack.

Webpack non solo va a supportare tutte queste tre definizioni dei moduli, ma non è più un Module Loader, ma diventa un Module Bundle. Adesso ti spiego che cos’è. Ma inoltre fa un’altra cosa divertente. Ovvero va a eliminare e prendere il posto di quelli che sono i Task Runner. I Task Runner praticamente non te li ho mai nominati perché sono morti e Webpack se li è già mangiati. Ma andiamo con ordine.

Che cosa sono i Task Runner?

Essenzialmente sono degli strumenti che ci consentono di lanciare in maniera automatica delle azioni ripetitive. Per esempio, prova a pensare al minify dei file javascript, o ancora alla compilazione dei Prepocessor del CSS, a lanciare degli Unit Test in maniera automatica, tutto questo tramite il nostro terminale. Essenzialmente tutti i compiti che potevano essere fatti con i Task Runner possono essere fatti anche tramite WebPack. Ma non solo!

Quindi WebPack è passato da Module Loader a Module Bundle, cioè essenzialmente prende i pacchetti, quindi prende quelli che sono tutti i nostri moduli, quindi che ne so abbiamo 50 file javascript, lui li prende tutti, li minifica, quindi li racchiude in un unico file. Oppure, addirittura, li può splittare, quindi in gruppi, quindi file differenti con strutture differenti. Non soltanto!

La cosa interessante di WebPack è che può “fare il bundle” non soltanto di file javascript, ma di qualsiasi tipo di file. Possono essere dei LESS, dei SASS, li può compilare, possono essere dei file Typescript, insomma, può fare un po’ tutto. E lavora benissimo con tutti quelli che sono questi strumenti. Quindi interagisce con tutti. Molto interessante! Andiamo avanti, cosa succede qua? C’è una sorta di evoluzione di quello che è, non tanto di WebPack, però una sorta di evoluzione dei Module Loader e si chiama SystemJS. È molto recente. Viene utilizzato all’interno di Angular o almeno è consigliato da utilizzare nelle ultime versioni di Angular. Te ne parlerò tra poco.

Poi abbiamo detto dobbiamo parlare dei Package Manager, te ne eri dimenticato?

Abbiamo l’NPM, Bower e Yarn. Quindi l’NPM è sia un Registry che sia un Package Manager, abbiamo detto che l’NPM viene usato su Node. Node è uno sviluppo backend, quindi non è per il frontend. Allora cosa si può usare nel frontend? Bene, è stato creato un nuovo Package Manager che si chiama Bower che fa sia da Registry che da Package Manager ed è specifico per il frontend developer. Bower essenzialmente aveva una grande distinzione dalle prime versioni dell’NPM perché utilizzava un metodo più intelligente della gestione delle dipendenze.

Successivamente l’NPM si è accorto che potevano gestire le dipendenze come le gestiva Bower, quindi hanno modificato dalla versione 3 in poi e a questo punto Bower non aveva più nessun vantaggio competitivo ed è stato eliminato ed è praticamente morto. Quindi te lo puoi anche dimenticare, puoi fare una bella X su Bower. E volendo puoi utilizzare l’NPM come viene utilizzato anche in Angular, React e così via. Parliamo di Yarn! Yarn, a differenza degli altri due è soltanto un Package Manager e sfrutta quello che è il registro dell’NPM. Quindi NPM e Yarn coesistono senza problemi. Ok!

Tutta questa parte l’abbiamo fatta, anzi no! Manca il Testing.

Ovviamente quando parliamo di frontend developer e anche di Javascript developer e così via non possiamo non citare quelli che sono gli strumenti per eseguire i test unitari o comunque i test dei nostri codici. Ovviamente anche per javascript ce li abbiamo! Abbiamo Mocha e Jasmine che sono i più diffusi, diciamo così. Ma anche Jest e Enzyme. Jest è uno strumento dell’ecosistema React, anche se poi… poi dopo ne parliamo. Invece Enzyme è sempre per React, ma è creato da Airbnb, a differenza di Jest che è di Facebook o almeno è stato creato da Facebook. Lo vediamo dopo, non corriamo troppo. Ok, tutta questa parte l’abbiamo fatta!

Framework di prima generazione

Passiamo finalmente ai frontend framework di prima generazione. Il concetto che sta dietro questi framework è molto semplice ed essenzialmente sono nati così. Hanno detto “mmh, abbiamo provato l’architettura MVC o comunque il design pattern MVC nel backend e ci ha dato dei buoni risultati. Perché non creiamo qualche libreria o qualche framework che lo implementi anche nel frontend?” E così sono nati Angular JS, BackBone.JS e anche Ember.

In realtà non tutti utilizzano il pattern MVC puro, ma alcune derivate. Non è così importante. L’importante è che hanno un approccio che è questo, ok? L’obiettivo di questi framework è quello di creare le Single Page Application e per spiegartele ti faccio un esempio molto semplice. Prova a pensare a Gmail. Quindi log-in su Gmail, hai la lista di quelle che sono tutte le tue mail, clicchi su una di queste per aprirla e il contenuto di quella mail ti verrà caricato automaticamente senza che la pagina venga aggiornata.

Questo non è un comportamento “normale” dei siti internet, ma è stato fatto volutamente e fa somigliare proprio la struttura e il funzionamento del sito Gmail ad un’applicazione mobile classica. E tipicamente si va ad associare alla nostra applicazione, quindi alla nostra interfaccia, le Rest API per il nostro server in modo tale che la nostra app possa andare a estrapolare e a prelevare quelli che sono i dati presenti sul server e a mostrarli all’utente finale. Ok. Andiamo avanti! Vue per un momento lo saltiamo.

Passiamo subito ai framework di seconda generazione.

Cosa molto importante perché cambia completamente l’approccio. Abbiamo detto che la caratteristica principale dei framework di prima generazione era il fatto che si basavano su un’architettura o comunque su un design pattern MVC. Ok? I framework di seconda generazione invece dicono “no, basta con l’MVC. Non va bene per il frontend. Abbiamo capito che è completamente sbagliato!”, e a dirlo questo sono Google e Facebook. Hanno detto “dobbiamo spostarci e dobbiamo cambiare approccio”. L’approccio che quindi accomuna i framework di seconda generazione sono i componenti. Che cos’è un componente? Prova a pensare ad una pagina internet, ok? Abbiamo il menù. Ecco, quel menù è un componente che è formato a sua volta da altri componenti. Che magari abbiamo le voci dei menù, ogni voce è un componente riusabile. Ok, adesso sai che cosa sono i componenti, possiamo andare avanti.

Quindi parliamo di Angular

Anzi, parliamo sia di AngularJS che di Angular. Allora, volevo fare alcune precisazioni. La prima versione del framework viene chiamata AngularJS e il codice veniva scritto appunto in Javascript puro. Successivamente, dopo un anno di sviluppo, è stata creata Angular che tecnicamente è la versione 2, ma completamente diversa dalla prima. Inoltre se tu vai adesso sul sito internet troverai che in realtà la versione di Angular non è più la 2, ma bensì la 5. Però non spaventarti, adesso ti spiego. Essenzialmente hanno deciso di fare un po’ com’è successo per l’ECMAScript, ovvero ogni anno rilasciano degli aggiornamenti che non vanno a stravolgere completamente quella che è la struttura del linguaggio, ma vanno semplicemente ad aggiungere delle migliorie. Quindi se impari ad usare la versione 2, non avrai problemi ad utilizzare la 4 o la 5, quindi puoi stare tranquillo.

Angular inoltre si basa su un nuovo paradigma di programmazione chiamato programmazione reattiva. È un concetto un po’ particolare che al posto di utilizzare gli eventi usa i flussi. Se sei interessato ti lascio un link in descrizione di un talk dell’Angular day del 2017 che c’è stato a Verona, è in italiano ed è fantastico e vanno a spiegare appunto questa libreria chiamata RxJs che sta per Reactive X. E non c’entra nulla con React. Poi abbiamo detto che non vai più a scrivere il codice javascript puro, ma bensì vai a scrivere codice Typescript che quindi ti dà le classi, i tipi, le interfacce e così via. È compilato, insomma, hai tanti vantaggi nello scrivere questo codice. Vantaggi che insomma anche il team di Google ha riconosciuto e infatti ha deciso di utilizzare Typescript come linguaggio ufficiale per Angular.

Inoltre va a utilizzare SystemJS. E adesso ti posso spiegare finalmente che cos’è. Essenzialmente è un Module Loader, ma con una particolarità. Infatti può essere utilizzato indistintamente sia sul browser che sul server. Questo ci dà un enorme vantaggio. Anzi, fa fare un passo successivo alle Single Page Application perché prima ti ho detto “ti ricordi quando vai su Google, su Gmail, clicchi su una determinata mail e ti carica solo quel contenuto?”, ecco. Questo è l’approccio classico delle Single Page Application. Però qui si fa qualcosa in più. E si passa al concetto di IsomorphicJS e di Universal JS. Ti spiego!

Allora: in un sito internet classico, fatto in WordPress, per intenderci, succede questo. Quando io visito il sito internet, mando la richiesta al server, il server elabora quella richiesta e mi restituisce l’HTML, con tutta la pagina. Dall’inizio, alla fine. Quindi io ho tutto l’HTML già fatto. Ok. Nelle Single Page Application non accade più questo. Perché l’HTML in realtà è dinamico e viene generato da Javascript. Quindi quando io effettuo una richiesta al server, lui mi restituisce una pagina HTML di una riga, ok? E poi un sacco di Javascript. Quel Javascript mi va a generare tutta la pagina che io vedo. Quindi tutto l’HTML è generato in Javascript.  Con l’IsomorphicJS si fa un mix di questi due approcci. Ovvero: quando io visito una pagina, qui dentro, all’interno del server, viene generato tutto il codice HTML e viene restituito, ok? E poi qui, all’interno del mio browser, quando io però mi sposto, per esempio tra un’email e l’altra, allora qua si attivano le funzioni delle Single Page Application, ok? Quindi praticamente è come se il rendering della pagina venisse fatto indistintamente sia nel server che nel client, così da scambiarsi informazioni in maniera più veloce. Questo stesso concetto lo possiamo utilizzare non soltanto per i siti internet classici, ma anche per le app o addirittura per le applicazioni desktop. Cioè i programmi che possono essere installati nel tuo computer. Infatti Angular viene utilizzato sia per siti internet, sia per app, sia per applicazioni desktop, quindi programmi. Ok!

Passiamo a React.

React, come ti ho detto prima, non è un framework, ma bensì è una libreria. E si occupa soltanto della gestione della UI. Quindi interfaccia utente e lo fa in maniera molto efficiente. O almeno è nato con questo scopo. Essendo una libreria la puoi usare in progetti già avviati dove magari hai un sacco di librerie che già usi, è già tutto pronto, però vuoi dire “voglio utilizzare la potenza di React per gestire soltanto la V del mio MVC”, bene. Lo puoi fare. Cosa che invece non puoi fare con Angular e con gli altri framework.

Ora l’altra cosa interessante di React è che si porta dietro un ecosistema di strumenti che essenzialmente sono tutti indipendenti. E puoi utilizzarli con React, però volendo li puoi utilizzare anche da soli o con altri strumenti. Un pochino come appunto puoi fare con React stesso.

Il primo è JSX e sta per Javascript Exstension. Essenzialmente è un insieme di Javascript, di Template Engine e di HTML. Molti programmatori criticano questo mix perché stiamo andando a fondere del Javascript e dell’HTML assieme e la cosa non piace perché stiamo fondendo un linguaggio con l’HTML. E questo è male. È male per tutte quelle che sono le concezioni classiche dello sviluppo. In realtà ci siamo accorti che da qui in poi non vale più niente di quello che valeva tecnicamente nello sviluppo backend, ma è proprio un’altra concezione. E dobbiamo cominciare a ragionare per componenti. Quindi per quanto mi riguarda JSX non è nulla di male, anzi. Può anche essere d’aiuto e diventa molto leggibile.

Poi andiamo avanti e parliamo di Flux e di Redux. Partiamo da Flux. Flux in realtà non è un framework, non è una libreria, è semplicemente una struttura per l’architettura della tua applicazione. È stata ideata da Facebook e tendenzialmente è molto utile quando si vanno a sviluppare dei progetti molto complessi e molto grandi. E ti dice e ti consiglia Facebook come dovresti strutturare la tua applicazione utilizzando React se vuoi andare a gestire dei progetti così grandi. Una delle implementazioni più famose dell’architettura Flux è appunto Redux. E a questo punto Redux è proprio appunto una libreria che puoi andare ad utilizzare assieme a React, ma volendo anche all’esterno, quindi con altre librerie, senza problemi e ti permette di implementare la struttura di Flux. Diciamo che Flux è una sorta di contrapposizione all’MVC. Ovviamente il Flux è basato su componenti, mentre invece l’MVC è basato sullo sviluppo classico. Poi, andiamo avanti.

Abbiamo Relay Modern che non è altro che una sorta di client framework per andare ad utilizzare GraphQL. GraphQL è sempre sviluppato da Facebook ed è un’evoluzione del REST API. Cioè, al posto di effettuare delle singole chiamate http al nostro server API, andiamo ad effettuare delle query lato client. Andando a specificare gli attributi che ci servono e così via. Lo so, sembra una cosa strana, infatti è particolare. Con Relay Modern possiamo andare a definire addirittura la relazione che c’è tra i dati quindi i vari attributi delle query e i nostri componenti. Ti lascio un link in descrizione. Nello specifico ti lascio il link di un sito che si chiama Apollo che ti permette di poter sviluppare in vari linguaggi di programmazione lato server andando appunto a utilizzare la tecnologia GraphQL. Ah, aspetta un momento!

Mi stavo dimenticando di Vue.JS. In realtà Vue ha un approccio intermedio, per questo l’ho posizionato qua in mezzo. Perché va a prendere alcune delle cose, delle peculiarità interessanti dei framework di seconda generazione pur restando vicino ai framework di prima generazione.

Nuove tecnologie legate al mondo Javascript

Poi parliamo di altre tecnologie che non ho potuto inserire all’interno di questa lista perché ripeto, c’è tantissima roba da dire e io ho cercato di riassumerti e tutto. Quindi parliamo di Web Component che essenzialmente sono dei “tag” personalizzati HTML che possono essere utilizzati nei vari browser. Esempio pratico: prova a pensare al tag “video” dell’HTML 5. Ecco, quel tag video, se noi lo apriamo con Firefox o con Chrome ci aprirà due player differenti. Bene, quello lo possiamo considerare una sorta di antenato di Web Component. I Web Component possono essere sviluppati in realtà da qualsiasi sviluppatore e possono essere inseriti in una sorta di catalogo. Ti lascio anche qua il link in descrizione. È un concetto interessante che si sta sviluppando negli ultimi anni. Attualmente non sono ancora uno standard quindi non vengono supportati da tutti i browser. Poi, andiamo avanti! Mi sta mancando la voce… Cerchiamo di fare in fretta.

Abbiamo ASM.JS + Emscripten che essenzialmente prendono dei codici C e C++, li convertono in codici Javascript e permettono di eseguirli in tutti i browser, ma non solo nei browser come abbiamo visto prima. Essenzialmente hanno provato a prendere l’Unreal Engine 4, quindi il motore grafico dei giochi e l’hanno convertito in Javascript per farlo uscire nei browser. Fantastico! Andiamo avanti.

Abbiamo il Web Assembly che non ho citato. È essenzialmente un’evoluzione del Javascript. Possiamo scrivere dei codici in vari linguaggi di programmazione, poi compiliamo questi codici e li convertiamo in Web Assembly. Ecco, questo nuovo linguaggio può essere eseguito dai nuovi browser. Ovviamente non tutti i browser moderni lo supportano però si sta andando verso questa direzione. Ok! Finalmente il video è finito!

Conclusione

Volevo dirti una cosa importante: io in questo momento esatto sono in Giappone quindi se lasci dei commenti, se mi mandi dei messaggi privati non ti posso rispondere. Ad ogni modo ti lascio dei link in descrizione. Un link per ogni singolo argomento che ti ho citato sulla lavagna più alcuni video speciali che trovo veramente belli. Il primo, come ti ho detto prima, è quello su RxJS, ma te ne lascio un altro su WebPack sempre in italiano e poi ti lascio un altro link speciale che si chiama “Potrebbe non servirti un framework” ed è proprio del 2017, quindi recentissimo e si basa su React. È interessante perché va a scomporlo andando a sostituire ogni singola parte con delle librerie. Io l’ho trovato molto educativo dicendo così, potrebbe esserti molto utile. Te lo lascio come al solito in descrizione.

Benissimo, finalmente il video è finito! E io ti chiedo di non lasciare un like, te lo giuro, fallo per me, non lasciarlo. Al posto del like, scrivimi un commento. Scrivimi cosa ne pensi, se ti è piaciuto, se non ti è piaciuto, se ti è stato utile. Ok, dimmi qualcosa di te. Conosciamoci, diventiamo amici. Poi se addirittura vuoi proporre dei nuovi argomenti per lo spiegone del prossimo mese di gennaio allora vieni nel gruppo chiuso che ho creato, la Developer Society. Al suo interno troverai un sondaggio e in questo sondaggio puoi proporre dei nuovi argomenti. Ok? Il più votato verrà utilizzato per lo spiegone del prossimo mese.

L’ultima cosa finale è che in realtà l’argomento che ha vinto lo scorso mese era Frontend Framework in Javascript però io ho, diciamo, rielaborato la domanda e ho deciso di fare questo. Se invece sei interessato ad un’effettiva comparazione dei frontend framework, quindi di Angular, di React, di Vue e così via, almeno questi sono i tre più importanti, puoi riproporre quello e magari vediamo di farla. Ok, ti ho detto tutto, ti posso lasciare in pace. Ti auguro buone feste, buona programmazione soprattutto e adesso io vado a prendere il volo per il Giappone.

Quindi sayonara!