Discussion :

[vermine]

ECMAScript 2016 : des mises à jour plus petites et plus fréquentes
pour l'ensemble de normes des langages de script

Le comité de ECMAScript, un ensemble de normes pour les langages de script tels que le JavaScript et l'ActionScript, a décidé l'an dernier de sortir des mises à jour plus petites, mais plus fréquentes. C'est pourquoi aujourd'hui, nous voyons sortir des versions dont le périmètre est restreint.

Quel en est l'objectif ? Il y en a plusieurs, à vrai dire. D'abord, c'est la coutume actuelle de sortir des révisions régulières et petites, selon un cycle de sortie standardisé et plus facile à gérer. Ensuite, ça en découle, le but est d'intégrer plus rapidement les nouvelles normes dans les navigateurs.

Ce n'est pas plus mal lorsque l'on se souvient que ES3 est sorti en 1999, un peu au mauvais moment pour certains navigateurs, et avec une foule de modifications. Que dire de ES4 qui n'a jamais été finalisé ? De son côté, ES5 était assez conservateur et, par conséquent, ES6 représente une grosse révision.

Du coup, que contient la norme ECMAScript 2016 (ES7) ?! Ce sera vite dit :

• la méthode Array.prototype.includes ;
• un opérateur d'exponentiation.

C'est tout.

La première détermine si un tableau contient un certain élément. C'est assez similaire à la méthode indexOf excepté que includes trouve les NaN.

La seconde s'explique plus facilement par un exemple. Ceci :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

x ** y

équivaut à cela :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

Math.pow(x, y)

En d'autres termes, 3 ** 2 = 9.

Ce nouveau mécanisme de révisions courtes permet également d'intégrer au mieux les propositions, car ces dernières doivent absolument être compatibles avec les autres. Si la révision est énorme, le risque d'incompatibilité, de redondance et autre augmente. Ce serait dommage d'avoir attendu tout ce temps pour au final se voir refuser sa proposition.

En tout cas, c'est plus simple à communiquer pour moi. 


Pour plus d'information sur les travaux en cours : le site ECMA International.


Et vous ?

Que pensez-vous de cette vision de sortir des petites versions ?

Retrouvez les cours et tutoriels sur les frameworks JavaScript.

[npuzin]

C'est une bonne idée de faire des updates plus fréquentes. Bon par contre, ils se sont pas trop foulés par contre.

En plus "l'opérateur d'exponentiation", ca me parait pas primordial, d'ailleurs je ne connais pas d'autre language ou on a un opérateur pour "pow".

Peu mieux faire, mais bel effort quand meme

[melka one]

bonne idée je suis pas sur on risque de se retrouvé avec un langage usine ça commence déjà a en être un.

quand je vois cette syntaxe x ** y c'est vraiment pas parlant au moins avec math.pow on sait tout de suite de quoi il s'agit c'est en quelle que sorte une regression.

[marts]

je ne connais pas d'autre language ou on a un opérateur pour "pow"

On l'a en Python. Mais effectivement ça n'a rien de primordial.

Juste ces 2 évolutions en un an, c'est très léger ! Il faut espérer que c'est parce qu'un gros travail est fait sur d'autres à venir.

[Jarodd]

En plus "l'opérateur d'exponentiation", ca me parait pas primordial, d'ailleurs je ne connais pas d'autre language ou on a un opérateur pour "pow".

http://fr.php.net/pow

Perso je préfère la notation **. Le pow me fait surtout penser à Mario.

[SylvainPV]

C'est dommage de ne pas inclure certaines fonctionnalités dans la norme faute de temps pour les traiter ou les finaliser, alors qu'il y a un consensus. C'est le cas de Object.values, Object.entries, Object.getOwnPropertyDescriptors qui ont été reportées à la norme ES2017. La version annuelle est une bonne idée pour dynamiser le rythme de développement du langage, maintenant il faut se donner les moyens pour suivre ce rythme ; en augmentant la fréquence des meetings du TC39 par exemple.

