Fermer

mai 30, 2018

Comprendre la gestion des versions de JavaScript –


Comme les langages de programmation disparaissent, le développement de JavaScript a été positivement frénétique au cours des dernières années. Chaque année, en voyant une nouvelle version de la spécification ECMAScript, il est facile de se tromper sur le versioning de JavaScript, quelle version supporte quoi, et comment vous pouvez mettre votre code à l'épreuve du futur.

Pour mieux comprendre le pourquoi et le comment flux constant de nouvelles fonctionnalités, jetons un coup d'œil sur l'historique des versions JavaScript et JavaScript, et découvrons pourquoi le processus de standardisation est si important.

L'historique des versions de JavaScript

Le prototype de JavaScript a été écrit en dix jours seulement en mai 1995 par Brendan Eich. Il a d'abord été recruté pour implémenter un runtime de schéma pour Netscape Navigator, mais l'équipe de gestion a poussé pour un langage de type C qui compléterait le Java récemment publié.

JavaScript a fait ses débuts dans la version 2 de Netscape Navigator en décembre 1995. L'année suivante, Microsoft a procédé à une ingénierie inverse de JavaScript pour créer sa propre version, l'appelant JScript. JScript était livré avec la version 3 du navigateur Internet Explorer, et était presque identique à JavaScript – y compris tous les mêmes bugs et bizarreries – mais il avait quelques fonctionnalités Internet Explorer supplémentaires.

The Birth of ECMAScript

nécessité de s'assurer que JScript (et toutes les autres variantes) reste compatible avec Netscape et Sun Microsystems motivés par JavaScript pour standardiser la langue. Ils l'ont fait avec l'aide de la European Computer Manufacturers Association qui serait l'hôte de la norme. Le langage standardisé s'appelait ECMAScript pour éviter d'enfreindre la marque Java de Sun – une décision qui a causé beaucoup de confusion. Finalement, ECMAScript a été utilisé pour se référer à la spécification, et JavaScript était (et est toujours) utilisé pour faire référence au langage lui-même.

Le groupe de travail chargé du JavaScript versioning et de la maintenance d'ECMAScript s'appelle Technical Committee 39 ou TC39. Il est composé de représentants de tous les grands fournisseurs de navigateurs tels qu'Apple, Google, Microsoft et Mozilla, ainsi que d'experts invités et de délégués d'autres sociétés intéressées par le développement du Web. Ils ont des réunions régulières pour décider comment la langue va se développer.

Lorsque JavaScript a été normalisé par le TC39 en 1997, la spécification était connue comme ECMAScript version 1. Les versions subséquentes d'ECMAScript étaient initialement publiées sur une base annuelle, mais devenaient sporadiques. en raison de l'absence de consensus et de l'encombrement incommensurable d'ECMAScript 4. Cette version a donc été arrêtée et réduite en 3.1, mais n'a pas été finalisée sous ce nom, pour finalement évoluer vers ECMAScript 5. Cette version a été publiée en décembre 2009, 10 années après ECMAScript 3, et introduit une API de sérialisation JSON Function.prototype.bind et mode strict entre autres capacités. Une version de maintenance pour clarifier une partie de l'ambiguïté de la dernière itération, 5.1, a été publiée deux ans plus tard


Voulez-vous plonger plus profondément dans l'histoire de JavaScript? Ensuite, jetez un coup d'œil au premier chapitre de JavaScript: Novice à Ninja, 2e édition


ECMAScript 2015 et la résurgence des rejets annuels

Avec la résolution du désaccord du TC39 résultant de l'ECMAScript 4, Brendan Eich souligne la besoin de versions plus petites et à plus court terme. La première de ces nouvelles spécifications était ES2015 (à l'origine nommée ECMAScript 6, ou ES6). Cette édition était une base importante mais nécessaire pour soutenir le futur, versioning JavaScript annuel. Il comprend de nombreuses fonctionnalités qui sont aujourd'hui appréciées par de nombreux développeurs, telles que:

