[Autre] Que nous réserve le futur de JavaScript ? Un ingénieur de Mozilla détaille les nouveautés d'ECMAScript 6

[Idelways]

Que nous réserve le futur de JavaScript ?
Un ingénieur de Mozilla détaille les nouveautés d'ECMAScript 6




Dave Herman, ingénieur à Mozilla Labs et membre du TC39, était présent à la conférence YUIConf 2011 pour une présentation inédite de ce que nous réserve le futur du standard ECMAScript et du langage JavaScript.

Cette spécification ne sera pas finalisée avant 2013, mais des implémentations devraient bientôt voir le jour sur Firefox et Chrome. Le support d'ECMAScript 6 sur ce dernier profitera de facto au framework Node.js articulé autour du moteur V8.

Herman a souligné en début de keynote qu'une grande partie de ces nouveautés vient remplacer le code passe-partout que les développeurs JavaScript doivent placer un peu partout dans leur nouveau projet.

Ainsi naîtra la notion de Module en JavaScript pour lever l'obligation d'encapsuler son code dans une fonction anonyme afin d'éviter la propagation de variables globales.
Ces modules pourront être importés via code bloquant que le parseur parcours à la recherche d'instructions imports. Les fichiers ainsi appelés seront chargés sans devoir écrire en dur d'autres balises <script> et jouer avec le DOMReady.

Code javascript :

1
2
3
4
5
6
module Collections{
  export function Dict(){}
 
  import { $ } from "jquery.js"
  import { map, each } from "underscore.js"
}

Dave Herman a aussi réintroduit le mot clé let, qui revient dans le processus de standardisation des années après son annulation pour ECMAScript 4.
Il se positionne comme une alternative complémentaire de var, évitant les erreurs récurrentes où une variable déclarée dans une fonction se retrouve hors de portée dans une fonction fille.

Let permettra des assignations collectives non strictes, rendant cette écriture de code possible : let [x,y] = [3,4,5]; // x=3, y = 4.

Notons aussi l'arrivée des valeurs par défaut des fonctions, évitant le recours systématique au passage d'objets d'options, souvent fusionnés avec d'autres objets JSON portant les valeurs par défaut en tout début d'une méthode.

Toujours dans l'optique d'épargner aux développeurs du code passe-partout, Herman a évoqué le nouveau mot-clé « yield » qui permettra de stopper l'exécution d'une méthode jusqu'au prochain appel à method.next().

Cette notion de « fonctions génératrices » permet d'éviter les « pyramides de ruines », comme les décrit Herman. Ces structures imbriquées qui résultent de la nécessité de n'exécuter une partie du code que lorsqu'une autre a fini son travail (le cas d'une requête asynchrone par exemple).

Fini le callback spaghetti !

Code javascript :

1
2
3
4
5
6
7
8
9
10
spawn(function*(){
  // Notez l'étoile qui distingue les fonctions génératrices
 
  var foo = yield read('foo.txt'),
  var bar = yield read('bar.txt'),
  var baz = yield read('baz.txt'),
 
  yield sleep(1000);
  status.innerHTML = foo + bar + baz
});

ECMAScript 6 introduira aussi les chaînes de caractères multilignes, entourées d'accents graves (`).

Code javascript :

1
2
3
var htmlString = `Say hello to 
multi-line
strings!`

JavaScript aura aussi des objets proxy capables de contrôler tout ce qui se passe dans les méthodes qu'ils encapsulent. Notons aussi l'interpolation des chaines.

Code javascript :

1
2
var firstName = "Jack";
var message = `Hello ${firstName}!`; // "Hello Jack!"

Et bien d'autres nouveautés à découvrir en détail sur la vidéo de l'évènement :

Keynote de Dave Herman

Keynote de Dave Herman

Et vous ?

Que pensez-vous de ces nouveautés d'ECMAScript 6 ?

[grunk]

C'est bien sympa tout ça, mais quand on voit que IE10 prévoit l'implémentation de ECMAScript 5 , on est pas près de pouvoir gouter au joies de ces nouveautés en production :'(

[ferber]

a le mot clef "let" !
Ca me rappelé l'epoque ou adobe a donnée une partis du code source du flash player ( le moteur d'exécution d'as3 ) a Mozilla, et que mozilla a laissé le projet dans un placard, suite a l'abandon de l'eCam4 par le w3c grace au travail de de lobbying microsoft, un belle exemple de travail de normalisation.
Il en reste toujours des traces sur internet :
http://hg.mozilla.org/tamarin-centra...esc/src/esc.es

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
75
76
77
78
79
80
81
 
