Come ci si sente ad imparare JavaScript nel 2016

Durante la stesura di questo articolo non è stato creato alcun framework JavaScript .

Quanto segue è ispirato all'articolo "It's the future" di Circle CI. Puoi leggere l'originale qui . Questo pezzo è solo un'opinione e, come qualsiasi framework JavaScript, non dovrebbe essere preso troppo sul serio.

Ciao, ho questo nuovo progetto web, ma a dire il vero non ho scritto molto codice web negli ultimi anni e ho sentito che il panorama è cambiato un po'. Tu sei lo sviluppatore web più aggiornato qui, giusto?

-Il termine esatto è Front End engineer, ma sì, sono la persona giusta. Mi occupo di web nel 2016. Visualizzazioni, lettori musicali, droni volanti che giocano a calcio, e così via. Sono appena tornato da JsConf e ReactConf, quindi conosco le ultime tecnologie per creare app web.

Fantastico. Devo creare una pagina che mostri le ultime attività degli utenti, quindi devo solo ottenere i dati dall'endpoint REST e visualizzarli in una sorta di tabella filtrabile, e aggiornarla se qualcosa cambia nel server. Stavo pensando di usare jQuery per recuperare e visualizzare i dati?

-Oh mio dio no, nessuno usa più jQuery. Dovresti provare a imparare React, siamo nel 2016.

Oh, ok. Cos'è React?

-È una libreria fantastica creata da alcuni ragazzi di Facebook, che apporta davvero controllo e prestazioni alla tua applicazione, consentendoti di gestire con estrema facilità qualsiasi modifica alla visualizzazione.

Sembra carino. Posso usare React per visualizzare i dati dal server?

-Sì, ma prima devi aggiungere React e React DOM come libreria nella tua pagina web.

Aspetta, perché due biblioteche?

-Quindi una è la libreria vera e propria e la seconda serve per manipolare il DOM, che ora puoi descrivere in JSX.

JSX? Che cos'è JSX?

-JSX è solo un'estensione della sintassi JavaScript che assomiglia molto a XML. È un altro modo per descrivere il DOM, pensalo come un HTML migliore.

Cosa c'è che non va nell'HTML?

-Siamo nel 2016. Nessuno codifica più direttamente in HTML.

Giusto. Comunque, se aggiungo queste due librerie posso usare React?

-Non proprio. Devi aggiungere Babel, e poi sarai in grado di usare React.

Un'altra biblioteca? Cos'è Babel?

-Oh, Babel è un transpiler che ti consente di indirizzare specifiche versioni di JavaScript, mentre codifichi in qualsiasi versione di JavaScript. Non DEVI includere Babel per usare ReactJS, ma se non lo fai, sei costretto a usare ES5, e diciamoci la verità, siamo nel 2016, dovresti programmare in ES2016+ come fanno tutti i ragazzi più cool.

ES5? ES2016+? Mi sto perdendo. Cosa sono ES5 e ES2016+?

-ES5 sta per ECMAScript 5. È l'edizione a cui mirano la maggior parte delle persone, poiché è stata implementata dalla maggior parte dei browser odierni.

ECMAScript?

-Sì, sai, lo standard di scripting su cui si basava JavaScript nel 1999 dopo la sua prima release nel 1995, quando JavaScript si chiamava Livescript e girava solo su Netscape Navigator. All'epoca era molto complicato, ma per fortuna ora le cose sono molto chiare e abbiamo, tipo, 7 edizioni di questa implementazione.

7 edizioni. Davvero. E ES5 e ES2016+ lo sono?

-Rispettivamente la quinta e la settima edizione.

Aspetta, cosa è successo con il sesto?

-Intendi ES6? Sì, intendo dire che ogni edizione è un superset della precedente, quindi se stai usando ES2016+, stai usando tutte le funzionalità delle versioni precedenti.

Giusto. E allora perché usare ES2016+ invece di ES6?

-Beh, POTRESTI usare ES6, ma per usare funzioni interessanti come async e await, devi usare ES2016+. Altrimenti sei bloccato con i generatori ES6 con coroutine per bloccare le chiamate asincrone per un flusso di controllo appropriato.

Non ho idea di cosa hai appena detto, e tutti questi nomi sono fonte di confusione. Guarda, sto solo caricando un mucchio di dati da un server, prima potevo semplicemente includere jQuery da una CDN e ottenere i dati con chiamate AJAX, perché non posso semplicemente farlo?

- Siamo nel 2016, amico, nessuno usa più jQuery, finisce in un mucchio di codice spaghetti. Lo sanno tutti.

Giusto. Quindi la mia alternativa è caricare tre librerie per recuperare i dati e visualizzare una tabella HTML.

-Bene, puoi includere queste tre librerie ma raggrupparle con un gestore di moduli per caricare un solo file.

Capisco. E cos'è un gestore di moduli?

-La definizione dipende dall'ambiente, ma nel web in genere intendiamo tutto ciò che supporta i moduli AMD o CommonJS.

Giusto. E AMD e CommonJS sono...?

-Definizioni. Ci sono modi per descrivere come più librerie e classi JavaScript dovrebbero interagire. Sai, exports e requires? Puoi scrivere più file JavaScript che definiscono l'API AMD o CommonJS e puoi usare qualcosa come Browserify per raggrupparli.

OK, ha senso... credo. Cos'è Browserify?

-È uno strumento che consente di raggruppare le dipendenze descritte da CommonJS in file che possono essere eseguiti nel browser. È stato creato perché la maggior parte delle persone pubblica tali dipendenze nel registro npm.

registro npm?

-È un repository pubblico molto grande in cui le persone intelligenti inseriscono codice e dipendenze come moduli.

Ti piace una CDN?

-Non proprio. È più simile a un database centralizzato in cui chiunque può pubblicare e scaricare librerie, così puoi usarle localmente per lo sviluppo e poi caricarle su una CDN se vuoi.

Oh, come Bower!

-Sì, ma ormai siamo nel 2016 e nessuno usa più Bower.

Ah, capisco... quindi devo scaricare le librerie da npm?

-Sì. Quindi, ad esempio, se vuoi usare React, scarichi il modulo React e lo importi nel tuo codice. Puoi farlo per quasi tutte le librerie JavaScript più diffuse.

Oh, come Angular!

-Angular è così 2015. Ma sì. Angular sarebbe lì, insieme a VueJS o RxJS e altre fantastiche librerie del 2016. Vuoi saperne di più?

Restiamo con React, sto già imparando troppe cose. Quindi, se ho bisogno di usare React, lo prendo da questo npm e poi uso questa cosa di Browserify?

-SÌ.

Sembra eccessivamente complicato prendere semplicemente un mucchio di dipendenze e collegarle insieme.

-Lo è, ecco perché usi un task manager come Grunt o Gulp o Broccoli per automatizzare l'esecuzione di Browserify. Cavolo, puoi anche usare Mimosa.

Grugnito? Gulp? Broccoli? Mimosa? Di cosa diavolo stiamo parlando adesso?

-Task manager. Ma non sono più cool. Li abbiamo usati nel 2015, poi abbiamo usato i Makefile, ma ora incartiamo tutto con Webpack.

Makefile? Pensavo che fossero usati soprattutto nei progetti C o C++.

-Sì, ma a quanto pare nel web ci piace complicare le cose e poi tornare alle basi. Lo facciamo ogni anno o giù di lì, aspetta un attimo, faremo l'assemblaggio nel web tra un anno o due.

Sigh. Hai menzionato qualcosa chiamato Webpack?

-È un altro gestore di moduli per il browser, ma è anche una specie di task runner. È come una versione migliore di Browserify.

Oh, ok. Perché è meglio?

-Beh, forse non meglio, è solo più opinabile su come le tue dipendenze dovrebbero essere legate. Webpack ti consente di usare diversi gestori di moduli, e non solo quelli CommonJS, quindi per esempio moduli nativi supportati da ES6.

Sono estremamente confuso da tutta questa faccenda di CommonJS/ES6.

