L'assemblée générale Ecma International a annoncé l'approbation d'ECMAScript 6

Version imprimable

Voir 40 message(s) de cette discussion en une page

18/06/2015, 10h28
Stéphane le calme

L'assemblée générale Ecma International a annoncé l'approbation d'ECMAScript 6

L'assemblée générale Ecma International a annoncé l'approbation d'ECMAScript 6,
qui devient donc officiellement un standard

L'Assemblée générale Ecma International a annoncé l'approbation d'ECMA-262 6e édition, la nouvelle version du standard sur lequel est basé JavaScript.

Pour rappel, JavaScript a été créé par Brendan Eich en 1995, mais il lui aura fallu 20 ans pour connaître une évolution de certaines des caractéristiques parmi les plus populaires dans d'autres langages modernes. Même si, au départ, JavaScript n'a pas un langage des plus impressionnant, Brendan Eich a apporté une excellente idée : un langage pour le navigateur. JavaScript a tout de suite su capter l’attention, a été soumis à la standardisation l'année suivante, avec la version 1.0 standardisée par l'Ecma en 1997, suivie par la version 2.0 en 1998 qui embarquait quelques changements mineurs, puis la version 3.0 en 1999 qui embarquait quelques nouvelles fonctionnalités.

Le langage a été par la suite quelque peu négligé pendant plusieurs années jusqu'à ce que l'Ajax ait été considéré comme une solution raisonnable pour construire des applications client dans le navigateur. C’est alors qu’un travail plus intense sur l'amélioration de JavaScript a été amorcé, mais les parties concernées n'ont pas été d’accord de prime abord sur la voie à suivre jusqu'en 2008 lorsque le TC39, le comité chargé de surveiller ECMAScript, a proposé un accord et a décidé qu’il y aurait des itérations plus petites d’abord, matérialisées par l’ECMAScript 5 (ES5) en 2009, puis des itérations plus importantes matérialisées par l’ES6 qui vient d’être approuvé.

Le nom officiel de cette dernière version est ECMAScript 2015. Notons que l’Ecma a l'intention de publier plus souvent de nouvelles versions par plus petits incréments, le prochain étant prévu pour l'année prochaine et qui sera appelé ECMAScript 2016. Désormais, le nom des nouvelles versions incluront ECMAScript suivi de l'année de leur publication.

ES6 est une amélioration majeure par rapport ES5, la spécification du langage ayant près de 600 pages, comparativement à 245 pour les ES 5.1. ES6 ajoute beaucoup de fonctionnalités basiques telles que les modules et les classes, et certaines plus utiles comme Maps, Sets ou Generators. En plus d’être une amélioration majeure, ES6 est totalement rétro compatible avec les versions précédentes, le comité de normalisation ayant décidé d'éviter de « briser le web » dans le cas où des versions seraient non compatibles avec le langage. Par conséquent, tout le code précédent s’exécute et la transition est plus douce, même si cela pourrait aussi signifier que certaines plaintes formulées par des développeurs puissent rester d’actualité.

A l’heure actuelle, aucun des agents JavaScript ne soutient pleinement ES6, alors les développeurs désireux d'utiliser les dernières fonctionnalités du langage devront transpiler le code dans ES5. Et il faudra un certain temps pour voir les principaux navigateurs appliquer pleinement les fonctionnalités ES6, peut-être même plus d'un an.

Les travaux ont commencé sur ECMAScript 2016, un certain nombre de propositions ont été déjà présentées, y compris, entre autres : les fonctions asynchrones, les objets typés ou même les class decorators. Bien que ces caractéristiques soient activement étudiées par le comité, nous ne pouvons pas statuer quant à leur avenir. Certaines seront inclues dans la prochaine spécification, certaines dans celles à venir, et certaines pourraient même ne jamais être adopté. Pour plus d’information, le TC39 Process explique les différentes étapes traversées par une caractéristique désirée jusqu'à ce qu'elle soit adoptée et inclus dans le langage.

Si l’évolution de JavaScript a été lente au début, elle a repris du rythme récemment. Probablement un signe qui montrerait que JavaScript est là pour rester.

