Logo JavaScript

Améliorations du support de ES6

Flattr this!

Je me suis livré à un petit exercice, j'ai fait le diff entre la semaine dernière et cette semaine sur la table de compatibilité ES6 de Kangax.

Bon alors pour les incultes (sans méchanceté), la table de Kangax, c'est toutes les fonctionnalités apportées par ES6 passées au crible sous chaque moteur JS, navigateur et autres pour voir si elles sont supportées. Soit ça : https://kangax.github.io/compat-table/es6/

Je voulais voir si il y avait eu du progrès et quelles étaient les nouveautés. Et il y en a un peu. Seule l'équipe de Webkit a vraiment fourni de la progression cette semaine. On a donc au menu :

  • Meilleur support de destructuring pour Webkit (+1 point sur 32, soit 26/32)

L'opérateur Spread est désormais complètement supporté dans le destructuring. Du coup on peut faire ça :

var [a, ...b] = [3, 4, 5];

// a===3
// b instanceof Array
// b == [4,5]

var [c, ...d] = [6];

// c === 6
// d instanceof Array
// d.length = 0

 

 

  • Meilleur support des arrow functions pour Webkit (+2 sur 11, soit 3/11). Ca supporte les paramètres maintenant. N'était supporté jusqu'à maintenant que celles sans paramètres.
  • Support de WeakMap[symbol.species] pour Webkit, Chrome, io.js (+1 sur 10, soit 10/10 pour Webkit et 9/10 pour le reste). Les Symbol.species sont expliqués ici sur la MDN, très bonne référence comme d'habitude. On parle ici juste de l'utilisation des Symbol.species comme clé dans une WeakMap.

Je suis assez content que le destructuring progresse, j'avouerai qu'à mon sens c'est le progrès le plus intéressant de ES6.

Les WeakMap etc aussi sont intéressantes mais pouvaient être simulées en ES5 (pas à 100% mais sur une partie substantielle des concepts).

Par contre, les "arrows functions", c'est juste de la branlette pour faire revenir les mecs qui s'étaient barrés pour CoffeeScript. Si ça les amuse, tant mieux, j'ai banni cette merde immonde de mon environnement en l'interdisant dans ESlint. En quoi est-ce plus rapide à coder ? -> Installe toi un vrai IDE, vire ton Notepad++. Ou plus lisible ? Tu dois être fan d'art très abstrait, mon pauvre, quel monde cruel. Pour ceux qui avancent le this relié à la fonction mère... Allez, fais un effort, mets ton this en cache dans une variable et paf, ça fait des choca... le même boulot, mais en plus clair.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) . Vous pouvez la mettre en favoris avec ce permalien.
  • http://putaindecode.fr/ Nyalab

    « Par contre, les « arrows functions », c’est juste de la branlette pour faire revenir les mecs qui s’étaient barrés pour CoffeeScript »
    lol, résoudre un problème de binding lexical avec une feature native du langage, on appelle pas ça de la branlette nan.
    puis niveau code concis avec l’absence de parenthèses si tu n’as qu’un arguments et le return implicite si tu n’as qu’un statement, niveau clarté du code, c’est encore un argument en faveur…

    • http://www.mathieurobin.com/ Mathieu ROBIN

      Pas tout à fait d’accord. Oui c’est plus « simple ». Mais ça veut dire une deuxième façon de déclarer une fonction. Que les gens peuvent choisir en fonction du nombre d’arguments. C’est comme ça que ça va finir, se résumer.
      Rien que pour une question de cohérence dans le temps sur la tronche du code, c’est pas viable. Avec toujours le manque de maîtrise par les moins expérimentés de « bordel, il vaut quoi this ». Ça va continuer d’être le bordel dans leurs têtes alors même que le travail d’évangélisation pour faire comprendre la base même de la portée des variables n’est pas terminé.
      On est d’accord que ce problème de binding nécessitait une solution. Mais elle n’est clairement pas la bonne.
      Après ce n’est que mon point de vue.

      • http://moox.io/ MoOx (Maxime Thirouin)

        > Après ce n’est que mon point de vue.

        Apparement tu dois faire partie du petit village es3 au fond à droite, qui ne veut pas évoluer vu le nombre les gens heureux d’utiliser cette nouvelle feature dès que c’est pertinent :)

        • http://www.mathieurobin.com/ Mathieu ROBIN

          Je suis d’accord pour évoluer, mais quand c’est fait de façon pertinente. Et en apprentissage des erreurs du passé. Ce qu’on ne fait pas là, à mon avis

      • http://bloodyowl.github.io/ bloodyowl

        c’est pour ça qu’il faut enseigner le scope et le context très vite. et justement, avoir une syntaxe différente permet de gommer la confusion. c’est comme si tu disais `let` et `const` c’est de la merde parce que mes élèves savent déjà pas piger qu’une variable c’est scopé à la fonction parente.

        • http://www.mathieurobin.com/ Mathieu ROBIN

          Ouais mais là on remplace pas, on complète. Tu peux coder entièrement sans var en utilisant exclusivement let et const. Si tu fais pareil avec les fonctions fléchées, je vois surtout un bordel infernal venir. Après peut-être que je me trompe.

          • http://bloodyowl.github.io/ bloodyowl

            tu complètes aussi. c’est une autre forme de fonction avec des propriété qui lui sont particulières.

          • http://www.mathieurobin.com/ Mathieu ROBIN

            Je ne peux pas contester ton approche. Ceci dit la symbolique me rebute et ne me semble définitivement pas adaptée. Ceci dit, là où je suis à 100% d’accord avec toi, c’est que l’enseignement du scope et du contexte sont une priorité en permanence.

          • Armaklan

            Pour moi, l’arrow function sert à une écriture « lambda style », notamment dans l’utilisation des fonctions de transformation de listes. Les lambda, ce n’est pas spécifique à Javascript, ça apparaît sur un peu toutes les technologies ^^

            Exemple, j’ai une liste de personne et je veut le nom des personnes adultes :

            personnes
            .filter((p) => p.isAdult())
            .map((p) => p.name);

            ça donne une écriture qui est bien plus courte et lisible que son équivalent ancienne verison :

            personnes
            .filter(function(p) {
            return p.isAdult();
            })
            .map(function(p) {
            return p.name;
            });

          • http://www.mathieurobin.com/ Mathieu ROBIN

            Soyons honnêtes ? J’ai vomi.

            Si tu veux aller à fond dans la logique objet. Tu utilises une classe pour gérer un ensemble de personnes. Du coup, tu aurais fait :

            personnes
            .getAdults()
            .getNamesList()

            Peu importe ce que font les fonctions. Après je suis peut-être un peu extrémiste mais comme ça ton code est testable.

          • Armaklan

             » J’ai vomi  »

            Et hop, bel exemple de dévalorisation par l’image. J’aime ce genre d’introduction à une réponse.

            « Si tu veut aller à fond de la logique objet »

            Trop de classe, tue les classes. Parfois il faut savoir sacrifier un peu la théorie au profit d’une écriture plus courte et efficace.

            Amha, tu fait souvent des classes qui contiennent uniquement une collection d’objet ? ça m’ai arrivé de temps à autre, mais ça alourdi tout de même pas mal pour souvent pas grand chose.

            Ma méthode unitaire (p.isAdult) qui contient la règle métier est testable. Ma fonction finale sera aisément testable au dessus. Je ne voit pas l’intérêt de rajouter une classe supplémentaire pour de la testabilité en plus. S’il y a réutilisation de cette fonction ailleurs, ok pas de soucis, mais sinon « bof ».

            Bref, je pense que l’on rentre ici dans un débat proche du style de programmation, donc on ne trouvera de toutes manières pas de consensus.

          • http://www.mathieurobin.com/ Mathieu ROBIN

            Désolé pour l’image mais elle me semblait pertinente même si clairement pas du tout classieuse. Et pour le reste, oui, tu as raison, là on rentre littéralement dans un débat philosophique sur le style de programmation. Je préfère le style ultra verbeux plutôt que des petits raccourcis certes pratique mais tellement pas verbeux. Pas de consensus possible en effet…

  • http://about.me/amorgaut Alexandre Morgaut

    J’étais contre les fat arrow jusqu’à les avoir vu utilisés proprement dans un code clair non pollué par un hack de binding explicite du this.

    Maintenant, je reste très réservé. L’idéal serait de réserver son usage pour des fonctions tenant sur une ligne, idéalement sur une expression.

    4 points m’ont particulièrement gênés:
    – une nouvelle syntaxe est moins intuitive à apprendre qu’une nouvelle API correctement nommée
    – une nouvelle syntaxe nécessite une transpilation pour les ancien moteur, un simple polyfil ne suffit pas
    – cette syntaxe encourage plus à ne pas donner de nom au fonctions expressions ce qui peut être contre-productif, génant en debug, en optimisation de perf et en maintenance (cf http://www.quora.com/What-is-an-anonymous-function-in-JavaScript/answer/Alexandre-Morgaut )
    – le binding de this n’est pas clair dans certain cas, comme dans le cas du array.forEach(cb, context)

    Le 3ème point est heureusement atténué par le fait que ES6 intègre un nommage interne automatique des fonctions dans certains cas. Mais il ne prévoit rien pour les fonctions créé directement en paramètre pour callback comme pour array.map( a => foo(a))
    Si cet exemple est peu problematique (donc quasi tolerable), il le devient plus si le callback est plus long et necessite d’être debuggé / profilé

    • http://www.mathieurobin.com/ Mathieu ROBIN

      Comme souvent, tu parles bien^^

      Côté Safari 9, je ne sais pas pourquoi il n’est pas intégré. Mais c’est vrai que du coup il parait léger. Ceci dit, à dire vrai, Safari n’est pas vraiment mon plus gros problème. Je n’irai pas dire que je m’en fous mais il est relativement à jour par rapport à d’autres que je suis encore obligé de maintenir (IE 8 par exemple, 3% de mon CA, gain largement supérieur au coût de maintenance).

      Concernant tes 4 points :
      – Parfaitement d’accord.
      – Ce point ne devrait pas perdurer. Dans le sens où d’ici 2 ou 3 ans, les navigateurs qui ne la supporteront pas auront massivement disparu. Même si il y a des irréductibles, on n’arrivera bientôt plus à empêcher la MAJ automatique. De ce côté là, je ne m’inquiète pas.
      – Même si ce point est atténué comme tu le suggères, ce n’est pas forcément une bonne pratique que d’encourager à aller dans des pratiques non considérées comme bonnes. Et donc à moins encourager à bien connaître le fonctionnement du langage.
      – Rien à redire.

Articles liés