Questa è la traduzione italiana dall’articolo di Jose Aguinaga ‘How it feels to learn JavaScript in 2016’.Ho sentito la necessità di tradurre il documento per la sua ironia, che al contempo rappresenta perfettamente lo stato delle JS-cose. Così rimango felicemente a terra con le mie app native. Link quì
</div>
Allora, ho questo nuovo progetto web ma, ad essere onesti, è da tempo che non scrivo codice per il web e ho sentito che il panorama è cambiato sensibilmente. Tu sei il web developer più all’avanguardia e aggiornato vero?
Il termine esatto è Ingegnere di Front End, ma si, sono la persona giusta. Mi occupo di web nel 2016. Visualizzazione, player musicali, droni che giocano a calcio, fai tu. Sono appena tornato dal JsConf e ReactCont, pertanto conosco le ultime tecnologie per creare web apps.
Figo! Devo creare una pagina che visualizza le ultime attivitià degli utenti, quindi dovrei soltanto prendere i dati da un endpoint REST e mostrarli in una specie di tabella filtrabile, quindi aggiornarla in caso di aggiornamenti nel server. Pensavo di usare jQuery per scaricare e mostrare i dati.
Oh Gesù, no! Nessuno usa più jQuery. Dovresti provare React, è il 2016.
Ah, OK. Cos’è React?
</div>
È una libreria fighissima creata da qualche pazzo di Facebook. Consente controllo e prestazioni massime per la tua applicazione, consentendo di gestire qualsiasi aggiornamento con estrema semplicità.
Sembra interessante. Posso usare React per visuaizzare i dati del server?
Si, ma prima devi aggiungere le librerie React e React DOM alla tua pagina web.
Perché due librerie?
Una è la libreria effettiva e l’altra è quella per manipolare il DOM, che ora puoi scrivere in JSX.
JSX? Cos’è JSX?
</div>
JSX è semplicemente un’estensione di JavaScript che somiglia molto a XML. È di fatto un modo alternativo per rappresentare il DOM, un HTML migliore.
Che c’è che non va nel HTML?
È il 2016. Nessuno scrive più direttamente in HTML
Va bene. Comunque, se aggiungo queste due librerie poi posso usare Reac?
Non proprio. Devi aggiungere Babel, quindi puoi usare React.
Un’altra libreria? Cos’è Babel?
Dunque, Babel è un trans-compilatore che consente di appoggiarti a specifiche versioni di JavaScript, così da poter scrivere codice in una qualsiasi versione di JavaScript. Non è necessario che includi Babel per usare ReactJS, ma se non lo fai sei costretto ad utilizzare ES5 e, siamo onesti, è il 2016, quindi dovrescri scrivere in ES2016+, come fa la gente che ne sa.
ES5? ES2016+? Mi sto perdendo in giro? Cosa sono ES5 e ES2016+?
ES5 sta per ECMAScript 5. È l’edizione più utilizzata dalla maggior parte dei browser attuali.
ECMAScript?
</div>
Si, vedi, lo standard di JavaScript era basato su quello del 1999, dopo il suo rilascio iniziale del 1995, quando ancora era chiamato Livescript e girava solo su Netscape Navigator. Era un vero casino, ma fortunatamente ora le cose sono molto più definite e abbiamo tipo 7 edizioni di questa implementazione.
7 edizioni. Dici davvero?. Quindi ES5 e ES2016+ sarebbero?
Rispettiamente la quinta e la settima edizione.
Fermo, che ne è stato della sesta?
Intendi ES6? Certo, voglio dire, ogni edizione è un superset della precedente, quindi se utilizzi ES2016+, stai di fatto usando tutte le funzionalità delle precedenti versioni.
Va bene. Perché però usare ES2016+ anziché ES6?
Dunque, potresti teoricamente usare ES6, ma per avere funzioni toste come async e await, devi utilizzare ES2016+. In caso contrario sei fermo a generatori ES6 con co-routine che bloccano le chiamate asincrone che ti consentono un controllo di flusso ottimale.
Non ho idea di quello che hai detto e tutti questi nomi mi confondono. Senti, sto solo cercando di caricare qualche dato da un server, cosa che ero in grado di fare semplicemente includendo jQuery da un CDN a ottenere i dati con chiamate AJAX. Perché non posso più farlo?
È il 2016. Nessuno utilizza più jQuery. La finisci con una manciati di codice a spaghetto. Lo sanno tutti.
Ok. Quindi l’alternativa è caricare tre librerie per leggere i dati e mostrarle in una tabella HTML.
Beh, includi queste tre librerie, ma poi le devi impaccare con un module manager per caricare un solo file.
Ok, e cosa sarebbe un module manager?
</div>
La definizione dipende dall’ambiente, ma nel web intendiamo qualsiasi cosa che supporti moduli AMD o CommonJS.
Ooook, e cosa sarebbero AMD e CommonJS?
Definizioni. Ci sono modi di descrivere come molteplici librerie e classi JavaScript dovrebbero interagire. Hai presente exports e requires? Puoi creare più file JavaScript definendo le API AMD e CommonJS, quindi utilizzare roba tipo Browserify per metterle insieme.
Ok, la cosa sembra avere senso, credo. Cos’è Browserify?
È uno strumento che ti consente di “impaccare” dipendenze CommonJS in file che possano essere eseguiti nel browser. È stato creato dal momento che la maggior parte delle persone pubblica queste dipendenze nel registro npm.
Registro npm?
È un gigantesco deposito pubblico dove gente in gamba mette codice e dipendenze sottoforma di moduli.
Come un CDN?
Non proprio. È più un database centralizzato dove ognuno può pubblicare e scaricare librerie, così che si possano utilizzare localmente per lo sviluppo e quindi caricate su un CDN se vuoi.
Capito! Come Bower!
Si, ma è il 2016. Nessuno utilizza più Bower.
Perfetto, quindi devo scaricare queste librerie da npm?
Si. Se per esempio, vuoi utilizzare React, scarichi il modulo React e lo importi nel tuoi codice. Puoi fare lo stesso per la maggior parte delle librerie JavaScript disponibili.
Ottimo, come Angular!
Angular è molto 2015, ma si. Ci trovi Angular, come VueJS o RxJS e altre librerie fighe. Ne vuoi sapere di qualcuna?
Rimaniamo per ora su React, sto imparando un po’ troppe cose al momento. Quindi, se voglio utilizzare React lo scarico da questo npm e uso la cosa del Browserify, esatto?
Si
Mi pare un tantino complicato solo per scaricare qualche dipendenza e metterle assieme.
In effetti lo è. Per questo usi un task manager come Grunt o Gulp o Broccoli per automatizzare l’esecuzione di Browserify. Puoi anche usare Mimosa.
Grunt? Gulp? Broccoli? Mimosa? Di che diavolo parli ora?
</div>
Task managers. Ma non sono più tanto fighi. Li usavamo tipo nel 2015, poi siamo passati ai Makefiles, ma ora si tende ad impaccare tutto con Webpack.
Makefiles? Pensavo venissero usati principalmente per progetti C o C++.
Già, ma a quanto pare nel web ci piace fare cose complicate per poi tornare alle origini. Lo facciamo ogni tanto. Vedrai che finiremo con usare l’assembler in un anno o due!
Cristo! Hai menzionato qualcosa chiamato Webpack?
È un altro module manager per il browser, che contemporaneamente è anche un task runner. È come una migliore versione di Browserify.
Ok, ok. Qual’è meglio?
Beh, forse non meglio, dipende da come vuoi che siano collegate le tue dipendenze. Webpack ti consente di utilizzare module manager diversi e non solo CommonJS, come per esempio moduli nativi ES6.
Sono estremamente confuso da questa cosa CommonJS/ES6.
Tutti lo siamo, ma con SystemJS non ce ne dovremmo più preoccupare.
Madre santissima, un’altra JS-cosa. Cos’è SystemJS?
Allora, a differenza di Browserify e Webpack 1.x, SystemJS è un modulo a caricamento dinamico che consenti di collegare moduli multipli in file diversi anziché conglobarli in uno unico.
Aspetta, avevo capito che l’intenzione fosse quella di unire le nostre librerie in un unico file e caricarlo!
Si, ma dal momento che sta arrivando HTTP/2, sarà molto meglio utilizzare richieste HTTP multiple.
Un attimo. Quindi non possiamo semplicemente aggiungere le tre librerie originali per React??!!
Non proprio. Voglio dire, puoi sempre aggiungerle come script esterni da un CDN, ma dovrai comunque includere anche Babel.
E questa non è una bella cosa vero?
Esatto. Finiresti per includere tutto il core di Babel e non sarebbe efficiente in produzione. In produzione hai la necessità di eseguire una serie di pre-task per affinché il tuo progetto sia pronto. Devi “minificare” gli assets, “uglificarli”, inserire i CSS inline, preporre gli script, poi…
Capito, capito! Quindi tu non includeresti le librerie direttamente in un CDN. Come faresti?
Utilizzerei un trans-compilatore da Typescript utilizzando Webpack + SystemJS + Babel.
Typescript? Pensavo si programmasse in JavaScript!
Typescript È JavaScript o, diciamo, un superset di JavaScript. Più precisamente una specie di JavaScript versione ES6. Hai presente la sesta versione di cui abbiamo parlato prima?
Pensavo ES2016+ fosse già un superset di ES6! Perché adesso viene fuori questa cosa chiamata Typescript?
Eh, perché consente di utilizzare JavaScript come linguaggio tipizzato e riduce gli errori di runtime. È il 2016 ed è davvero necessario aggiungere i tipi al tuo codice JavaScript.
E ovviamente Typescript fa questo, immagino.
Così come Flow, benché controlli soltanto la tipizzazione, mentre Typescript è un superset di JavaScript che deve essere compilato.
Nooo…e Flow sarebbe?
</div>
È un verificatore di tipo statico fatto da gente di Facebook. L’hanno scritto in OCaml, perché la programmazione funzionale è una figata.
OCaml? Programmazione funzionale?
È quello che la gente tosta utilizza ora, hai presente, nel 2016? Programmazione funzionale, funzioni di alto ordine, currying, funzioni pure?
Capito nulla di quello che hai detto.
Nessuno lo capisce all’inizio. Senti, devi solo sapere che la programmazione funzionale è meglio della OOP ed è ciò che dovremmo usare nel 2016.
Aspetta, ho imparato la OOP a scuola. Mi pareva andasse bene.
Cosi come andava bene Java prima che fosse acquisito da Oracle. Voglio dire, OOP era ok ai suoi tempi e viene ancora usata, ma tutti stanno capendo che la modifica degli stati è l’equivalente del picchiare le vecchiette, pertanto tutti si stanno spostando verso l’immutabilità degli oggetti e la programmazione funzionale. Quelli di Haskell l’hanno capito da tempo, per non parlare dei tipi di Elm, ma fortunatamente nel web abbiamo librerie come Ramnda che ci consente di utilizzare la programmazione funzionale in JavaScript.
Ma senti, stai buttando nomi a pera giusto per il gusto o davvero fai? Che diavolo è Ramnda?
No dico sul serio. Ramnda, come Lambda. Hai presente la libreria di David Chambers?
David chi?
</div>
Davi Chambers. Tipo tosto. Uno dei creatori di Ramnda. Dovresti anche dare un occhio a Erik Meijer se vuoi studiare seriamente la programmazione funzionale.
E Erik Meijer sarebbe?
Anche lui dietro la programmazione funzionale. Tipo affascinante. Trovi un po’ di presentazioni dove butta alle ortiche Agile, indossando questa folle camicia colorata. Dovresti cercare anche roba di Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-
Ok, a questo punto ti fermo. Sembra tutto buono e va bene, ma penso solo che sia tutto troppo complicato e non necessario solo per scaricare dei dati e mostrarli. Sono abbastanza certo di non aver bisogno di conoscere tutta questa gente o imparare tutte quelle cose per creare una tabella con dati dinamici. Torniamo a React per favore. Come estraggo i dati dal server con React?
In realtà non scarici i dati con React, li visualizzi soltanto.
Ma porc…Quindi cosa utilizziamo per scaricare i dati?
Utilizzi Fetch per scaricare i dati dal server.
Scusa, utilizzi Fetch per “fetchare” i dati? Chiunque abbia dato il nome a questa roba merita il Nobel.
Fetch è il nome dell’implementazione nativa di XMLHttpRequest verso un server.
Ah, quindi AJAX.
</div>
AJAX è solo l’utilizzo delle XMLHttpRequests. Ma certo, Fetch ti consente di eseguire AJAX basandoti sulle Promises, che quindi puoi risolvere, senza dover ricorrere a cose infernali come le Callback.
Cose infernali come le Callback?
Certo. Ogni volta che esegui una richiesta asincrona ad un server, devi attendere la risposta, il che ti costringe ad aggiungere una funzione dentro a una funzione. La cosa è chiamata la piramide infernale delle callback.
Ah, ok. E questa cosa della “promise” risolve la questione.
Infatti. Manipolando le tue callback attraverso le “promises” o “promesse”, puoi scrivere codice più facile da leggere, adattare e provare, così come eseguire richieste simultanee in un solo colpo e attendere il completamento di tutti i caricamenti.
E immagino che tutto questo sia fatto utilizzando Fetch?
Si, ma solo se i tuoi utenti utiilzzano browser aggiornati, altrimenti devi includere dei Fetch polyfill o utilizzare Request, Bluebird o Axios.
Ma di quante librerie ho bisogno? Quante sono?
È JavaScript. Probabilmente ci sono migliaia di librerie che fanno la stessa cosa. Conosciamo le librerie e di fatto abbiamo le migliori librerie. Le nostre librerie sono immense, e a volte ci includiamo pure le immagini di Guy Fieri.
Hai detto Guy Fieri? Saltiamo questo passaggio va bene? Cosa fanno queste librerie come Bluebird, Request e Axios?
Sono librerie per eseguire XMLHttpRequest che ritornano “promises”.
Ma il metodo AJAX di jQuery non aveva iniziato a restituire “promesse” pure lui?
Non utilizziamo più la parola “J” nel 2016. Semplicemente utilizza Fetch, e applica un polyfill se non è in un browser oppure utilizza Bluebird, Request or Axios. A questo punto gestisci la “promessa” con await dall’interno di una funzione asincrona e fatto: hai un controllo di flusso come si deve.
È la terza volta che menzioni await ma non ho la minima idea di cosa sia.
Await ti consente di bloccare una chiamata asincrona, dandoti un miglior controllo su quando i dati sono scaricati e incrementando la leggibilità del codice. È fantastico, devo solo accertarti di aggiungere il preset stage-3 in Babel, oppure utilizzare i plugin syntax-async-functions e transform-async-to-generator.
Siamo alla follia!
</div>
No, è folle che si debba pre-compilare il codice Typescript e quindi trans-compilarlo con Babel per utilizzare await.
Che? Non è incluso in Typescript?
Lo sarà nella prossima versione, ma sino alla 1.7 funziona solo con ES6, quindi se vuoi utilizzare wait nel browser, prima devi compilare il tuo codice Typescript e renderlo compatibile con ES6, quindi passarlo a Babel che lo rende compatibile con ES5.
Mi hai perso.
Senti, è semplice. Scrivi tutto in Typescript. Tutti i moduli che utilizzano Fetch compilano e rendono compatibile con ES6, quindi trans-compila con Babel su un preset in stage-3, poi carica il tutto con SystemJS. Se non hai Fetch, “polyfillalo” o usa Bluebird, Request o Axios, e gestisci tutte le “promises” con await.
Abbiamo visioni differenti di “semplice”. Quindi, alla fine di questo rituale o scaricato i dati e ora posso visualizzarli con React, giusto?
La tua applicazione deve gestire qualche cambio di stato?
Ehm, non credo. Devo solo mostrare i dati.
Bene, questo è bene. Altrimenti ti dovrei parlare di Flux e implementazioni come Flummox, Alt, Fluxible. La mia opinione è che dovresti utilizzare Redux.
Fingerò di non avere mai sentito questi nomi. Te lo ripeto, devo solo visualizzare dei dati.
Ah ok, se devi solo visualizzare dei dati non hai bisogno a tutti i costi di React. Potresti usare un semplice templating engine.
Mi prendi per il culo? Pensi sia divertente? È così che tratti le persone care?
Ti stavo solo spiegando cosa potresti utilizzare.
Basta.
Voglio dire, anche utilizzando un templating engine, io userei comunque Typescript + SystemJS + Babel se fossi in te.
Devo visualizzare dei dati in una pagina, non eseguire MK Sub Zero. Dimmi solo il templating engine da utilizzare.
Ce ne sono una miriade. Con quale ti trovi meglio?
Boh. Non mi ricordo il nome. È stato tanto tempo fa.
jTemplates? jQote? PURE?
</div>
No, non mi dicono diente. Un altro?
Transparency? JSRender? MarkupJS? KnockoutJS? Quello ha il binding a due view.
Un altro?
PlatesJS? jQuery-tmpl? Handlebars? Alcuni ancora lo usano.
Forse. Ce ne sono similari a quest’ultimo?
Mustache, underscore? Credo anche lodash ne abbia uno, ma è roba da 2014.
Ehm, magari era più recente.
Jade? DustJS?
No.
DotJS? EJS?
No.
Nunjucks? ECT?
No.
-Mah, a nessuno piace la sintassi di Coffeescript. Jade?
No, Jade l’hai già detto.
Volevo dire Pug, cioè Jade. Nel senso che Jade ora si chiama Pug.
Oddio. No. Non ricordo. Quale useresti tu?
Probabilmente solo template strings native ES6.
Fammi indovinare, questo necessita di ES6.
Esatto.
Che, in funzione del browser utilizzato, necessita di Babel.
Esatto.
Che, se voglio includerlo senza aggiungere tutta la libreria core, devo caricare come modulo da npm.
Esatto.
Che richiede Browserify o Wepback o meglio quell’altra cosa chiamata SystemJS.
Esatto.
Che, se non è Webpack, dovrebbe idealmente essere gestita da un task runner.
Esatto.
Ma, dal momento che dovrei adottare la programmazione funzionale e linguaggi tipizzati, dovrei prima pre-complare Typescript o infilarlo in quella Flow-cosa.
Esatto.
E quindi inviare il tutto a Babel se voglio utilizzare await.
Esatto.
Così che possa utilizzare Fetch, promises, il controllo di flusso e tutte quelle cose magiche.
Solo non dimenticare di applicare il polyfill a Fetch se non è supportato. Safari ad esempio ancora non lo gestisce.
La sai una cosa? Direi che finiamo qui. Anzi direi che io la finisco qui. Ho chiuso con il web e ho chiuso pure con JavaScript.
Va bene. Tra qualche anno staremo tutti programmando con Elm o WebAssembly.
Passerò al backend. Non posso gestire tutte queste cose e versioni e edizioni e compilatori e trans-compilatori. La comunità JavaScript è completamente folle se pensa che qualcuno possa stare dietro a tutto questo.
Capito. Dovresti provare la comunità Python.
Perché?