/* -*- mode: java; tab-width: 4; insert-tabs-mode: nil; indent-tabs-mode: nil;  -*- */
/* ***** BEGIN LICENSE BLOCK *****
 * Version: MPL 1.1/GPL 2.0/LGPL 2.1
 *
 * The contents of this file are subject to the Mozilla Public License Version
 * 1.1 (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 * http://www.mozilla.org/MPL/
 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Original Code is [Open Source Virtual Machine.].
 *
 * The Initial Developer of the Original Code is
 * Adobe System Incorporated.
 * Portions created by the Initial Developer are Copyright (C) 2004-2006
 * the Initial Developer. All Rights Reserved.
 *
 * Contributor(s):
 *   Adobe AS3 Team
 *
 * Alternatively, the contents of this file may be used under the terms of
 * either the GNU General Public License Version 2 or later (the "GPL"), or
 * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
 * in which case the provisions of the GPL or the LGPL are applicable instead
 * of those above. If you wish to allow use of your version of this file only
 * under the terms of either the GPL or the LGPL, and not to allow others to
 * use your version of this file under the terms of the MPL, indicate your
 * decision by deleting the provisions above and replace them with the notice
 * and other provisions required by the GPL or the LGPL. If you do not delete
 * the provisions above, a recipient may use your version of this file under
 * the terms of any one of the MPL, the GPL or the LGPL.
 *
 * ***** END LICENSE BLOCK ***** */
 
{
    let total_frontend = 0;
    let total_backend = 0;
 
    let before = new Date();
 
    let files = ESC::filterCommandLine(Util::commandLineArguments());
 
    let prof = ESC::flags.profile_compiler;
 
    if (prof)
        ESC::startProfile();
 
    for ( let i=0, limit=files.length ; i < limit ; i++ ) {
        let fname = files[i];
        let [parse,cogen] = ESC::compileFile(fname);
        total_frontend += parse;
        total_backend += cogen;
        print (fname);
        print ("  Scan+parse:  " + parse + " ms");
        print ("  Cogen:       " + cogen + " ms");
 
        // This is a hack.  The profiler needs to be callback-based; the
        // snapshot is captured so that the profiler won't lose data.
        if (prof)
            ESC::snapshotProfile();
    }
 
    let after = new Date();
 
    if (files.length > 1) {
        print("");
        print("Total time: " + (after - before));
        print("Front end:  " + total_frontend);
        print("Back end:   " + total_backend);
    }
 
    if (prof) {
        ESC::stopProfile();
        ESC::dumpProfile("esc.profile");
    }
}

[camus3]

il va falloir que Microsoft change sa politique en matière de navigateurs , que les clients puissent upgrader leur navigateurs quelque soit l'os utilisé ( I installer I.E X sous Xp par exemple ) .c'est un frein à l'adoption des nouvelles specs du web. Microsoft a une politique ambiguë à propos des "standards".

[Neko]

Oui enfin XP n'est plus qu'en support étendu, ça fait un moment qu'ils l'ont annoncé qu'ils ne supportaient plus XP. Tôt ou tard faudra que les gens changent quand même.

[camus3]

Oui enfin XP n'est plus qu'en support étendu, ça fait un moment qu'ils l'ont annoncé qu'ils ne supportaient plus XP. Tôt ou tard faudra que les gens changent quand même.

et alors ? les gens changent d'os uniquement quand ils changent de pc , et cela n'empeche en rien Microsoft de sortir une version d'IE 9 ou 10 pour XP.
Je n'acheterai pas pas W8. je ne pourrai donc pas utilisé IE 10 ? je ne vois pas pourquoi je devrai racheter windows pour upgrader mon navigateur , c'est un choix purement commercial et pas du tout technique qui frêne l'adoptions des standards tant loués par les "évangélistes". Microsoft n'en a rien à faire de "promouvoir" les standards , c'est juste du marketing. L'api javascript de Metro par exemple est non standard , Ecmascript 5 dans IE9 n'est pas standard non plus puisqu'il ne propose pas de strictmode.

[damo]

C'est bien maigre tout ça, en tout cas bien insuffisant pour considérer JavaScript à la hauteur d'un langage moderne comme Java, .Net, Python, AS3, etc...

[ithel]

Que nous réserve le futur de JavaScript ?

Du sang, de la sueur et des larmes (désolé, trop tentant)

[ugo-sans-h]