-Lo sono tutti, ma con SystemJS non dovresti più preoccuparti.

Gesù Cristo, un altro sostantivo-js. Ok, e cos'è questo SystemJS?

-Beh, a differenza di Browserify e Webpack 1.x, SystemJS è un caricatore di moduli dinamico che consente di collegare più moduli in più file anziché raggrupparli in un unico file di grandi dimensioni.

Aspetta, ma pensavo che volessimo creare le nostre librerie in un unico grande file e caricarlo!

-Sì, ma poiché HTTP/2 è ora disponibile, le richieste HTTP multiple sono in realtà migliori.

Aspetta, quindi non possiamo semplicemente aggiungere le tre librerie originali per React?

-Non proprio. Voglio dire, potresti aggiungerli come script esterni da una CDN, ma dovresti comunque includere Babel.

Sospiro. E questo è un male, vero?

-Sì, includeresti l'intero babel-core e non sarebbe efficiente per la produzione. In produzione devi eseguire una serie di pre-attività per preparare il tuo progetto che fanno sembrare il rituale per evocare Satana una ricetta di uova sode. Devi minimizzare le risorse, renderle brutte, inserire css inline sopra la piega, rinviare gli script e-

Ho capito, ho capito. Quindi se non dovessi includere le librerie direttamente in una CDN, come faresti?

-Lo transpilerei da Typescript utilizzando una combinazione Webpack + SystemJS + Babel.

TypeScript? Pensavo che stessimo programmando in JavaScript!

-Typescript È JavaScript, o meglio, un superset di JavaScript, più specificamente JavaScript nella versione ES6. Sai, quella sesta versione di cui abbiamo parlato prima?

Pensavo che ES2016+ fosse già un superset di ES6! PERCHÉ ora abbiamo bisogno di questa cosa chiamata Typescript?

-Oh, perché ci consente di usare JavaScript come linguaggio tipizzato e ridurre gli errori di runtime. Siamo nel 2016, dovresti aggiungere alcuni tipi al tuo codice JavaScript.

E TypeScript ovviamente fa questo.

-Flow, anche se controlla solo la digitazione, mentre Typescript è un superset di JavaScript che deve essere compilato.

Sigh… e Flow?

-È un verificatore di tipi static fatto da alcuni ragazzi di Facebook. L'hanno codificato in OCaml, perché la programmazione funzionale è fantastica.

OCaml? Programmazione funzionale?

-È quello che usano i ragazzi fighi oggigiorno, amico, sai, 2016? Programmazione funzionale? Funzioni di ordine elevato? Currying? Funzioni pure?

Non ho idea di cosa hai appena detto.

-Nessuno lo fa all'inizio. Guarda, devi solo sapere che la programmazione funzionale è migliore della OOP ed è quella che dovremmo usare nel 2016.

Aspetta, ho imparato la programmazione orientata agli oggetti all'università, pensavo fosse una buona idea?

-Così era Java prima che Oracle lo acquistasse. Voglio dire, la OOP andava bene ai vecchi tempi, e ha ancora i suoi usi oggi, ma ora tutti si stanno rendendo conto che modificare gli stati equivale a dare calci ai bambini, quindi ora tutti si stanno spostando verso oggetti immutabili e programmazione funzionale. I ragazzi di Haskell lo chiamavano così da anni, -e non fatemi iniziare con i ragazzi di Elm- ma fortunatamente nel web ora abbiamo librerie come Ramda che ci permettono di usare la programmazione funzionale in semplice JavaScript.

Stai solo facendo nomi per il gusto di farlo? Che diavolo è Ramnda?

-No. Ramda. Come Lambda. Sai, quella biblioteca di David Chambers?

Davide chi?

-David Chambers. Un tipo simpatico. Gioca un gran gioco di Coup. Uno dei collaboratori di Ramda. Dovresti anche dare un'occhiata a Erik Meijer se vuoi davvero imparare la programmazione funzionale.

E Erik Meijer è…?