Source : Ecma International, TC39 Process (Google Docs)
18/06/2015, 11h19
Markand

_o\ \o\ \o| |o| |o/ /o/ /o_
18/06/2015, 11h32
SpaceFrog

je dirais même plus
18/06/2015, 12h06
crodilus

HALLEJUHA Nous allons pouvoir enfin utiliser Class et Extends ! Que le Grand Divin Gourou de l'informatique nous bénisse :mouarf: !
18/06/2015, 12h39
Watilin

Citation:

Envoyé par crodilus

HALLEJUHA Nous allons pouvoir enfin utiliser Class et Extends ! Que le Grand Divin Gourou de l'informatique nous bénisse :mouarf: !

Ce qui est amusant c'est que cette nouvelle spec n'apporte quasiment rien de nouveau du côté de l'héritage par prototypes. Est-ce une preuve que cet aspect était déjà rôdé dans ES5 ? C'est peut-être le moment de s'y mettre… Ou pas, car après tout, le langage nous donne le choix, respectons ceux qui choisissent l'une ou l'autre solution ;)

Je partage un super site que j'ai découvert pas plus tard qu'hier : http://es6-features.org/
18/06/2015, 14h12
crodilus

Citation:

Envoyé par Watilin

Ce qui est amusant c'est que cette nouvelle spec n'apporte quasiment rien de nouveau du côté de l'héritage par prototypes. Est-ce une preuve que cet aspect était déjà rôdé dans ES5 ? C'est peut-être le moment de s'y mettre… Ou pas, car après tout, le langage nous donne le choix, respectons ceux qui choisissent l'une ou l'autre solution ;)

Je partage un super site que j'ai découvert pas plus tard qu'hier : http://es6-features.org/

Je trouve que la programmation par prototype peut porter à confusion car le terme function est utiliser pour plusieurs choses différentes. Une fonction, un constructeur,une méthode... Certain me diront oui mais en JS un constructeur ou une méthode est une function Sur le principe technique c'est certain mais sur la conception non.

Je trouve que Class et Extends vont apporter de clarté au code.
18/06/2015, 14h22
SylvainPV

Citation:

Envoyé par Watilin

Ce qui est amusant c'est que cette nouvelle spec n'apporte quasiment rien de nouveau du côté de l'héritage par prototypes. Est-ce une preuve que cet aspect était déjà rôdé dans ES5 ? C'est peut-être le moment de s'y mettre… Ou pas, car après tout, le langage nous donne le choix, respectons ceux qui choisissent l'une ou l'autre solution ;)

Oui enfin on est tous d'accords sur le fait que les "classes" en JavaScript ne sont qu'une syntaxe travestie de la POO par prototype pour faire plaisir aux développeurs accoutumés à la POO par classe. Techniquement, ce sont toujours les prototypes qui sont utilisés.

Citation:

In ECMAScript 6, we'll see the introduction of "classes". Many, many people argue that they are unnecessary, and technically they are. ES6 classes aren't even classes; they are syntactic sugar that eases our development. That's all. Classes aren't an entirely new construct in JavaScript, they are just a new way of saying the exact same thing, except it makes more sense and is simpler to use.

http://www.joezimjs.com/javascript/j...-say-about-it/

Même Brendan Eich en plaisante:
https://www.youtube.com/watch?v=NJxB0Pp69IQ

Sinon il y a quand même des choses intéressantes en ES6 pour les prototypes : Object.setPrototypeOf même s'il était déjà supporté par certains navigateurs depuis quelques temps ; et Object.assign pratique pour faire de l'héritage multiple par composition ;
18/06/2015, 14h49
Traroth2

Quel est le niveau d'adoption actuel ou dans un futur prévisible par les différentes applications implémentant Javascript (browsers, node.js, Cordova...) ? Où peut-on voir l'évolution de l'adoption de cette norme ?
18/06/2015, 15h44
SylvainPV

@Traroth: ici : https://kangax.github.io/compat-table/es6/

Citation:

Envoyé par SylvainPV

