JavaScript EcmaScript6

a marqué ce sujet comme résolu.

Bonjour à tous,

Les discussions sur la norme EcmaScript6 pour JavaScript commençAnt à se tasser et leur implémentation arrivant gentiment dans Node.js et les navigateurs, je pense que ça serait une bonne idée de faire un article pour en parler et expliquer en quoi c'est une véritable révolution pour le langage. Je sais, plein de monde en parle déjà bien assez partout ailleurs. Mais vous avez fait de splendides billets techniques sur les dernières nouveautés de python (s'il ne fallait citer que ceux-là), alors pourquoi ne pas parler de JavaScript ? Avec la place qu'il occupe aujourd'hui, ça me paraît plutôt important…

Cet article pourrait inclure les sujets suivants :

  • Les fonctions raccourcies a.k.a. arrow functions
  • Le mot-clé class
  • let, const et var
  • Les itérateurs et la boucle for…of
  • Les générateurs/coroutines
  • L'opérateur ... (point de suspension)), i.e. paramètres du reste + décomposition
  • Les autres bricoles diverses peut-être un peu moins importantes (Array.from/of, Map/Set/WeakMap/WeakSet, promesses, raccourcis dans les littéraux objet, paramètres par défaut des fonctions, …)
  • La compatibilité des navigateurs dans tout ça

J'en ai sûrement oublié, car il y en a beaucoup plus que ça, et il y a plein de choses que je n'ai pas encore testé moi-même. Pour le moment, mes premiers ressentis :

  • Les arrow functions sont extrêmement pratiques, c'est un raccourci plus que bienvenu et en plus ça résoud des problèmes de propagation du this
  • Mème s'il ne faut pas oublier le fonctionnement prototypal du langage, le mot-clé class et ses adjoints extends et super sont aussi très bienvenus; ça facilite grandement l'écriture et la compréhension de l'héritage classique. Je sais, ce sucre syntaxique a été passablement critiqué parce qu'il tend à cacher des choses au novice, et parce qu'on perd en flexibilité entres autres, mais bon.... je ne pense pas qu'on puisse être fondamentalement contre une simplification, et ce n'est pas comme si on était absolument obligé de l'utiliser (on peut toujours le faire « à l'ancienne »).
  • Quand on a fait du Java, du C++ et un peu de python, la notion d'itérateur paraît tellement évidente qu'on se demande pourquoi ça n'a pas réellement émergé plus tôt. Gare à la confusion for…of et for…in! Le mieux sera sans doute d'oublier complètement for…in à l'avenir.
  • l'arrivée relativement récente des générateurs/coroutines un peu partout (PHP et python entres autres) me réjouit; ça me paraît d'autant plus important et intéressant en JavaScript qu'il a été particulièrement bâti sur des concepts et API asynchrones (alors qu'en python on peut facilement s'en passer et qu'en PHP ça ne me paraît de très loin pas si utile). Question bonus, qu'est-ce qui justifie l'astérisque dans la syntaxe ?
  • Le reste est essentiellement une question de cosmétique, mais c'est sympa quand même.

Le gros WTF qui me reste est celui des variables… OK pour const, ce n'était pas forcément indispensable mais ça permet de mieux sécuriser le code. Par contre je ne comprends encore pas trop le problème avec var et pourquoi du coup on a inventé let. ON pourra en discuter ailleurs si vous avez des réponses longues à fournir sur le sujet.

Du côté du support des navigateurs, en gros la situation est actuellement la suivante: l'essentiel est déjà implémenté dans les dernières versions de Firefox et Crhome; Edge en partie aussi; Safari pas encore mais on peut raisonnablement supposer que ça le sera dans la prochaîne version majeure (et donc sûrement dans iOS10/OS X 10.11) vu que ça existe dans la technical preview. Et comme d'habitude, on peut aller se brosser pour IE, même IE11. Sources: MDN et caniuse

Quant à Node.js, puisqu'il est basé sur V8 comme Chrome, il suit les évolutions de ce dernier; pas mal de fonctionalités ES6 sont déjà disponibles par défaut (sans flag --harmony). Testé avec la v4.4.3.