-Anche un programmatore funzionale. Un tipo fantastico. Ha un sacco di presentazioni in cui critica l'Agile mentre indossa questa strana maglietta colorata. Dovresti anche dare un'occhiata ad alcune delle cose di Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-

Ok. Vi fermo qui. Tutto ciò è buono e perfetto, ma penso che tutto ciò sia semplicemente così complicato e inutile per il solo recupero dei dati e la loro visualizzazione. Sono abbastanza sicuro di non aver bisogno di conoscere queste persone o di imparare tutte quelle cose per creare una tabella con dati dinamici. Torniamo a React. Come posso recuperare i dati dal server con React?

-Beh, in realtà non si recuperano i dati con React, si limitano a visualizzarli.

Oh, accidenti a me. Quindi cosa usi per recuperare i dati?

-Utilizzare Fetch per recuperare i dati dal server.

Mi dispiace? Utilizzi Fetch per recuperare i dati? Chiunque stia dando un nome a quelle cose ha bisogno di un thesaurus.

-Lo so, vero? Fetch è il nome dell'implementazione nativa per eseguire XMLHttpRequests su un server.

Ah, quindi AJAX.

-AJAX è solo l'uso di XMLHttpRequests. Ma certo. Fetch ti consente di fare AJAX basato su promesse, che poi puoi risolvere per evitare l'inferno del callback.

L'inferno del callback?

-Sì. Ogni volta che esegui una richiesta asincrona sul server, devi attendere la sua risposta, che poi ti fa aggiungere una funzione all'interno di una funzione, che è chiamata la piramide di callback dall'inferno.

Oh, ok. E questa promessa risolve il problema?

-Certo. Manipolando i tuoi callback tramite promesse, puoi scrivere codice più facile da capire, simularli e testarli, oltre a eseguire richieste simultanee in una volta e attendere che siano tutte caricate.

E questo è possibile con Fetch?

-Sì, ma solo se l'utente utilizza un browser evergreen, altrimenti è necessario includere un polyfill Fetch o utilizzare Request, Bluebird o Axios.

Quante biblioteche devo conoscere, per l'amor di Dio? Quante sono?

-È JavaScript. Devono esserci migliaia di librerie che fanno tutte la stessa cosa. Conosciamo le librerie, in effetti, abbiamo le migliori librerie. Le nostre librerie sono enormi, e a volte includiamo immagini di Guy Fieri in esse.

Hai appena detto Guy Fieri? Facciamola finita. Cosa fanno queste librerie Bluebird, Request, Axios?

-Sono librerie per eseguire XMLHttpRequest che restituiscono promesse.

Anche il metodo AJAX di jQuery non ha iniziato a restituire promesse?

-Non usiamo più la parola "J" nel 2016. Usa semplicemente Fetch e polyfill quando non è in un browser o usa Bluebird, Request o Axios. Quindi gestisci la promessa con await all'interno di una funzione asincrona e boom, hai un flusso di controllo appropriato.

È la terza volta che nomini wait ma non ho idea di cosa sia.

-Await ti consente di bloccare una chiamata asincrona, consentendoti di avere un controllo migliore su quando i dati vengono recuperati e aumentando complessivamente la leggibilità del codice. È fantastico, devi solo assicurarti di aggiungere il preset stage-3 in Babel, o usare syntax-async-functions e il plugin transform-async-to-generator.

Questa è una follia.

- No, è assurdo che tu debba precompilare il codice Typescript e poi transpilarlo con Babel per usare await.

Cosa? Non è incluso in TypeScript?

- Lo fa nella prossima versione, ma a partire dalla versione 1.7 è destinato solo a ES6, quindi se vuoi usare await nel browser, devi prima compilare il codice Typescript destinato a ES6 e poi Babel trasformarlo in un target per ES5.

A questo punto non so cosa dire.

-Guarda, è facile. Codifica tutto in Typescript. Tutti i moduli che usano Fetch li compilano per target ES6, li transpilano con Babel su un preset stage-3 e li caricano con SystemJS. Se non hai Fetch, polyfill, o usa Bluebird, Request o Axios, e gestisci tutte le tue promesse con await.