ES2015 a été la première offre à suivre le processus TC39 un modèle basé sur des propositions pour discuter et adopter des éléments. ] Le processus TC39

Il y a cinq étapes à travers lesquelles une proposition doit passer avant qu'elle puisse être acceptée dans une prochaine version d'ECMAScript.

Étape 0: Strawman

Ceci est une étape de commodité pour permettre la soumission d'idées à la spécification. Les caractéristiques peuvent être suggérées par n'importe qui – à savoir les membres du TC39 et les non-membres qui se sont inscrits comme contributeurs.

Étape 1: Proposition

La première étape à laquelle une proposition est formalisée. Il est nécessaire que:

  • les problèmes existants rectifiés par la solution soient décrits
  • un aperçu de l'API est fourni, ainsi que des détails d'implémentation de haut niveau, ainsi que des problèmes potentiels et / ou démos
  • . 19659025] Un champion doit être choisi pour adopter et faire avancer la proposition. Cet individu doit être un membre TC39

    Étape 2: Ébauche

    Il s'agit du jalon auquel une fonctionnalité est susceptible d'être incluse dans une future version d'ECMAScript. Ici, la syntaxe et la sémantique de la proposition sont détaillées en utilisant le langage formel décrit par la spécification. Une implémentation expérimentale devrait être disponible à ce stade

    Étape 3: Candidat

    Ici, la majorité de la proposition et de la technologie de support ont été développées, mais elle nécessite d'autres commentaires des utilisateurs et des implémenteurs (tels que les vendeurs de navigateurs) . Une fois que cela est disponible et pris en compte, les détails et les spécifications sont finalisés et signés par les réviseurs désignés et l'éditeur désigné. Comme une implémentation conforme est requise à ce stade, seuls les changements critiques sont désormais adoptés

    Etape 4: Terminé

    La proposition a été acceptée et peut être ajoutée à ECMAScript. Il est donc inhérent que:

    • des tests d'acceptation, qui font partie de Test262 suite et qui sont construits avec JavaScript, ont été écrits pour prouver la conformité et le comportement de la caractéristique
    • deux implémentations conformes sont disponibles et ont été expédiées, ce qui démontre la robustesse et la facilité d'utilisation du développeur
    • une demande d'extraction a été soumise au rapport officiel ECMA-262 qui a été signé par l'éditeur de spécifications

    Le document de contribution du dépôt ci-dessus détaille davantage l'utilisation des questions GitHub et tire des demandes pour gérer les ajouts à la langue

    Moving Forward

    Après l'achèvement d'ES2015 et l'établissement du TC39 processus de version et de mise à jour de JavaScript, les versions ultérieures ont eu lieu chaque Juin, avec l'inclusion des propositions étant timeboxed à un an. Au moment de la rédaction, il y avait trois nouvelles spécifications

    ES2016

    Également connu sous le nom de ES7, il s'agissait de la première version incrémentielle plus petite d'ECMAScript. Mis à part les corrections de bugs, il n'a ajouté que deux fonctionnalités:

    Array.prototype.includes

    Cette méthode d'instance simplifie la recherche de valeurs dans un Array :

     // pre-ES2016:
    const hasBob = noms.indexOf ('bob')> -1;
    
    // ES2016:
    const hasBob = names.includes ('bob');
    

    Exponent Operator

    Avant ES2016, on pouvait effectuer une exponentiation avec Math.pow (base, exposant) . Cette version introduit un opérateur (**) qui a sa propre priorité:

     // pré-ES2016
    Math.pow (5, 3); // => 125
    
    // ES2016
    5 ** 3; // => 125
    

    ES2017

    Une version légèrement plus grande, ES2017 (alias ES8) contient une poignée de méthodes utiles et de constructions syntaxiques

    Fonctions asynchrones

    Les promesses nous ont sauvés du callback hell, mais leur API démontre néanmoins la verbosité. Les fonctions asynchrones les résument avec une syntaxe qui ressemble beaucoup au code synchrone:

     // promesses
    const getProfile = nom => {
      return fetch (`https: // certains-api / gens / $ {nom}`)
        .then (res => res.json ())
        .then (({profile}) => profil); // déstructuration `profile` de l'objet analysé
    }
    
    // async / wait
    const getProfile = nom asynchrone => {
      const res = wait fetch (`https: // certains-api / gens / $ {nom}`);
      const {profile} = attendre res.json ();
      retour profil;
    }
    

    Méthodes de remplissage de chaînes

    String.prototype.padStart (longueur, padder) et padEnd (longueur, padder) respectivement préfixent et ajoutent padder (ceci est facultatif, par défaut à un espace) à une chaîne à plusieurs reprises jusqu'à ce qu'il atteigne longueur caractères:

     'foo'.padStart (6); // => 'foo';
    'foo'.padEnd (6); // => 'foo';
    'foo'.padStart (10,' bar '); // => 'barbarbfoo';
    'foo'.padEnd (10,' barre '); // => 'foobarbarb';
    

    Autres caractéristiques: virgule flottante mémoire partagée et atomique et statique Object méthodes ( Object.entries () Object.values ​​() et Object.getOwnPropertyDescriptors () .)

    Si vous souhaitez en savoir plus sur l'ensemble des fonctionnalités complètes de ES2017, consultez notre article sur Quoi de neuf dans ES2017

    ES2018

    Cette dernière itération, à l'heure de l'écriture, introduit un petit ensemble d'ajouts puissants

    Iterators asynchrones

    While Promise.all () vous permet d'attendre la résolution de plusieurs promesses. Dans certains cas, vous devrez peut-être effectuer une itération séquentielle sur des valeurs récupérées de manière asynchrone. Il est maintenant possible d'attendre des itérateurs asynchrones avec des tableaux de promesses:

     (async () => {
      const personRequests = ['bob', 'sarah', 'laura'] .map (
        n => fetch (`https: // api / people / $ {n}`)
      )
    
      pour await (const response de personRequests) {
        console.log (attendez response.json ());
      }
    }) ();
    

    Propriétés de la propagation et du repos de l'objet

    Apparemment, ces deux améliorations syntaxiques sont déjà populaires parmi les développeurs JavaScript grâce à la disponibilité de compilateurs tels que Babel . Les propriétés de propagation et de repos des objets sont similaires aux propriétés de propagation et de repos des tableaux et permettent la copie superficielle et la déstructuration groupée des propriétés d'objet:

     const react = {
      nom: 'Réagir',
      vendeur: 'Facebook',
      description: 'Une bibliothèque JavaScript pour créer des interfaces utilisateur',
      npm: vrai,
      cdn: vrai,
    }
    
    / * Utiliser la syntaxe de propagation dans un littéral d'objet pour créer
     * une copie superficielle, tout en remplaçant certaines propriétés.
     * /
    const vue = {
      ...réagir,
      vendeur: 'Evan You',
      description: 'Un framework JavaScript pour construire des interfaces utilisateur',
    }
    
    / * Utilisez le repos dans la syntaxe de déstructuration pour créer un
     * label pour accéder aux propriétés d'objet supplémentaires.
     * /
    const {nom, vendeur, ... reste} = vue;
    console.log (rest.description); // => 'Un framework JavaScript pour créer des interfaces utilisateur'
    

    Les autres propositions acceptées sont Promise.prototype.finally () ainsi que les améliorations apportées aux expressions régulières et aux littéraux de gabarit . Pour en savoir plus sur l'ensemble des fonctionnalités de l'ES2018, veuillez consulter notre article sur Quoi de neuf dans ES2018

    Un dernier mot

    JavaScript a beaucoup évolué en peu de temps. Bien que cela soit attribuable au standard ECMAScript et au brillant travail de TC39, il s'agissait au départ d'un parcours ardu en raison du manque de stabilité et de cohésion dans la gestion des versions et le développement de JavaScript

    . seulement améliorer de manière pragmatique et gérable. C'est un bon moment pour devenir développeur web!




Source link