Pour ma part j'attends surtout les async functions qui sont selon moi une avancée bien plus intéressante que les générateurs d'ES6 (que je n'ai jamais vu utilisés en dehors de certaines expérimentations théoriques).

[danielhagnoul]

Avant d'introduire des nouveautés dans le langage, il serait prudent de finaliser l'implémentation de ES2015 dans Chrome, Firefox et Edge.

D'un côté, on a une avancée potentielle :

ES2016 : Array.prototype.includes

et de l'autre, un recul :

Chrome désactive ES6 Array.prototype.values() en raison de problèmes de compatibilité: https://bugs.chromium.org/p/chromium...tail?id=615873

[SylvainPV]

Pourquoi attendre l'implémentation par les éditeurs pour avancer sur les standards ? IE et Chrome ne supportent toujours pas 100% de la spec ES5 malgré qu'elle ait été publiée en 2009, heureusement qu'on ne les a pas attendus pour ES6 ! Les développeurs non plus ne veulent pas attendre, c'est pour ça que Babel a été inventé avant même que la norme ES6 ne soit finalisée.

Les organismes de standardisation doivent avoir l'avance nécessaire pour dynamiser le rythme de développement des navigateurs. On a dû attendre dix ans entre ES3 et ES5, et ça a été la décennie du monopole Internet Explorer. Puis six autres années à attendre pour ES6, et ça a donné les préfixes vendeurs et les Native Clients. Le web se porte beaucoup mieux quand ce sont les standards qui mènent la barque, et pas les éditeurs.

Et je déplore la décision de Chrome de retirer une feature à cause d'un CRM mal codé made in Microsoft, alors que Microsoft Edge supporte cette feature depuis sa sortie. C'est assez ironique quand on y pense...

[marts]

Les organismes de standardisation doivent avoir l'avance nécessaire pour dynamiser le rythme de développement des navigateurs. On a dû attendre dix ans entre ES3 et ES5, et ça a été la décennie du monopole Internet Explorer. Puis six autres années à attendre pour ES6, et ça a donné les préfixes vendeurs et les Native Clients. Le web se porte beaucoup mieux quand ce sont les standards qui mènent la barque, et pas les éditeurs.

Pas d'accord sur ES5. C'est la concurrence qui dynamise le développement des navigateurs, et c'est à Firefox qu'on doit d'avoir relancé le rythme des évolutions, à l'époque où IE régnait en maître absolu. Face à un tel monopole le standard seul n'a aucun pouvoir, et je dirais même aucune raison d'être puisqu'il y en a un de fait.

D'accord sur ES6, qui a trop tardé à être publié. Maintenant qu'il y a de la concurrence et une dynamique évolutive assez soutenue le standard doit devancer les navigateurs, et ne pas se contenter de lisser les divergences d'implémentations sur des pratiques et des concepts déjà répandus.

[SylvainPV]

C'est bien ce que je dis: entre 1999 et 2009 les standards n'ont quasiment pas bougé et c'était principalement les éditeurs qui innovaient. Pour subsister, Firefox a dû se calquer sur de nombreuses API propriétaires Microsoft telles que XMLHttpRequest. Et je pense qu'on est d'accord pour dire que cette API était sacrément mal fichue. J'aimerais bien connaître le nombre de devs qui savaient faire une requête AJAX sans jQuery ou autre utilitaire avant que le WHATWG ne propose l'API fetch.

La course au support ES6 faite par les éditeurs de navigateurs ces deux dernières années est pour moi le plus bel exemple de saine concurrence dans l'histoire de JavaScript. ActiveX est mort, les plug-ins sont mourants, et les éditeurs se félicitent dans les changelogs de retirer des préfixes vendeurs. Les choses se sont vraiment améliorées et j'espère que ça va continuer dans cette voie.

[Paleo]

Pour ma part j'attends surtout les async functions qui sont selon moi une avancée bien plus intéressante que les générateurs d'ES6 (que je n'ai jamais vu utilisés en dehors de certaines expérimentations théoriques).

Moi également, et j'attends aussi TypeScript 2 sur le sujet.
Pour info, un article qui soutient le contraire : partie 1, partie 2.

[SylvainPV]

Oui j'ai lu cet article mais c'est beaucoup de bruit pour pas grand chose. Seule la partie 2 présente les inconvénients et ils se résument à ça:

• obligation de patienter 1 tick pour les fonctions mi synchrones mi asynchrones
• pas de cancel de l'appel à l'extérieur de la fonction asynchrone
• pas de contrôle de l'ordre logique des opérations

Et effectivement les générateurs peuvent passer outre ces inconvénients. Sauf que pour utiliser des générateurs, on doit passer par des wrappers externes dont la fameuse coroutine. On peut faire le même genre de wrapper utilitaire avec les Promise et await. Et pour l'histoire du 1 tick, c'est délibéré : on décrit une fonction comme étant asynchrone, donc son exécution est déférée d'1 tick au minimum. Le contraire serait surprenant et pourrait provoquer des bugs suite à un ordre d'exécution inattendu pour le développeur.

J'ai pour ma part laissé tomber les générateurs, après avoir lu quantité d'articles qui essayaient de m'en vanter les mérites. Nouveau crédo : s'il n'est pas évident que ça résout un problème, alors c'est un nouveau problème.

[sekaijin]

ce qui me manque c'est quelque chose d'équivalent à
https://www.tcl.tk/man/tcl8.4/TclCmd/interp.htm
Qui est une fonction qui permet de créer un interprète fils et de lui donner quelque chose à faire.

La notion de task est quelque chose que j'aimerais voir arriver (et pas qu'en JS)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 task BufferTask{
     item : null,
 
     run : function() {
      continue = true;
      while(continue) {
        // some code 
        accept insert (in  aItem) {
           this.item = aItem;
        };
        // some code 
        accept remove (out aItem) {
           aItem = this.item;
        };
        // some code 
        accept stop () {
           continue = false;
        };
        // some code 
      };
     }
 };
 
//création d'une tache
myBuffer = new BufferTask();
//ici la tache s'exécute en parallèle. elle boucle de façon infinie
...
myBuffer.insert('toto'); // le process principal et la tache se synchronise (point de rendez-vous) pour échanger une donnée.
// la tache et le processus principal continuent de travailler en //
...
myBuffer.remove('toto');// le process principal et la tache se synchronise (point de rendez-vous) pour échanger une donnée.
 
// la tache et le processus principal continuent de travailler en //
...
myBuffer.stop(); // le process principal et la tache se synchronise (point de rendez-vous) pour demander l'arrêt de la tache.
 
myBuffer= null; //libération de la mémoire.

cette notion de programmation est un concept puissant permettant de faire de travaille // de façon claire et efficace. ce n'est pas la seule.
généralement la notion de rendez-vous n'est pas dans le langage et c'st au développeur de gérer les sémaphore et autre truc du genre. au final on n'a que peu de gens qui se servent de la puissance des processeurs.

A+JYT

[SylvainPV]

@sekaijin: ça me fait penser aux Web Workers, ce n'est pas précisément leur but ?

[sekaijin]

Oui est non les webworker ne sont dans dans EcmaScript mais dans le navigateur (norme W3C)
c'est une API.

je trouve que ce qu'il manque à JS c'est la possibilité de faire du parallélisme.

Les webWorkers pallient manque par une api dans le navigateur.
Mais EcmaScript ce n'est pas que le web.

la notion de fork permet de créer un autre process, les threads permettent paralléliser certaines partie d'un même process. les webworkers sont un peut comme des threads.
pour le moment à moins de faire appel à l'OS via une lib native fair un fork n'est dans possible en JS. ce n'est en tout cas pas dans le langage. on peut implémenter les threads via les webworkers http://keithwhor.github.io/multithread.js/
encore faut-il que le moteur supporte les webworkers.

il existe pas mal de choses dans ce giron là.

Je trouve que tout comme en C ou en TCL ... le langage devrait permettre de gérer le multithread et le multiprocess.


la notion de tache va beaucoup plus loin car elle embarque la notion de rendez-vous. et tout cela au niveau du langage lui-même.

pour la notion de tache il est extrêmement difficile d'élaboré une syntaxe à partir de ce qui existe dans JS pour implémenter la notion de rendez-vous.
il faut pour cela pouvoir indiquer qu'à des points précis du code de la tâche un rendez-vous est possible.
ensuite il faut l'implémenter donc mettre en place des sémaphores pour synchroniser les tâches. exécuter le code de synchronisation (c'est à dire le code du rendez-vous) puis relâcher la synchronisation pour continuer les tâche.
cette notion existe aujourd'hui dans certain langage celui qui l'a introduite est ADA. est sans les mots clefs dans le langage tout cela est extrêmement compliqué.

pourtant autant la notion de tâche est difficile à implémenter autant elle est facile d'usage.
A+JYT