ET vous, qu'en pensez-vous ? Faire un article là-dessus serait intéressant, ou est-ce qu'on en parle déjà bien assez ailleurs ? Serait-ce encore beaucoup trop tôt pour en parler ?

Avez-vous déjà testé tout ou partie de ces nouveautés ? Des avis ?

Envisagez-vous, ou pensez-vous qu'on peut envisager une utilisation concrète en production bientôt (avec ou sans transpileur) ? C'est aussi une question à laquelle on peut tenter de répondre en conclusion de l'article.

Voilà… à vous maintenant !

+3 -0

Mais vous avez fait de splendides billets techniques sur les dernières nouveautés de python (s'il ne fallait citer que ceux-là), alors pourquoi ne pas parler de JavaScript ?

Pourquoi pas en effet. Perso je n'ai rien contre. Mais autant pour Python je l'ai prit en charge car je maîtrisai le sujet, autant pour JS je ne me vois pas rédiger un truc dessus.

Je pense que c'est une bonne idée mais il faut simplement trouver des gens motivé pour le rédiger.

Le gros WTF qui me reste est celui des variables… OK pour const, ce n'était pas forcément indispensable mais ça permet de mieux sécuriser le code. Par contre je ne comprends encore pas trop le problème avec var et pourquoi du coup on a inventé let. ON pourra en discuter ailleurs si vous avez des réponses longues à fournir sur le sujet.

Dans les grandes lignes, vardéclare une variable sur tout le corps d'une fonction, alors que letdéclare une variable dont la portée se limite au bloc (un bloc if par exemple).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
function lol() {
    if (true) {
        var x = 42;
    }
    console.log(x);
}

lol()
VM307:5 42 // ok, on a x en dehors du bloc


function lol2() {
    if (true) {
        let x = 42;
    }
    console.log(x);
}

lol2()
VM329:5 Uncaught ReferenceError: x is not defined() // plus maintenant

Ça permet d'isoler un peu mieux les noms, et d'éviter du coup quelques soucis, du genre ré-utiliser par inadvertance une variable sans faire gaffe alors qu'il fallait pas. Désolé, j'ai pas vraiment d'exemple précis en tête, là…

Envisagez-vous, ou pensez-vous qu'on peut envisager une utilisation concrète en production bientôt (avec ou sans transpileur) ? C'est aussi une question à laquelle on peut tenter de répondre en conclusion de l'article.

Oui, d'après mon expérience ; avec des outils comme Babel on peut utiliser intensivement le letet le JS ES6 (arrows, générateurs, syntaxe ..., etc.) et il pondra un bon ES5. Le transpilleur TypeScript peut aussi le faire. Et au moins un outil de contrôle de qualité (le seule que je connais, JSHint), supporte ES6.

+0 -0

Node.js supporte encore plus de fonctionnalités ES6 en mode strict ('use strict';), comme les classes et les symboles. Voir https://nodejs.org/en/docs/es6/

Je ne serais personnellement pas beaucoup intéressé par un tutoriel sur les différences entre ES5 et ES6, il en existe déjà plein. Par contre, à mon avis un tutoriel sur Javascript partant des bases et n'utilisant que ES6 peut être beaucoup plus intéressant, en particulier pour les gens qui veulent commencer maintenant à apprendre du Javascript moderne. C'est aussi plus de travail, cela dit.

à mon avis un tutoriel sur Javascript partant des bases et n'utilisant que ES6 peut être beaucoup plus intéressant

emersion

Je plussoie, il y aura toutefois un gros problème de maintenance, puisqu'il il avait été dit par ECMA International qu'une nouvelle version d'ECMAscript serait réalisée chaque année à partir de maintenant (et cela semble être appliqué, puisqu'on aura un ES7 / ES2016 cette année normalement), cela implique des modifications - sûrement majeures - du tutoriel chaque année.

J'imagine que si ils font des révisions tous les ans, elles seront plus petites. Les révisions ne seraient pas majeur donc.