Oui enfin on est tous d'accords sur le fait que les "classes" en JavaScript ne sont qu'une syntaxe travestie de la POO par prototype pour faire plaisir aux développeurs accoutumés à la POO par classe. Techniquement, ce sont toujours les prototypes qui sont utilisés.

Oui mais le fait qu'il y ait l'héritage change la donne.

ES6 :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
class Rectangle extends Shape { 
    constructor (id, x, y, width, height) { 
        super(id, x, y); this.width = width; 
        this.height = height; 
    } 
} 
 
class Circle extends Shape { 
    constructor (id, x, y, radius) { 
        super(id, x, y); 
        this.radius = radius; 
    } 
}

ES5 :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
var Rectangle = function (id, x, y, width, height) { 
    Shape.call(this, id, x, y); 
    this.width = width; this.height = height; 
}; 
Rectangle.prototype = Object.create(Shape.prototype); 
Rectangle.prototype.constructor = Rectangle; 
 
var Circle = function (id, x, y, radius) { 
    Shape.call(this, id, x, y); 
    this.radius = radius; 
}; 
Circle.prototype = Object.create(Shape.prototype); 
Circle.prototype.constructor = Circle;

Tu préfères quelle syntaxe ? :mrgreen:

18/06/2015, 16h37
sekaijin

Je fais parti de ceux qui pense qu'on n'aurais pas du mettre de classe dans ES6
mais en plus on aurait du retirer le mot new qui lui aussi apporte de la confusion.

Mais bon il faut faire plaisir à d'autres
Perso je n'utiliserais pas de classe je trouve que que son usage appauvri la POO à base de prototype.

heureusement qu'il n'y a pas que ça.
A+JYT
18/06/2015, 17h14
Aurelien Plazzotta

La syntaxe EcmaScript 6 se rapproche indubitablement du Java et du Dart. Pour le meilleur et pour le pire, pour l'instant suis-jé sans opinion. :)
18/06/2015, 23h05
SylvainPV

Citation:

Envoyé par Gugelhupf

Tu préfères quelle syntaxe ? :mrgreen:

Une syntaxe qui ne t'obligerait pas à déclarer un constructeur quand tu n'en as pas besoin, qui ne fout pas en l'air ton code quand tu oublies new pour une instanciation, et qui te permet de faire de l'héritage multiple. Une syntaxe comme Proto, Stampit ou ObjectModel. As-tu lu mon dernier article ? Le chapitre IX me semble fort à propos.

@sekaijin: bien d'accord avec toi sur l'opérateur new, malheureusement on est pas prêt de voir des fonctionnalités retirées en JavaScript, rétrocompatibilité oblige. Faire ton propre linter ou ton propre framework reste la meilleure option.
19/06/2015, 01h42
danielhagnoul
On ne mettra jamais d'accord les puristes (prototype) et les utilisateurs du sucre syntaxique (Class). Les critiques sur JS exposées sur DVP et ailleurs sur le web sont généralement fondées.

Les puristes sont souvent des programmeurs qui veulent pouvoir modifier tout à tout moment (JS est un langage très permissif). Partant de ce constat ils ne peuvent que trouver une multitude d'avantages à la programmation-objet par prototype.

Les programmeurs venant d'autres langages-objets aiment "les gardes fous" et la rigueur. Ils ont été formés dans cet esprit. Apprendre qu'en JS, le code qu'ils ont concocté avec "amour" peut être cassé en une ligne de code leur fait faire des cauchemars.

ES5 et ES6 ont été conçus pour satisfaire partiellement ces programmeurs, et permettent aux puristes d'ignorer les nouveautés et de continuer comme avant.

ES5 avait déjà fait, pour la construction d'objet, une belle avancée dans la direction de la rigueur. Les descripteurs (enumerable, writable et configurable) offrent un réglage fin des permissions accordées. Bien entendu, elles n'ont pas été et ne seront jamais utilisées par ceux qui veulent pouvoir modifier tout à tout moment.

La classe ES6 offre des possibilités minimales, mais c'est le début de l'aventure.

