Vai al contenuto principale

Lo Stato di Babel

· Lettura di 27 min
Henry Zhu
Traduzione Beta Non Ufficiale

Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →

Issue precedenti: Babel Roadmap #4130, 6.0 #2168

Se non altro, date un'occhiata alla sezione sulla Comunità.

Pubblicato anche come parte del Calendario dell'Avvento Web 2016 di Mariko Kosaka!

Un po' di storia​

Sebastian creò "6to5" nel settembre 2014. Curiosamente, lo fece per soddisfare una sua esigenza di comprendere i linguaggi di programmazione e il loro funzionamento. Potreste aver pensato che chi creò il progetto sapesse già come funzionano i compilatori e conoscesse perfettamente JavaScript... ma vi sbagliereste! Leggete il suo post per un resoconto affascinante della sua storia: ~2015 in Review.

6to5 faceva esattamente questo: trasformare facilmente codice ES6 in ES5. Quando 6to5 divenne Babel, come menzionato in Not Born to Die, si trasformò in una piattaforma: una suite di strumenti progettati per creare la prossima generazione di tooling JavaScript. Non si limitava più a compilare ES6 in ES5, ma permetteva agli sviluppatori di costruire strumenti sopra di esso.

Ecco alcune delle nostre pietre miliari:

  • In 5.0.0, Babel si allineò maggiormente al processo TC39 introducendo gli stages, aggiungendo l'opzione di configurazione .babelrc e creando un sistema di plugin per trasformazioni personalizzate.

  • In 6.0.0, Babel divenne modulare (un'idea piuttosto controversa all'epoca). Fu un cambiamento radicale che portò a funzionalità opt-in (nessun default) e ai concetti di Presets e Opzioni dei Plugin.

    • Come menzionato nel suo articolo, Sebastian entrò in Facebook nel luglio 2015 e lavorò all'intero sviluppo di Babel 6 durante l'orario lavorativo.

  • In 6.3.13 Sebastian estrasse i nostri strumenti di build/pubblicazione monorepo in quello che oggi è Lerna. (Il lato divertente è che James lo riscrisse 3 volte e io dovetti revisionare tutto)

    • Dopo questo periodo, sia Sebastian che James entrarono in burnout su Babel, e alcuni contributor presero il loro posto.
    • Abbiamo faticato a trovare una direzione e gestire bug/richieste, ma abbiamo portato a termine moltissimo lavoro!

  • 6.13.0 ha finalmente introdotto le Preset Options.

  • 6.14.0 ha aggiunto un latest-preset che si mantiene aggiornato con la specifica JavaScript annuale.

  • 6.16.0 ha permesso di sostituire il parser o il code-generator.

  • Ad agosto, abbiamo rilasciato Babili, un minificatore basato su Babel.

  • A settembre, abbiamo rilasciato la prima versione di babel-preset-env (continua a leggere per i dettagli).

  • Dopo un anno su Phabricator, siamo tornati su GitHub issues grazie esclusivamente a @danez e al suo straordinario (e sottovalutato) lavoro.

Se utilizzi Babel, faccelo sapere con una PR nella nostra pagina degli utenti!

Ora babel-core viene scaricato oltre 5 milioni di volte al mese e quasi 60 milioni di volte in totale, ed è utilizzato in grandi aziende come Facebook/Netflix/Airbnb e altri progetti open source come React/Yarn.

Grazie a tutti per il continuo supporto! Vogliamo continuare a essere il fondamento della toolchain JavaScript: compilazione, linting, minificazione, codemod, code coverage, ecc.

Stato Attuale​

Se sei interessato a contribuire, consulta le issue linkate qui sotto!

Manutenzione dei plugin Babel per ogni proposta in TC39 a partire dallo Stage 0​

TC39 rappresenta Ecma International, Technical Committee 39: il comitato che sviluppa JavaScript.

Babel utilizza il concetto di stage di TC39 per categorizzare i suoi plugin sperimentali. Gli utenti dovrebbero poter utilizzare facilmente le funzionalità prima che siano pienamente implementate nei browser nello stage 4 del processo TC39.

Babel è fondamentale in questo processo grazie alla sua posizione nell'ecosistema: è significativamente più semplice per uno sviluppatore aggiornare un file .babelrc che modificare un flag del browser, e molto più rapido scrivere un plugin Babel che implementare nativamente la funzionalità nel browser. Questo è il cuore di Babel.

