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'objetArrayBuffer
mais de manière à pouvoir être utilisé pour créer des vues sur la mémoire partagée. Contrairement à unArrayBuffer
unSharedArrayBuffer
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!
Les commentaires sont désactivés en mode prévisualisation.
[ad_2]
Source link