Pour les amateurs, les classes offrent quelques avantages :
- Elles sont compatibles avec le code actuel (ES5).
- Elles sont plus faciles à appréhender.
- L'héritage est intégré dans le langage.
- La prochaine version du langage intégrera probablement une forme d'héritage multiple (traits).
- Elles aident les outils qui analysent statiquement le code (IDE, contrôleurs de type, contrôleurs de style, etc.).
Je suis loin d'avoir tout lu et tout compris sur ES6, mais je suis certain d'aimer les classes ES6 autant que les objets ES5.
19/06/2015, 02h04
SylvainPV

Je ne vois pas bien le rapport entre les prototypes et la mutabilité des objets. Utiliser les classes ES6 n'apporte aucun garde-fou, on peut toujours venir les modifier dynamiquement. Inversement on peut utiliser Object.seal et Object.freeze pour rendre immuable n'importe quel objet, qu'il s'agisse d'une classe, d'un constructeur, d'un prototype, d'une factory ou quoi que ce soit d'autre. D'après moi, il n'y a aucun lien entre ces deux sujets ; juste un vieux préjugé selon lequel la POO par classe serait plus rigoureuse que la POO par prototype.
19/06/2015, 04h46
gretro

Au boulot, on a commencé à utiliser Typescript pour addresser ce genre de problème. TS reprend une bonne partie de la syntaxe de ES6, mais permet de changer la version d'ECMAScript dans laquelle le code TS sera transpillé. Du coup, le jour où l'on voudra passer à ES6 (et qu'il sera pris en charge par une majorité de navigateurs), on changera une configuration, et ce sera fait. :ave:

Citation:

Envoyé par Watilin

C'est peut-être le moment de s'y mettre… Ou pas, car après tout, le langage nous donne le choix, respectons ceux qui choisissent l'une ou l'autre solution ;)

Je partage un super site que j'ai découvert pas plus tard qu'hier : http://es6-features.org/

Partage : voir mon message dans Où va-t-on avec JavaScript ?

Citation:

Envoyé par SylvainPV

Je ne vois pas bien le rapport entre les prototypes et la mutabilité des objets.

Je pense avoir été lu un peu trop vite. Je n'ai pas parlé de la mutabilité des objets.

Je connais ton point de vue et tes arguments, je suis convaincu que l'on ne sera jamais d'accord sur l'utilité des classes ES6.

Citation:

Envoyé par SylvainPV

Utiliser les classes ES6 n'apporte aucun garde-fou, on peut toujours venir les modifier dynamiquement.

Code:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
const
    kGetType = function( Obj ){
        return Object.prototype.toString.call( Obj ).match( /\s([a-zA-Z]+)/ )[ 1 ].toLowerCase();
    },
    Person = ( function( ){
 
        const
            kFirstName = new WeakMap(),
            kLastName = new WeakMap(),
            kFirstNameType = 'string',
            kLastNameType = 'string',
            kSetPerson = function( obj, first, last ){
 
                if ( kGetType( first ) === kFirstNameType && kGetType( last ) === kLastNameType ){
 
                    kFirstName.set( obj, first );
                    kLastName.set( obj, last );
 
                } else {
                    throw `Type des paramètres incompatibles.
                            first : ${ kFirstNameType } attendu, 
                            last : ${ kLastNameType } attendu`;
                }
 
                return obj;
            };
 
        return class {
            constructor( first, last ){
                kSetPerson( this, first, last );
            }
            get firstName( ){
                return kFirstName.get( this );
            }
            get lastName( ){
                return kLastName.get( this );
            }
            fullName( ){
                return kFirstName.get( this ) + " " + kLastName.get( this );
            }
        }
    })( ),
    Employee = ( function( P ){
 
        const
            kPays = Symbol( 'Pays' ),
            kPaysType = 'string',
            kSetPays = function( obj, value ){
 
                if ( kGetType( value ) === kPaysType ){
                    obj[ kPays ] = value;
 
                } else {
                    throw `Type des paramètres incompatibles.
                            pays : ${ kPaysType } attendu`;
                }
 
                return obj;
            };
 
        return class extends P {
            constructor( prenom, nom, pays ){
                super( prenom, nom );
                kSetPays( this, pays );
            }
            get pays( ){
                return this[ kPays ];
            }
            set pays( value ){
                kSetPays( this, pays );
            }
        }
 
    })( Person );