Ma il processo delle proposte comporta iterazioni significative: le proposte possono cambiare sintassi o essere abbandonate. Poiché TC39 si riunisce ogni 2 mesi, i plugin dovrebbero essere aggiornati almeno ad ogni cambiamento di stage per mantenere gli utenti sincronizzati.

Il feedback precoce al champion della proposta e al comitato è estremamente prezioso, sebbene si raccomandi cautela nell'uso delle funzionalità di Stage 0/1/2. Sebbene aziende come Facebook sfruttino queste funzionalità, hanno creato codemod per facilitarne la modifica.

Non ci sono abbastanza tempo e risorse per mantenere ogni plugin, specialmente quando ci sono aggiornamenti alle specifiche.

  • Alcune trasformazioni sono semplicemente obsolete, come i decoratori. Logan ha dovuto adattare la precedente specifica con babel-plugin-transform-decorators-legacy per Babel 6 e non abbiamo avuto risorse per riscriverla per la specifica aggiornata.

  • babel/babel#3473 - Async iteration proposal non è stato unito per così tanto tempo perché non abbiamo avuto tempo di revisionarlo. Quando è stato unito, era già passato dallo stage 2 allo stage 3.

Prossimamente lavoreremo con:

Problemi rilevanti:

Consulta thefeedbackloop.xyz per maggiori informazioni su TC39!

Manutenzione di altri plugin dell'ecosistema: JSX/Flow​

Babel è vitale per gli ecosistemi React e Flow, e collaboriamo strettamente con i team pertinenti di Facebook.

Etichette dei problemi rilevanti:

babel-preset-env ("autoprefixer" per Babel)​

La compilazione JavaScript è un bersaglio mobile: ci sono aggiornamenti annuali alle specifiche, i browser si aggiornano costantemente e gli utenti potrebbero abbandonare il supporto per browser precedenti. A prima vista, non sembra esserci un target fisso per la compilazione del nostro JavaScript.

La compat-table è costantemente aggiornata e viene utilizzata per questo preset.

È qui che entra in gioco babel-preset-env: un preset di Babel che determina automaticamente i plugin corretti da utilizzare in base agli ambienti specificati.

Il suo obiettivo è sia la semplicità d'uso che l'efficienza dell'output: devi solo preoccuparti dei tuoi ambienti target per sfruttare il codice nativo. Il preset decide per te i plugin necessari.

Alcuni esempi di configurazione​

Target Chrome 55 + ultime 2 versioni di altri browser tramite browserslist

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55,
        "browsers": ["last 2 versions"]
      }
    }]
  ]
}

Targeting della versione corrente di Node.js (usa process.versions.node)

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "node": "current"
      }
    }]
  ]
}

Chrome 55 useBuiltIns + webpack 2

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55
      },
      "modules": false,
      "useBuiltIns": true
    }]
  ]
}

In

JavaScript
import "babel-polyfill";