De maigres évolution de forme, toujours pas d'objet avec js...

Plus j'utilise Javascript plus je suis frustré. Je suis frustré de voir que ce langage est de plus en plus incontournable et pourtant si peu structuré et hasardeux. La qualité d'une application ne dépend que de l'assiduité du développeur, et est difficile de lui faire confiance dans ces conditions.

Un langage souple et laissant une grande liberté aux développeurs c'est bien, mais de grande applications complexes avec plusieurs milliers de lignes de cote, ne serais-ce que pour des questions de maintenabilité, nécessite quand même une conception plus structuré.

Quand je vois Dart de Google, je ne sais quoi penser. Certes il est jeune et ne sera pas supporté dès demain par tout les navigateurs. Mais il a la volonté de faire bouger les lignes. Et comme dit plus haut, cette nouvelle version de js ne sera de toute façon pas supporté par tous les navigateurs avant des années...

Commencer dès à présent à développer côté client dans un autre langage que le js pour l'avenir n'est peut être pas exclu, de toute façon, les deux mettrons des années à être supporté par tout et tout le monde.

[Bovino]

Envoyé par ugo-sans-h

toujours pas d'objet avec js...

Euh... tu plaisantes j'espère

[ugo-sans-h]

Non, pas du tout, du pseudo objet c'est pas de l'objet.

Des fonctions, un jour fonction, un jour class[...] des {} en guise je json ou de class... n'est le bordel si j'ose dire...

[Camille_B]

Javascript est un langage objet.

Point final.

Un langage objet à prototype et non un langage objet à classes.

Y a pas que le modèle C++/Java dans le monde de l'objet hein !

Allez jeter un oeil sur CLOS le système objet de Common Lisp, ou alors le système objet Moose pour Perl, ça permet de se nettoyer un peu le cerveau.

[w3ar3dus1]

Ce n'est qu'un avant goût, il y a bien d'autres évolutions à venir, la communauté de l'ECMA fait un gros travail actuellement.

Envoyé par ugo-sans-h
… et pourtant si peu structuré et hasardeux. La qualité d'une application ne dépend que de l'assiduité du développeur …

Ça m'a pas l'air sérieux ça, tu compte sur la syntaxe d'un language pour structurer tes apps ? ne sait tu pas ce qu'est un patron de conception ? De part mon experience, la plupart des personnes qui tiennent un discours comme le tien, ugo, ne maitrisent pas réellement JavaScript et encore moins les patrons qui lui sont appropriés. Dis toi bien que JavaScript est différent des languages dits conventionnels, il faut donc le comprendre. Le fait qu'il n'ai pas (encore) [1] de mot clés class, extends, … ne veut pas dire que ce n'est pas un language objet, c'est absurde de dire ça, il exploite juste un modèle différent, l'héritage prototypal.

Dans n'importe quel language si tu ne maitrise pas les patrons de conception et comment les lui appliquer, tu ne peut te targuer de le maitriser.

Alors oui je suis d'accord, une part énorme de ceux qui se disent développeur JavaScript ne le sont pas réellement – juste parce qu'un mec s'amuse à déclarer 2-3 évènement ou mets en place des validation sur ses forms ne fait pas de lui un dev JS – mais c'est pas une excuse.

Dart n'est que de la poudre aux yeux pour les "haters" qui ne comprennent pas l'héritage prototypal et tout ce qui va avec, c'est juste une nouvelle tentative de control de Google, car d'après tous ce qu'on en voit jusqu'ici à part le typage statique et quelques pirouettes syntaxiques les futures versions d'ECMA qui se dessines n'ont rien à lui envier (sans compter le fait que Google a fait son coup dans le dos de tous les copains).

Si tu veut faire de larges apps JavaScript, met tes préjugés de côté et étudie le de fond en comble. Le blog d'Addy Osmany, entre autres t'y aidera.

Mon avis perso et que JavaScript bénéficie d'un retour sur experience qui lui permettra de devenir un language plus solide que Dart (et je ne parle même pas des problèmes d'implémentations).

[1] Une des propositions pour les classes JS de Brendan Eich

[chok371]

Javascript est un langage objet

Exact, mais sa gestion des objets est trop pauvre et incomplète pour travailler sur de gros projets avec efficacité (par exemple développer un Jeu).

[w3ar3dus1]

@chok371 Est tu un guru du JavaScript pour dire ça ? Connait tu réellement l'état des évolutions ? Tes propos sont totalement improductifs franchement. JavaScript a ses bon cotés et est un language puissant si on le maitrise réellement.

