Découvrez les principales caractéristiques ES2017

Quelles sont les principales caractéristiques de ES2017 et ce qui est sur la liste pour ES2018? Cette série en deux parties explore les dernières fonctionnalités d'ECMAScript. La partie 1 explore des fonctions majeures telles que les fonctions asynchrones et la mémoire partagée et les atomes, tandis que Part 2 explore des caractéristiques mineures.

Vérifions avec ECMA International, Comité technique 39 ! Il se trouve que le 6 dans ES6 ne représente pas le nombre d'années qu'il faut pour une version. Je blague! Comme ES6 / ES2015 a pris tellement de temps à sortir (6 ans, d'où mon jab), le comité a décidé de passer à une version annuelle en petits lots. Je suis un grand fan de cela et je pense que l'élan continue à bouger et à améliorer JavaScript. Quels cadeaux avons-nous obtenu pour ES2017 et ce qui est sur notre liste pour ES2018?

Vous pouvez en apprendre plus sur le processus TC39 des propositions de 2ality par Dr. Axel Rauschmayer : Le processus TC39 pour les fonctions ECMAScript .

ES2017

En janvier, lors de la réunion du TC39, le groupe s'est arrêté sur les propositions ECMAScript qui seraient les caractéristiques d'ES2017 (également renvoyé à ES8, qui devrait probablement être supprimé pour éviter toute confusion). Cette liste comprenait:

Principales caractéristiques

Caractéristiques mineures

Dans ce post, le premier d'une série en deux parties, nous allons couvrir les principales caractéristiques énumérées ci-dessus. Vous pouvez lire le deuxième post pour couvrir les caractéristiques mineures

Fonctions asynchrones

Fonctions asynchrones sur GitHub (Proposé par Brian Terlson)

Je commence ici parce qu'il était premier sur la liste et mon niveau d'excitation est assez élevé pour cette addition chouette. En ES2015, nous avons promis pour nous aider avec la condition trop familière communément appelée … (allez-vous vraiment me le faire dire?) CALLBACK HELL ?.

Le async ] / await lit une syntaxe entièrement synchrone et s'inspire de TJ Holowaychuk Co . Comme un aperçu rapide, async et attendent des mots-clés vous permettent de les utiliser et essayez / catch blocs pour que les fonctions se comportent de manière asynchrone. Ils fonctionnent comme des générateurs mais ne sont pas traduits en fonctions génératrices. Voici à quoi cela ressemble:

 // Old Promise Town
Fonction fetchThePuppies (chiot) {
  retour chercher (chiot)
  .then (chiotInfo => chiotInfo.text ())
  .then (texte => {
    return JSON.parse (texte)
  })
  .catch (err =>
    console.log (`Erreur: $ {err.message}`)
  )
}

// Nouvelle Async / Await City
async function fetchThePuppies (chiot) {
  essayez {
    Laissez chiotInfo = attendez fetch (chiot)
    let text = attendez chiotInfo.text ()
    return JSON.parse (texte)
  }
  catch (err) {
    console.log (`Erreur: $ {err.message}`)
  }
} 

Cela ne signifie pas que vous devriez entrer et remplacer toutes les promesses dans votre code avec async / attendre . Tout comme vous ne l'avez pas fait et remplacez toutes les fonctions de votre code par des fonctions de flèches (on espère), utilisez uniquement cette syntaxe là où elle fonctionne le mieux. Je n'entrerai pas trop dans les détails ici parce que là sont tonnes de articles couvrant async / attendent . Vérifiez-les (oui, j'ai ajouté un lien d'un async / attendez blog pour chacun de ces derniers mots dans la phrase précédente, je vous en prie ?). Dans l'année à venir, nous verrons comment les gens peuvent rendre leur code plus lisible et efficace en utilisant async / await .

Mémoire partagée et atomique

Mémoire partagée et atomique sur GitHub (Proposé par Lars T. Hansen)

Attendez, est-ce que nous sommes entrés dans un cours de physique théorique? Cela semble amusant, mais non. Cette proposition ECMAScript rejoint la ligne ES2017 et introduit SharedArrayBuffer et un objet d'espace de noms Atomics avec des fonctions auxiliaires. Super haut niveau (jeu de mots), cette proposition est notre prochaine étape vers le parallélisme de haut niveau en JavaScript .

Nous utilisons JavaScript pour de plus en plus d'opérations dans le navigateur en utilisant Just-in -Time compilateurs et CPU rapides. Malheureusement, comme le dit Lars T. Hansen dans son article génial, Un goût des nouvelles primitives parallèles de JavaScript à partir de mai 2016:

Mais les JIT JS s'améliorent maintenant plus lentement et l'amélioration des performances du processeur est en panne. Au lieu de processeurs plus rapides, tous les appareils grand public – des ordinateurs de bureau aux smartphones – ont maintenant plusieurs processeurs (en réalité des cœurs de processeurs) et, sauf au bas de l'échelle, ils en ont généralement plus de deux. Un programmeur qui veut de meilleures performances pour son programme doit commencer à utiliser plusieurs cœurs en parallèle. Ce n'est pas un problème pour les applications "natives", qui sont toutes écrites dans des langages de programmation multithread (Java, Swift, C # et C ++), mais c'est un problème pour JS, qui a des possibilités très limitées pour fonctionner sur plusieurs processeurs (travailleurs Web, transmission lente de messages et peu de moyens d'éviter la copie de données)

SharedArrayBuffer

Cette proposition nous fournit les blocs de construction pour le calcul multicœur afin de rechercher différentes approches pour implémenter des constructions parallèles de plus haut niveau en JavaScript . Quels pourraient être ces blocs de construction? Puis-je vous présenter à SharedArrayBuffer . MDN a une grande définition succincte donc je vais juste le faire ici:

L'objet SharedArrayBuffer est utilisé pour représenter un tampon de données binaire brut, de longueur fixe, similaire à l'objet ArrayBuffer mais de manière à pouvoir être utilisé pour créer des vues sur la mémoire partagée. Contrairement à un ArrayBuffer un SharedArrayBuffer ne peut pas se détacher.

Je ne sais pas pour vous mais la première fois que j'ai lu que j'étais "wat."

Fondamentalement, l'une des premières façons dont nous avons pu exécuter des tâches en parallèle était avec les travailleurs Web. Puisque les travailleurs ont couru dans leur propre environnement global, ils ont été incapables de partager, par défaut, jusqu'à ce que la communication entre les travailleurs, ou entre les travailleurs et le fil principal, ait évolué. L'objet SharedArrayBuffer vous permet de partager des octets de données entre plusieurs travailleurs et le thread principal. De plus, contrairement à son prédécesseur ArrayBuffer la mémoire représentée par SharedArrayBuffer peut être référencée simultanément à partir de plusieurs agents (c'est-à-dire des web workers ou le programme principal de la page web). Vous pouvez le faire en utilisant postMessage pour transférer le SharedArrayBuffer d'un de ces agents à l'autre. Mettez tout ensemble, et qu'est-ce que vous avez? Transfert de données entre plusieurs travailleurs et le thread principal en utilisant SharedArrayBuffer afin que vous puissiez exécuter plusieurs tâches à la fois, ce qui == parallélisme en JavaScript. Mais attendez, il y en a plus!

Mise à jour SharedArrayBuffer

Avant de passer à autre chose, il est important de noter quelques retards actuels pour SharedArrayBuffer . Si vous avez prêté attention aux nouvelles ces derniers temps, vous pouvez être conscient de la faille de conception de la puce de processeur de processeur causant deux vulnérabilités: Meltdown et Spectre . N'hésitez pas à lire dessus mais sachez que les navigateurs désactivent SharedArrayBuffer jusqu'à ce que ce problème soit résolu.

SharedArrayBuffer est désactivé car vous pouvez mettre à jour ses valeurs dans un worker, dans une boucle serrée. Puis, à partir d'un autre thread, ces données peuvent être utilisées comme une minuterie à haute résolution.

Il reviendra une fois que les problèmes de processeur sous-jacents auront été corrigés.

– Jake Archibald (@jaffathecake) 4 janvier 2018

Atomique

Bon, l'arrêt suivant sur ce train parallèle: Atomics qui est une variable globale qui a deux méthodes. Tout d'abord, permettez-moi de vous présenter le problème résolu par les méthodes Atomics . Lors du partage d'un SharedArrayBuffer betwixt ? agents (pour rappel, les agents sont les web workers ou le programme principal de la page Web), chacun de ces agents peut lire et écrire dans sa mémoire à tout moment. Alors, comment gardez-vous cela sain et organisé, en s'assurant que chaque agent sait attendre qu'un autre agent finisse d'écrire ses données?

Atomics méthodes wake et load ! Les agents vont "dormir" dans la file d'attente en attendant qu'un autre agent finisse d'écrire leurs données, donc Atomics.wake est une méthode qui leur permet de se réveiller. Lorsque vous avez besoin de lire les données que vous utilisez Atomics.load pour charger des données à partir d'un certain emplacement. L'emplacement est basé sur les méthodes deux paramètres: un TypedArray un mécanisme semblable à un tableau pour accéder aux données binaires brutes (ce que SharedArrayBuffer utilise), et un index pour trouver la position dans que TypedArray . Il y a plus que ce que nous venons de couvrir mais c'est l'essentiel.

Pour l'instant, Atomics n'a que ces deux méthodes. Finalement, Hansen (notre adorable auteur de cette proposition et explicateur de choses parallèles) dit, il devrait y avoir plus de méthodes, comme store et compareExchange pour vraiment mettre en œuvre la synchronisation. Encore une fois, nous sommes aux premières étapes du parallélisme en JavaScript et cette proposition nous fournit les éléments de base pour y arriver.

Ouf! Même si c'était beaucoup à penser, c'était toujours un aperçu de haut niveau. Cette mise à jour ne sera peut-être pas utilisée par la plupart des développeurs l'année prochaine mais contribuera à faire progresser JavaScript pour le bénéfice de tous. Alors, remerciez votre cerveau de vous avoir plongé aussi loin et découvrez ces ressources fantastiques pour y plonger!