Out (dipende dall'ambiente)

JavaScript
import "core-js/modules/es7.string.pad-start";
import "core-js/modules/es7.string.pad-end";

Problemi rilevanti:

Linting tramite babel-eslint​

example of eslint

ESLint non supporta nuove funzionalità del linguaggio finché non raggiungono lo Stage 4 del processo di proposta. Per questo manteniamo babel-eslint (un parser ESLint personalizzato) che permette di effettuare linting su JavaScript con sintassi sperimentale.

Questo progetto è stato uno dei più complessi: essendo uno strato di compatibilità tra Babel e ESLint, richiede costanti aggiornamenti ad ogni modifica dei progetti sottostanti, con alto rischio di cambiamenti imprevisti dovuti al monkey-patching. È stato spiacevole riscontrare problemi come babel/babel-eslint#243 o babel/babel-eslint#267.

Per ridurre il carico di manutenzione, miriamo a migliorare l'interoperabilità di scope e traversal con ESLint. Sarebbe interessante poter scrivere regole ESLint usando le API di Babel o viceversa?

Problemi rilevanti:

Minificazione​

Babili è il nostro nuovo minificatore basato su Babel, che permette di produrre codice minificato mirando ai browser più recenti.

In

JavaScript
class Mangler {
  constructor(program) {
    this.program = program;
  }
}
new Mangler();

Out

JavaScript
// ES2015 code -> Babili -> Minified ES2015 Code
class a{constructor(b){this.program=b}}new a;

Maggiori informazioni nel blog post.

Essendo stato rilasciato di recente, cerchiamo nuovi contributori! Ci sono molti bug minori e miglioramenti possibili per chi cerca un progetto a cui contribuire.

Codemods / Refactoring / eslint --fix​

Un codemod è una modifica assistita da strumenti: un find-and-replace avanzato.

Se volessi cambiare merge({}) in Object.assign({}) (e forse successivamente in object rest), potresti usare una sostituzione regex. Ma non vorresti sostituire altri elementi chiamati merge come import/export, stringhe, commenti o variabili locali. Per operare in sicurezza serve uno strumento più potente che modifichi solo il codice specifico.

Sebbene Babel trasformi già codice in altro codice, come compilatore non considera lo stile del codice sorgente. Dopo un codemod con opzioni predefinite di Babel, git diff risulta disordinato.

Ecco Recast: uno strumento che preserva la formattazione del codice non modificato e allo stesso tempo formatta in modo elegante i nuovi nodi AST.

recast

Nello screenshot sopra, il riquadro in alto a sinistra è il codice di input e quello in basso a destra è il codice di output dopo l'esecuzione del plugin di Babel. In questo caso, preserva gli spazi bianchi del codice di input quando possibile.

Passando Recast nelle opzioni, Babel può alimentare il futuro delle trasformazioni di codice automatizzate.

.babelrc

JavaScript
{
  "parserOpts": {
    "parser": "recast"
  },
  "generatorOpts": {
    "generator": "recast"
  }
}

Esegui le trasformazioni di Babel pertinenti sul codice sorgente e sovrascrivilo:

Shell
babel src -d src

Questa funzionalità è stata appena resa possibile, quindi non vediamo l'ora di renderla più facile da usare e di vedere le trasformazioni che può abilitare. Consulta il post del blog 6.16.0 per maggiori informazioni!

Altri progetti correlati: JSCodeshift, js-codemod, Lebab.

Problemi rilevanti:

Copertura del codice / Strumentazione​

Vogliamo supportare strumenti come nyc e babel-plugin-istanbul.

Ecosistema di plugin​

Grazie alla nostra vivace community, nuovi plugin vengono creati costantemente: che si tratti di un nuovo modo per scrivere il tuo CSS in JSX o ricablare i test.

Attualmente esistono >1200 plugin Babel su npm.

Abbiamo avuto discussioni interessanti su come possiamo far crescere e supportare l'ecosistema di plugin. Potremmo provare a monitorare tutti i repository, ma è ovviamente troppo impegnativo.

Potrebbe essere interessante creare bot per automatizzare alcune attività: sviluppare plugin Babel specifici/regole ESLint per babel-plugin, scrivere codemod per aggiornare i cambiamenti delle API e integrare i plugin nei nostri test di verifica rapida.

  • Dovremmo creare una newsletter per i nuovi plugin utili?

  • Come possiamo insegnare alle persone cosa sono i plugin e come scriverli?

  • Come possiamo migliorare ASTExplorer?

Documentazione (questo sito!)​

I contributi alla documentazione sono stati decisamente scarsi nell'ultimo anno.

Tuttavia, proprio di recente abbiamo fatto molte cose fantastiche:

Abbiamo anche aggiunto nuovi collaboratori:

  • @STRML: Ha aggiunto Discourse a tutte le pagine GitHub tramite #875

  • @xtuc: Ha aggiunto il supporto per la lettura del README dal repository di Babel evitando la sincronizzazione di due copie della documentazione tramite #990

  • @fredericmarx: Ha aggiunto un pulsante di copia negli appunti per gli snippet di codice tramite #998

  • @seedofjoy: Ha aggiunto la funzionalità di ridimensionamento per il REPL tramite #1003

Alcune idee

  • Tutti i plugin dovrebbero includere esempi. È possibile incorporare RunKit o il REPL.

  • Aggiornare le FAQ con gli errori comuni

  • Documentazione API / migliorare il babel-handbook

Problemi rilevanti:

Il futuro​

NOTA: Tutto quanto segue può essere modificato o eliminato. Alcuni elementi potrebbero essere già in lavorazione, altri sono solo proposte che richiedono discussione e un promotore.

La priorità deve essere determinata dalle esigenze della community, non dalla desiderabilità marginale.

Modifiche all'API dei plugin​

C'è molta confusione sull'interazione tra plugin/preset riguardo all'ordinamento. Ciò causa bug e problemi di configurazione che costringono gli utenti a posizionare i plugin prima/dopo altri in modo non intuitivo.

Stiamo discutendo modifiche all'API che potrebbero ridurre questa confusione. Tuttavia, trattandosi di un cambiamento fondamentale al core di Babel, potrebbe richiedere tempo per individuare l'approccio migliore.

Versioning​

Dalla versione 6 di Babel utilizziamo un versioning "fisso" tramite Lerna. Questo ci consente di rilasciare contemporaneamente più pacchetti con la stessa versione (se il pacchetto cambia). È vantaggioso perché evita di impostare manualmente versioni separate per ogni pacchetto, mantenendo tutto sincronizzato. L'unico scenario problematico si verifica quando un pacchetto introduce breaking changes: in tal caso tutti i pacchetti incrementeranno la versione major.

Questo è spiegato più approfonditamente in babel/notes ma dobbiamo ancora definire il miglior piano d'azione per il progetto.

Cosa succede quando dobbiamo aggiornare una specifica da Stage 0 a Stage 1 e si tratta di una modifica breaking per il parser? Ci limitiamo ad aumentare la versione major, aspettiamo di raggruppare più modifiche o troviamo un modo per gestirlo tramite più versioni dei plugin?

Issue di discussione

Cambiare l'approccio ai preset Stage X​

Problemi rilevanti:

Velocità​

Le prestazioni sono una caratteristica fondamentale! A volte altri aspetti hanno priorità (bug fix, conformità alle specifiche, ecc.), ma rimangono comunque cruciali in diversi ambiti.

  • Come ridurre dimensioni/tempi d'installazione, specialmente per progetti multi-package? (yarn aiuta)

  • Come velocizzare il parsing?

  • Come creare plugin più veloci (e misurarne singolarmente le prestazioni)?

  • Come generare più rapidamente il codice trasformato?

  • Come generare codice che viene eseguito velocemente nel browser (https://fhinkel.github.io/six-speed/)?

Se riscontri problemi nell'output compilato, segnalali e chiedi aiuto per creare una PR!

Issue precedenti:

Possibile supporto per TypeScript?​

Babel potrebbe imparare a comprendere la sintassi TypeScript (come già fa per Flow)? Potremmo aggiungere un plugin per rimuovere i tipi TypeScript e migliorare l'interoperabilità.

Ciò richiederebbe di analizzare la sintassi specifica di TypeScript e rimuoverla. Tuttavia TypeScript include elementi sintattici non tipizzati, quindi per costrutti come enum dovremo discutere ulteriormente.

Sfruttare le informazioni sui tipi?​

Integrarsi con sistemi di tipi come Flow/TypeScript per ottimizzazioni. Significa che Babel potrebbe acquisire tramite questi strumenti la consapevolezza che un identificatore arr sia effettivamente un Array.

Esistono plugin che effettuano controllo dei tipi: babel-plugin-typecheck e babel-plugin-tcomb

Considerare un grafo delle dipendenze / operare su più file?​

Potremmo così integrarci meglio con strumenti come Webpack. Abiliterebbe trasformazioni cross-file o ottimizzazioni dell'intera codebase, utili per:

  • Minificazione (rimuovere proprietà verificandone l'uso nell'intera applicazione)

  • Segnalare errori per import/export mancanti o non validi

  • Issue di discussione

Errori del parser​

Messaggi d'errore più chiari, ispirati a Compiler Errors for Humans.

È evidente che tutti desideriamo errori utili!

Possiamo migliorare l'inferenza/indovinare l'intenzione dell'utente per evitare errori vaghi. Fateci sapere in quali casi succede!

Problemi rilevanti:

babel-init​

Sostanzialmente un modo per configurare Babel più facilmente, come fa create-react-app.

  • Configurare un .babelrc da zero, con prompt di domande

Possibile idea:

  • Chiedere sugli ambienti target (browser, node) e passarli a babel-preset-env

  • Chiedere sulle funzionalità sperimentali (aggiungere plugin specifici)

  • Aggiornare il pacchetto npm babel per fargli fare qualcosa di nuovo: renderlo il babel predefinito/opt-in/opinionato che era Babel 5. Può usare di default env e supportare latest 2 browsers (senza alcuna configurazione).

Problemi rilevanti:

Eseguire tc39/test262​

test262 verifica la conformità allo standard ECMAScript futuro in bozza mantenuto continuamente su tc39.github.io/ecma262, insieme a qualsiasi proposta TC39 allo Stage 3 o successivo. È mantenuto da Tom Care (@tcare) con contributi significativi di molti nella community ECMAScript.

Eseguire i test ufficiali delle specifiche contro Babel può garantire la nostra conformità o almeno farci sapere quando non lo siamo. Dovremo capire come filtrare elementi non compilabili (proxy, TCO, ecc.) e impostare un modo semplice per verificare i test falliti e segnalare issue e PR.

Problemi rilevanti:

Test di Smoke/Integrazione​

Sarebbe utile avere una sorta di Greenkeeper inverso o eseguire test con il branch master di Babel per individuare regressioni importanti prima di ogni rilascio (node ha il progetto citgm per questo). In teoria vorremmo prendere i più grandi progetti open source che usano Babel ed eseguire i loro test.

motiz88/babel-smoke-tests è un buon inizio! Sarebbe fantastico se esistesse già qualcosa di simile!

Analisi del Programma​

C'è stato un ottimo talk di Alan Shreve chiamato "Idealized Commit Logs: Code Simplification via Program Slicing" che ha ispirato @kentcdodds a provarlo in JavaScript via slice-js.

L'idea generale è che abbiamo molti strumenti per aiutarci a scrivere codice, ma pochi per aiutarci a comprendere/leggere il codice. Puoi pensare allo slicing del codice come a una forma mirata di eliminazione del codice morto.

slice-js

Un program slice elimina dal codice sorgente tutto ciò che non viene utilizzato per un caso di test eseguito. Se ci sono molte istruzioni if e loop non eseguiti durante il tuo caso d'uso, non appariranno nel program slice.

  • Strumento di ricerca semantico (consapevole dell'AST)?

Simile a graspjs, sarebbe interessante poter eseguire un trova-sostituisci usando un AST come input. Ci permetterebbe di creare altri strumenti di analisi: trovare tutte le IIFE nel codice, contare quante volte viene chiamato un metodo o persino quanti Class ci sono nella codebase.

babel --settings​

Questo comando stampa tutte le informazioni (anche in caso di errore). Include anche metriche sulle prestazioni relative alla durata di ogni plugin.

Unificazione del Parser​

Ci sono state discussioni sull'unificazione di parser/AST, in TheLarkInn/js-parser-discussions e precedentemente con ESTree.

Purtroppo con Babel 6 abbiamo "forkato" e abbiamo alcune differenze nel nostro AST rispetto a ESTree. Babel mira a supportare funzionalità allo stage x, mentre altri parser potrebbero supportare solo quelle allo stage 4. Priorità diverse possono riguardare conformità allo spec, prestazioni, funzionalità allo stage x, messaggi d'errore, estensibilità, rilasci, ecc. È però importante rimanere aperti a breaking change che migliorino l'interoperabilità e la comunità.

Interoperabilità con Sweet.js?​

Precedente issue. Forse possiamo semplicemente migliorare l'interoperabilità?

Supporto Node.js​

Dovremmo interrompere il supporto in base all'EOL delle versioni di Node.js? Quanto dovremmo aspettare in generale?

  • Vogliamo continuare a supportare gli utenti che non hanno ancora aggiornato?

  • Alcune trasformazioni/PR sono bloccate da questo, a causa di strumenti che hanno già abbandonato le versioni precedenti.

  • Molti altri progetti di build-time come ESLint lo hanno già fatto.

  • Faremo un major version solo per questo o pianificheremo altri cambiamenti aggiuntivi?

  • Discussione su Issue

Transizione da Babel 5 a 6 / Percorsi di aggiornamento​

Il passaggio a Babel 6 è stato complesso per la comunità. Il rilascio iniziale è stato un po' affrettato. Nonostante un post sul rilascio della 6.0, una guida all'installazione subito dopo, e persino uno strumento (ora deprecato) per la transizione, è rimasto difficile per gli utenti comprendere i cambiamenti.

Ci sono ancora un numero significativo di utenti su Babel 5 che non vogliamo lasciare indietro. Cosa possiamo fare per aiutarli a migrare? Quali passi dobbiamo intraprendere in futuro per evitare che accada lo stesso con Babel 7? Ci sono altri progetti/comunità con cui dovremmo entrare in contatto e offrire supporto?

Problemi rilevanti:

Che altro?​

Qualsiasi altro aspetto non già menzionato qui? Scrivici un tweet @babeljs, un messaggio sul nostro Slack (registrati su https://slack.babeljs.io/, commenta questo post o crea una issue di discussione nella nostra repository!

Ci sono progetti o comunità con cui dovremmo collaborare maggiormente? Come possiamo rendere l'esperienza di contribuzione più accogliente? Cosa possiamo fare per rendere il processo di sviluppo più trasparente?

Comunità​

Problemi storici:

Potreste pensare che quando un progetto viene adottato su larga scala più persone si offrano di aiutare. Ma come molti progetti OSS non supportati da aziende, ci sono costanti problemi di manutenzione e sostenibilità: le persone si esauriscono, passano ad altri progetti interessanti o sono occupate con lavoro/famiglia/ecc.

Come James descrive in Dear JavaScript, l'attuale team di Babel è piuttosto ridotto.

Babel non è un'azienda, un team speciale di Facebook o un progetto OSS finanziato da società. È uno sforzo guidato dalla comunità attualmente sostenuto da poche persone e vogliamo che questo numero cresca.

Quindi se sei interessato a contribuire a uno strumento che utilizzi, speriamo che questo possa essere quello giusto!

Su quali problemi dovrei concentrarmi o contribuire?​

Molti dei nostri progetti hanno etichette beginner-friendly e help-wanted. Puoi anche consultare discussion.

Team​

Il nostro core team è:

E solo negli ultimi 3 mesi molti altri collaboratori:

Team principale di Babili:

Come accennato sopra, abbiamo molti collaboratori per il sito web:

Inattivi ma comunque una risorsa:

Come posso contattare il team?​

GitHub​

Per segnalazioni di bug o PR, consulta le nostre repository.

Twitter​

Puoi contattarci su Twitter con @babeljs - o menzionarci individualmente.

Io stesso ho creato un account su Twitter per interagire con gli utenti e offrire supporto. Pubblicare nuove funzionalità e changelog è molto utile per ricevere feedback!

Slack​

Abbiamo una comunità piuttosto attiva su Slack!

Troverai molti membri della comunità disponibili ad aiutare, come Jordan Harband, @ljharb, Jessica Franco, @Jessidhia, Jimmy Jia, @taion, Denis Pushkarev, @zloirock e altri!

Se hai domande entra in #discussion, mentre per contribuire o seguire i lavori visita #development.

Cerchiamo di evitare discussioni private quando non necessario: io stesso pubblico solitamente le issue/PR su cui sto lavorando per revisioni e discussioni.

Altro​

In quali altri modi possiamo interagire con la comunità? Dovremmo organizzare meetup, partecipare a conferenze o gestire hackathon?

Come possiamo rendere Babel sostenibile? Dovremmo configurare un Open Collective o cercare una fondazione? Dovremmo pagare un project manager?

Fateci sapere cosa ne pensate! Cosa vi aspettate da Babel?

Vedi errori di battitura o problemi? Invia una PR o commenta su babel/babel.github.io#1014

Se c'è una cosa che vogliamo comunicarvi, è che molti di noi hanno iniziato con Babel proprio per imparare JavaScript, non per contribuire perché già lo conoscevamo. Personalmente, non sapevo nulla dei compilatori e avevo appena scoperto cosa fosse ES6 quando mi sono imbattuto nel progetto. Sono arrivato qui grazie a un pizzico di curiosità e all'incoraggiamento di molte persone. Voglio portare avanti questo spirito e sperare che possiamo riuscirci tutti insieme.

Grazie mille per la lettura!

Henry Zhu (@hzoo) (@left_pad)

Un ringraziamento speciale a tantissime persone per revisioni e contributi: @DrewML, @mrjoelkemp, @kentcdodds, @existentialism, @jdalton, @gaearon, @nolanlawson, @jayphelps, @montogeek, @TheLarkInn, @jasonLaster, @benjamn, @addyosmani, @Daniel15, @loganfsmyth, @gr2m, @mathiasbynens, @chicoxyzzy, @bvaughn, @bcoe.