Bref je voulait quand même dire que certaines évolutions sont appréciables quand même, le scoping de bloc et lexical, l'assignement déstructuré. Un système de module uniforme amènera du bon dans la standardisation de la structure des applis je pense, ça gommera par exemple certaines différences d'implémentation de l'AMD, mise à part que le chargement asynchrone se fera encore au niveau de la balise script si je ne m'abuse.

[lilington]

Envoyé par chok371

Exact, mais sa gestion des objets est trop pauvre et incomplète pour travailler sur de gros projets avec efficacité (par exemple développer un Jeu).

Qui a dit que pour faire des jeux il fallait de l'objet?
Je comprend pas pourquoi beaucoup de gens pense que Objet=bien, procedural=has been.

c'est deux approches differente. Je sais je suis dans la pensee de Linus T. qui deteste l'objet sauf que moi je ne deteste pas l'objet mais ceux qui pense que l'objet c'est mieux, l'objet c'est obligatoire pour bien faire.
bref tout ca pour dire que l'argument

Code :

JS n'est meme pas objet

pour le denigrer est totalement ridicule qu'il soit objet ou non, ca demontre juste qu'on a affaire a un programmeur du dimanche bourre de certitudes et qui pense que ce que lui il utilise c'est mieux que ce que les autres utilises.

fin du coup de gueule.

[Grimly]

Certaines choses assez sales, d'autres plutôt pas mal.

La mort de arguments ... enfin une modif dont on avait besoin !
J'ai très peur de ce que peuvent donner les "yield" ...

Je reste un peu plus séduit par dart que cette suite du pour js.

[Camille_B]

Généralement les personnes qui jugent un langage à sa capacité à gérer l'objet (et encore qu'un seul modèle objet !), ne maîtrisent même pas vraiment la programmation orientée objet.

Ils sont tellement content d'avoir réussi à assimiler la chose qu'ils s'enorgueillissent et se font un plaisir de bêtement taper sur tout ce qui ne ressemble à ce qu'ils ont peiné à apprendre.

Ce serait reconnaître qu'ils ne savent rien, et que tout est toujours à réapprendre.

C'est vrai pour tout, et ça l'est vraiment pour l'informatique.

Javascript est un langage OO, je le répète, et son modèle objet est vraiment puissant.

Mais il n'est pas que cela. La vraie force de Javascript c'est son modèle de fonctions proche de Scheme.

Le principal défaut de Javascript, au fond, c'est d'avoir voulu faire un Scheme pour programmeur C du dimanche. Un Scheme habillé en C quoi, avec deux trois trucs sensés faciliter la vie du développeur débutant qui compliquent plus les choses qu'autre chose.

Mais, au fond, c'est globalement un très très bon langage. Ses qualités surpassent largement ses défauts.

[Camille_B]

Personnellement Dart ne me séduit pas plus que ça. En fait, aucun remplaçant pour le web ne me séduit vraiment.

Non que les remplaçants soient mauvais, certains sont très bons (ClojureScript est vraiment sympa par exemple), mais au final on aura toujours à faire à javascript.

Alors il vaut mieux, dans un premier temps, bien connaître javascript, quitte, plus tard, à utiliser par-ci par-là un "remplaçant".

[lilington]

Envoyé par Camille_B

Ils sont tellement content d'avoir réussi à assimiler la chose qu'ils s'enorgueillissent et se font un plaisir de bêtement taper sur tout ce qui ne ressemble à ce qu'ils ont peiné à apprendre.

Le problemme c'est que ce que tu dis est un cas general de l'humain. Et pis on est meme capable de tuer pour forcer les gens a faire comme nous. ex: les guerres de religions pour convertir les mecreants, la democratie forcee(ou plus generalement imposition de systeme polique a ceux qui ont des systemes different ).
moins meutrier on a Mac c'est mieux que windows ou linux. si tu utilises pas c'est que tu connais rien, on peut permutter Mac ,windows et linux au choix (ou meme mettre android et IOS).
Et en ce qui nous concerne on a Java c'est mieux que C. Objet c'est bien sans objet c'est depasse... j'en passe.
c'est juste humain et je l'avoue je suis passe par la. donc je suis encore humain.

sinon pour js, j'ai jamais vraiment compris pourquoi on le denigre, bon c'est vrai que je n'ai pas fait d'application immense mais bon j'ai jete un coup d'oeil sur le code de extjs (un peu hein) et je vois pas trop pourquoi on dit que c'est pas objet