Abbiamo definizioni molto diverse di facile. Quindi, con quel rituale ho finalmente recuperato i dati e ora posso visualizzarli con React, giusto?

-La tua applicazione gestirà eventuali cambiamenti di stato?

Ehm, non credo. Ho solo bisogno di visualizzare i dati.

-Oh, grazie a Dio. Altrimenti avrei dovuto spiegarti Flux e implementazioni come Flummox, Alt, Fluxible. Anche se a dire il vero dovresti usare Redux.

Passerò semplicemente sopra quei nomi. Di nuovo, ho solo bisogno di visualizzare i dati.

-Oh, se stai solo visualizzando i dati non hai bisogno di React per cominciare. Ti sarebbe bastato un motore di template.

Stai scherzando? Pensi che sia divertente? È così che tratti i tuoi cari?

-Stavo solo spiegando cosa potresti usare.

Basta. Basta.

-Voglio dire, anche se si utilizza solo un motore di template, fossi in te userei comunque una combinazione Typescript + SystemJS + Babel.

Devo visualizzare i dati su una pagina, non eseguire la fatality MK originale di Sub Zero. Dimmi solo quale motore di template usare e me ne occuperò io.

-Ce ne sono molti, quali conosci?

Ugh, non ricordo il nome. È stato tanto tempo fa.

-jTemplate? jCitazione? PURO?

Ehm, non mi dice niente. Un altro?

-Trasparenza? JSRender? MarkupJS? KnockoutJS? Quello aveva un binding bidirezionale.

Un altro?

-PlatesJS? jQuery-tmpl? Manubri? Alcune persone lo usano ancora.

Forse. Ce ne sono di simili a quest'ultimo?

-Baffi, sottolineatura? Penso che ora anche lodash ne abbia uno, per essere onesti, ma quelli sono un po' del 2014.

Ehm... forse era più recente.

-Giada? DustJS?

NO.

Cosa significa?

NO.

-Nunjuck? Elettroshock?

NO.

-Mah, comunque a nessuno piace la sintassi di Coffeescript. Jade?

No, hai già detto Jade.

-Volevo dire Pug. Volevo dire Jade. Voglio dire, Jade ora è Pug.

Sigh. No. Non ricordo. Quale useresti?

-Probabilmente solo stringhe modello native ES6.

Lasciatemi indovinare. E questo richiede ES6.

-Corretto.

Che, a seconda del browser che sto utilizzando, necessita di Babel.

-Corretto.

Se voglio includerlo senza aggiungere l'intera libreria principale, devo caricarlo come modulo da npm.

-Corretto.

Il che richiede Browserify, o Wepback, o più probabilmente quell'altra cosa chiamata SystemJS.

-Corretto.

Che, a meno che non si tratti di Webpack, idealmente dovrebbe essere gestito da un task runner.

-Corretto.

Tuttavia, poiché dovrei utilizzare la programmazione funzionale e i linguaggi tipizzati, devo prima precompilare Typescript o aggiungere questa cosa di Flow.

-Corretto.

E poi inviarlo a Babel se voglio usare await.

-Corretto.

Quindi posso usare Fetch, le promesse, il flusso di controllo e tutta quella magia.

-Non dimenticare di usare polyfill per Fetch se non è supportato: Safari non è ancora in grado di gestirlo.

Sai cosa? Penso che abbiamo finito qui. In realtà, penso di aver finito. Ho finito con il web, ho finito con JavaScript del tutto.

-Va bene, tra qualche anno scriveremo tutti codice in Elm o WebAssembly.

Tornerò semplicemente al backend. Non riesco proprio a gestire tutti questi cambiamenti, versioni, edizioni, compilatori e transpiler. La comunità JavaScript è pazza se pensa che qualcuno possa tenere il passo con tutto questo.

-Ti capisco. Allora dovresti provare la comunità Python.

Perché?

-Hai mai sentito parlare di Python 3?

Aggiornamento: Grazie per aver segnalato errori di battitura e refusi, aggiornerò l'articolo come indicato. Discussione su HackerNews e Reddit .