19/06/2015, 15h11
sekaijin

Je pense que se trompe lourdement entre poo par classe ou par prototype dans le navigateur

il fut un temps où tout cela était très simple
nous avions dans les navigateurs plusieurs langages vb js tcl etc.

Mais rien n'était normalisé.
Il se trouve qu'en reversant js dans la coupe ecma la base de js c'est normalisé et que le w2c l'a pris en compte.

devenant normalisé on a peu à peu abandonner les autres langages embarqué dans le navigateur.

je comprends tout à fait que certain préfèrent la poo à base de classe tout comme d'autre préfèrent les langages fonctionnels.
Je pense qu'il y a de la place pour tous.

Ce que je trouve dommageable c'est de vouloirs à tout prix intégrer des notions de langage à base de classe dans javascript.
je pense que c'est contre nature contre productif et que cela ne fait qu'ajouter de la confusion.

en y regardant de plus près. voici où nous en sommes
nous avons d'un coté un langage avec une syntaxe
une analyser syntaxique
un compilateur à la volée
et une machine virtuelle

il n'y a dans tout ça rien qui techniquement empêche de compiler un autre langage sur cette machine virtuelle.
c'est une technique aujourd'hui grandement éprouvée. on trouve ça dans la JVM avec Java, Scala, Ecmascript et bien d'autres

Je pense qu'il aurait été plus judicieux de partir dans cette voie.
porter un langage à base de classes sur l'EVM (EcmaVirtualMachine) Définir le binding du DOM pour ce langage
et implémenter le tout sur le navigateur.

on aurait ainsi un langage à prototype un langage à classe les deux gardant leur avantage et restant très clair dans leur modèle.
avec une telle approche il suffirait d'ajouter à cela une normalisation de l'amorce pour pouvoir compiler à l'avance le code pour
qu'i s'exécute sur le navigateur du client sans que le code ne soit accessible.

Mais voilà pour aller dans cette direction il faudrait que tous les acteurs se mettent d'accord et c'est loin d'être le cas.
Alors chacun ajoute au forceps des petit bout en essayant de mettre les autorité de normalisation devant le fait accompli.

et on se retrouve avec un langage à base de prototype qui contient des bout de syntaxe à base de classes mais qui n'implémente pas les modèles sous-jacent à cette théorie
qui laisse croire à ceux qui l'emploi qu'il en on les garantie. te tout en troublant l'apprentissage des tenant du prototype.

bref on se retrouve dans la pire des solution. personne n'est satisfait personne n'a de garantie solide.

enfin je constate que plus on avance plus les langages poo à base de classe intègrent des notions visant à assouplir le modèle jugé trop rigide et contraignant
et dans le même temps on a un langage très souple avec des défaut de clarté (surtout pour les débutant)
et au lieu d’améliorer ce dernier sur ces point faible on le rends encore plus confus en tentant d'y ajouter les verrous que l'on cherche à faire sauter partout ailleurs.

A+JYT
19/06/2015, 15h24
sekaijin

Je me réponds

je ne suis pas le seul à penser qu'il serait intéressant d'avoir une approche multilangage
et une séparation du langage et de la machine virtuelle

Brendan Eich parle sur son blog d'une approche assembleur pour le web
https://brendaneich.com/2015/06/from...o-webassembly/

Le W3C a créer un groupe à ce sujet
https://www.w3.org/community/webassembly/

A+JYT
19/06/2015, 15h34
SylvainPV

Citation:

Envoyé par danielhagnoul

Je pense avoir été lu un peu trop vite. Je n'ai pas parlé de la mutabilité des objets.

De quoi parlais-tu alors ? Tu as mentionné les descripteurs enumerable/writable/configurable, et le fait de "pouvoir modifier tout à tout moment".

Le code que tu as montré n'a rien à voir avec les classes ES6, il utilise les getters/setters ES5 tout comme ma bibliothèque ObjectModel.

Voir 40 message(s) de cette discussion en une page