Pour le reste je ne pense pas que l'idée soit de faire un TUTO sur le passage ES5 -> ES6 mais un ARTICLE comme on a put le faire sur Python 3.5 : plein de gens connaissaient déjà Python 3.4, ça permettait de présenter les nouveautés de façon sympa pour ceux qui ne suivent pas tout.

Perso j'utilise souvent JS au boulot mais je ne suis pas les dernières nouveautés, un tel article je le lirai probablement.

Je ne serais personnellement pas beaucoup intéressé par un tutoriel sur les différences entre ES5 et ES6, il en existe déjà plein. Par contre, à mon avis un tutoriel sur Javascript partant des bases et n'utilisant que ES6 peut être beaucoup plus intéressant, en particulier pour les gens qui veulent commencer maintenant à apprendre du Javascript moderne. C'est aussi plus de travail, cela dit.

L'idée c'est bien un article et non pas un tutoriel. Comme tu le dis, des tutoriels qui expliquent en détail les changements entre ES5 et ES6, il y en a déjà à la pelle, donc aucun intérêt.

Pour le reste je ne pense pas que l'idée soit de faire un TUTO sur le passage ES5 -> ES6 mais un ARTICLE comme on a put le faire sur Python 3.5 : plein de gens connaissaient déjà Python 3.4, ça permettait de présenter les nouveautés de façon sympa pour ceux qui ne suivent pas tout.

C'est justement ce que j'avais apprécié avec la news sur python 3.5. Je ne suis pas python d'assez près pour être au courant de toutes les nouveautés tout le temps car je n'ai pas de projet concret en cours l'utilisant sérieusement. J'avais trouvé la news sympa parce qu'elle présentait les nouveautés de façon relativement concise mais avec tout de même bien assez de détails pour donner envie de la télécharger et de le'ssayer tout de suite. Par contre une nième news sur le passage de python 2 à python 3, ça m'aurait sûrement barbé, vu que personnellement je suis arrivé après la bataille.


Au-delà de ça, effectivement, un tutoriel complet démarrant directement et exclusivement sur ES6 serait une très bonne idée. D'autant plus que :

  • La plupart des tutoriels sur JavaScript (ou en tout cas ceux que j'ai déjà pu trouver) ne sont pas d'une super qualité et/ou ne sont pas trop à jour, même par rapport à Es5. Un certain nombre parlent encore même de JavaScript 1.5, 1.6, 1.7, attention ça ne marche qu'avec IE8 et c'est pas compatible IE6, etc… Par exemple, pour ES5, qui connaît la syntaxe raccourcie get X () { ... } pour définir un accesseur ? Bien trop peu de monde j'ai l'impression, vu le temps que j'ai mis pour trouver la réponse la première fois que je suis tombé dessus. ET pourtant ça existe depuis ES5. Pareil pour Array.prototype.forEach/map/filter/reduce/each/some qui ont l'air d'être largement ignorés ou en tout cas sous-exploités. JE me suis moi-même surpris en apprenant que use strict existe aussi déjà depuis ES5!
  • ES6 nous permet de faire à peu près totalement abstraction du modèle objet prototypal de JavaScript. A mon avis, pas besoin d'encombrer un débutant avec ça avant l'ultime chapitre, surtout que c'est une source de confusion et d'incompréhension courante qui fait dire à tort que « ON peut faire de l'OO en JavaScript mais c'est très compliqué ». Avec le mot-clé class on peut sans autre parler d'OO classique et ça passera très bien jusqu'à la partie sur les notions avancée. Tout ça, en ES5, c'est juste… pas possible parce qu'effectivement c'est pas si simple.

Par contre là où on a un problème avec un tutoriel JavaScript pour débutant, c'est pour fixer le cadre général. Faut-il parler de JavaScript dans Node.js, ou dans le navigateur ? Dans le navigateur c'est l'utilisation la plus courante et la plus connue, mais ça se mêle inévitablement à HTML et CSS. Ce qui confuse et perturbe probablement largement l'apprentissage. De l'autre, Node c'est cool et ça permettrait de partir sur un tutoriel dans une forme plus classique comparable à ceux sur python, ruby, lua ou autre chose, mais c'est quand même clairement pas fait pour un débutant complet en programmation; il faudrait vraiment mettre le paquet notamment sur l'asynchronie tout en restant abordable ! ET pas vraiment de moyen de savoir ce que celui qui veut apprendre JavaScript veut faire avec… l'un, l'autre, ou les deux à la fois. C'est peut-être deux tutoriels distincts qu'il faut, du coup. Je pense que prendre un framework genre Meteor pour être sûr de tout mélanger n'est sûrement pas une solution non plus; ces frameworks sont simples en apparence mais ils cachent des choses bien incidieuse, parmi lesquelles rendre flou la différenciation entre ce que fait le client et ce que fait le serveur (sûrement le meilleur moyen de se foirer complet en terme de sécurité ou de performances si on ne maîtrise pas)

Je plussoie, il y aura toutefois un gros problème de maintenance, puisqu'il il avait été dit par ECMA International qu'une nouvelle version d'ECMAscript serait réalisée chaque année à partir de maintenant (et cela semble être appliqué, puisqu'on aura un ES7 / ES2016 cette année normalement), cela implique des modifications - sûrement majeures - du tutoriel chaque année.

J'ai même déjà vu des choses indiquant 2017! Mais je ne pense pas que ça poserait tant de problèmes que ça, on ne peut pas faire évoluer le langage si vite que ça. Il faut quand même que Google, Mozilla, Apple et Microsoft puissent suivre.

ET puis, vu sous un autre angle, on peut dire qu'avec ES6, JavaScript rattrape plus ou moins son retart sur les autres langages modernes. A partir de là il ne peut pas aller plus vite que les tendances. ON a l'impression qu'il évolue d'un coup très vite, mais en fait c'est parce qu'on a réutilisé des concepts généraux qui ont mis des années à mûrir dans d'autres langages. Par exemple, même si ça fait longtemps que ça existe, ça ne fait pas si longtemps que ça qu'on parle de générateurs et de coroutines et que c'est disponible dans les implémentations; de même pour les arrow functions, on ne peut pas nier qu'on a profité du travail fait pour Java8, idem pour les propriétés et C# à l'époque de ES5… Et pour class et les notations raccourcies, c'est les années d'usage qui a certainement dirigé l'ECMA vers ces simplifications.

Dans la continuation des opérateurs de décomposition sophistiqués, on pourra peut-être voir venir un système de pattern matching; ou peut-être qu'ils se décideront à faire quelque chose pour la surcharge d'opérateur. ON pourrait imaginer aussi, comme d'autres langages l'ont déjà proposé, voir un accès null safe aux propriétés, du genre objet.propriete?.sous_propriete?.valeur. Mais il n'y a plus non plus 36000 éléments aussi importants dans l'air du temps qui pourraient être candidats tout de suite maintenant. ON ne sait pas qui sera le prochain à proposer un nouveau concept fondamental qui sera adopté partout, mais ce qui est sûr c'est que ça ne peut pas arriver tous les quatre matins non plus.

+0 -0

J'imagine que si ils font des révisions tous les ans, elles seront plus petites. Les révisions ne seraient pas majeur donc.

Kje

On a déjà async & await, "trailing commas parameters", les décorateurs, les propriété de classes, les "function bindings" et les nouveaux "Observers" dans ES2016/2017 (version censé sortir cette année mais marquée ES2017 dans les drafts), ce qui fait beaucoup à traiter, sans parler des choses que je ne cite même pas telles que les nouvelles propriétés des types de référence et qui seront dans la spec… Je ne dit pas que c'est impossible, je dis que si c'est fait sous forme de tutoriel, il nous faudra du monde pour le mettre à jour chaque année afin de suivre les nouveautés

EDIT : Je suis plus pour la forme d'article, mais ça fait un peu redondant avec ce qu'on peut trouver ailleurs sur le web, n'oublions pas que l'idée proposée plus haut est de faire un tutoriel JS depuis ES6, pas un tutoriel sur les nouvelles fonctionnalités.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte