Quelles sont les nouvelles fonctionnalités qui pourraient débarquer dans JavaScript en 2019 ?
Un tour d'horizon des candidats pour ES2019

Le , par Michael Guilloux

122PARTAGES

13  0 
JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives, mais aussi pour les serveurs avec l'utilisation par exemple de Node.js. C'est un langage orienté objet à prototype et qui supporte le paradigme objet, impératif et fonctionnel. Il a été standardisé sous le nom d'ECMAScript en juin 1997 par Ecma International dans le standard ECMA-262. JavaScript n'est depuis qu'une implémentation d'ECMAScript (ES), celle mise en œuvre par la fondation Mozilla.

Au cours des dernières années, JavaScript a évolué à un rythme soutenu avec de nouvelles fonctionnalités de langage apportées à la spécification ECMAScript suivant un processus normalisé avec 5 étapes de maturité : idée (étape 0), proposition formelle (étape 1), brouillon (étape 2), candidat (étape 3) et approuvé (étape 4).

Le groupe Ecma International qui examine et adopte les modifications apportées aux spécifications du langage est le Technical Committee 39, ou TC39. Il travaille actuellement sur les nouvelles fonctionnalités à intégrer à ES2019. Pour le moment, aucune nouvelle fonctionnalité n'a atteint l'étape 4, mais quelques-unes sont déjà candidates pour la spécification ES2019, c'est-à-dire à l'étape 3. Ce qui permet donc de se faire une idée plus ou moins juste des fonctionnalités de langage qui pourraient débarquer dans JavaScript cette année. Et David Neal, Senior Developer Advocate chez Okta et spécialiste de la communauté JavaScript (y compris Node.js et les frameworks front-end populaires tels que React et Vue), a pris soin de les répertorier pour nous.


Modifications apportées aux classes JavaScript

Un certain nombre de modifications ont été proposées aux classes, notamment les déclarations de champ, les méthodes et champs privés et les méthodes et champs statiques. Voici un exemple de ce à quoi ces changements pourraient ressembler.

Code JavaScript : Sélectionner tout
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
  
class Truck extends Automobile { 
  model = "Heavy Duty"; // public field declaration 
  #numberOfSeats = 5; // private field declaration 
  #isCrewCab = true; 
  static #name = "Truck"; // static private field declaration 
  
  // static method 
  static formattedName() { 
    // Notice that the Truck class name is used 
    // to access the static field instead of "this" 
    return `This vehicle is a ${ Truck.#name }.`; 
  } 
  constructor( model, seats = 2 ) { 
    super(); 
    this.seats = seats; 
  } 
  
  // Private method 
  #getBodyType() { 
    return this.#isCrewCab ? "Crew Cab" : "Standard Cab"; 
  } 
  bodyType() { 
    return `${ this.#numberOfSeats }-passenger ${ this.model } ${ this.#getBodyType() }`; 
  } 
  get seats() { return this.#numberOfSeats; } 
  set seats( value ) { 
    if ( value >= 1 && value < 7 ) { 
      this.#numberOfSeats = value; 
      this.#isCrewCab = value > 3; 
    } 
  } 
}

Pour sa part, David Neal n’aime pas le fait que la syntaxe hash (#) soit utilisée pour les membres privés. Il dit qu'il aurait préféré que la spécification du langage JavaScript adopte le mot-clé private à cette fin, comme dans les autres langages.

Méthodes trimStart() et trimEnd() pour le type String

Le type String type a une méthode trim() qui supprime les blancs à la fois au début et à la fin d'une chaîne de caractères. Les nouvelles méthodes trimStart() et trimEnd() proposées pourraient apporter plus de contrôle sur la suppression d'espace vide.

La méthode trimStart() permet de retirer les blancs au début de la chaîne de caractères. trimLeft() est un synonyme pour cette méthode.

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
  
var str = "   toto  "; 
console.log(str.length); // 8 
str = str.trimStart(); 
console.log(str.length); // 5 
console.log(str);        // "toto  "

De la même manière, la méthode trimEnd() permet de retirer les blancs situés à la fin d'une chaîne de caractères. trimRight() est un synonyme pour cette méthode.

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
  
var str = "   toto  "; 
console.log(str.length); // 9 
str = str.trimEnd(); 
console.log(str.length); // 7 
console.log(str);        // "   toto"

Ci-dessous, un exemple combinant trimStart et trimEnd :

Code JavaScript : Sélectionner tout
1
2
3
4
  
const one = "      hello and let "; 
const two = "us begin.        "; 
console.log( one.trimStart() + two.trimEnd() ) // "hello and let us begin."

trimStart et trimEnd ne modifient pas la chaîne elle-même. L'intérêt de cette fonctionnalité de langage est qu'elle est déjà implémentée dans un certain nombre de moteurs JavaScript. C'est l'un des nombreux cas où les navigateurs aident à faire avancer le langage.

Les grands nombres avec BigInt

BigInt est un objet natif qui permet de représenter des nombres entiers supérieurs à 253 (la plus grande valeur entière qui puisse être représentée par le type Number). Un objet BigInt est créé en ajoutant un n à la fin d'un littéral d'entier — 10n par exemple — ou en appelant la fonction BigInt().

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
  
const plusGrandEntier = 9007199254740991n; 
const grandNombre = BigInt(9007199254740991); 
// &#8618; 9007199254740991n 
  
const grandNombreEnChaîne = BigInt('9007199254740991'); 
// &#8618; 9007199254740991n 
  
const grandeNombreHexa = BigInt("0x1fffffffffffff"); 
// &#8618; 9007199254740991n 
  
const grandeNombreBinaire = BigInt("0b11111111111111111111111111111111111111111111111111111"); 
// &#8618; 9007199254740991n

Tableaux plats avec flat() et flatMap()

La méthode flat() permet de créer un nouveau tableau contenant les éléments des sous-tableaux du tableau passé en argument, qui sont concaténés récursivement pour atteindre une profondeur donnée. Dans les exemples ci-dessous, on aplatit des tableaux imbriqués avec flat().

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
  
var arr1 = [1, 2, [3, 4]]; 
arr1.flat();  
// [1, 2, 3, 4] 
  
var arr2 = [1, 2, [3, 4, [5, 6]]]; 
arr2.flat(); 
// [1, 2, 3, 4, [5, 6]] 
  
var arr3 = [1, 2, [3, 4, [5, 6]]]; 
arr3.flat(2); 
// [1, 2, 3, 4, 5, 6]

La méthode flat() permet également de retirer les « trous » d'un tableau :

Code JavaScript : Sélectionner tout
1
2
3
4
  
var arr4 = [1, 2, , 4, 5]; 
arr4.flat(); 
// [1, 2, 4, 5]

La méthode flatMap() permet d'appliquer une fonction à chaque élément du tableau puis d'aplatir le résultat en un tableau. Cela correspond à l'enchaînement de Array.prototype.map() suivi de Array.prototype.flat() de profondeur 1. flatMap est plus efficace que la combinaison de ces deux opérations, souvent réalisées conjointement.

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
  
var arr1 = [1, 2, 3, 4]; 
arr1.map(x => [x * 2]);  
// [[2], [4], [6], [8]] 
  
arr1.flatMap(x => [x * 2]); 
// [2, 4, 6, 8] 
  
// seul un niveau est aplati 
arr1.flatMap(x => [[x * 2]]); 
// [[2], [4], [6], [8]]

On peut utiliser un autre exemple où on génère une liste de mots à partir d'une liste de phrases :

Code JavaScript : Sélectionner tout
1
2
3
4
5
6
7
  
let tableau1 = ["Coucou comment", "", "ça va ?"]; 
tableau1.map(x => x.split(" ")); 
// [["Coucou", "comment"], [""], ["ça", "va", "?"]] 
  
tableau1.flatMap(x => x.split(" ")); 
// ["Coucou", "comment", "", "ça", "va", "?"]


Autres fonctionnalités candidates

Parmi les autres fonctionnalités candidates (étape 3), on peut noter :
  • globalThis, qui offre un mécanisme universel d'accéder à l'objet global même dans des fonctions strict ou des modules, quelle que soit la plateforme ;
  • import() dynamique ;
  • des fonctionnalités RegExp legacy ;
  • l'objet import.meta, une métapropriété qui expose des métadonnées d'un module JavaScript spécifiques au contexte. Cet objet contient des informations à propos du module, telles que l'URL du module ;
  • matchAll() pour le type String ;
  • Object.fromEntries(), une nouvelle méthode statique pour transformer une liste de paires clé-valeur en un objet ;
  • une proposition visant à empêcher JSON.stringify de retourner des chaînes mal formées ; et
  • hashbang (#!) pour les applications CLI.

Depuis quelques années, le TC39 a régulièrement publié de nouvelles éditions de la spécification de langage ECMAScript en juin. Il est donc très probable que la spécification ES2019 soit publiée en juin 2019. Pour ceux qui veulent expérimenter ces fonctionnalités de langage candidates, certaines sont déjà disponibles dans les moteurs et les utilitaires JavaScript. Ces nouvelles fonctionnalités sont parfois désactivées par défaut, mais peuvent être configurées pour être utilisées. Vous pourrez notamment les tester avec la dernière version de Node.js ou avec Babel 7.0+.

Rappelons que jusqu'à ce qu'une fonctionnalité de langage atteigne l'étape 4, rien ne garantit qu'elle fera partie de la spécification officielle d'ECMAScript. Toutefois, les implémentations de moteur JavaScript, telles que V8 (utilisée par Chrome et Node.js) et SpiderMonkey de Firefox, peuvent ajouter une prise en charge expérimentale des fonctionnalités proposées avant d’atteindre la phase 4, afin que les développeurs puissent tester et fournir des commentaires.

Sources : David Neal, Mozilla MDN (pour la plupart des exemples de code)

Et vous ?

Que pensez-vous des fonctionnalités candidates pour la spécification ES2019 ?
Lesquelles appréciez-vous le plus ou le moins ? Et pourquoi ?
Avez-vous repéré d'autres fonctionnalités candidates ES2019 ? Si oui, lesquelles ?
Quelles fonctionnalités présentes dans d'autres langages ou pas attendiez-vous pour la prochaine version de JavaScript ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 23/01/2019 à 6:50
Pour sa part, David Neal n’aime pas le fait que la syntaxe hash (#) soit utilisée pour les membres privés. Il dit qu'il aurait préféré que la spécification du langage JavaScript adopte le mot-clé private à cette fin, comme dans les autres langages.
En effet... il y a toujours eu chez JavaScript cette politique du comment faire simple quand on peut avoir une syntaxe bizarre difficilement compréhensible pour une personne extérieure au langage.
Avatar de Mrsky
Membre éprouvé https://www.developpez.com
Le 23/01/2019 à 7:00
On repart déjà pour 4 pages de Sodium VS JavaScript ou on attend trolldi?
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 23/01/2019 à 7:14
Citation Envoyé par Mrsky Voir le message
On repart déjà pour 4 pages de Sodium VS JavaScript ou on attend trolldi?
Boah non, déclarations de champs, méthodes et champs privés... ça commence à ressembler à un vrai langage, je n'ai pas trop à critiquer pour une fois
Avatar de Beginner.
Membre chevronné https://www.developpez.com
Le 23/01/2019 à 8:53
Citation Envoyé par Sodium Voir le message
En effet... il y a toujours eu chez JavaScript cette politique du comment faire simple quand on peut avoir une syntaxe bizarre difficilement compréhensible pour une personne extérieure au langage.
Oui le mot clé "private" serait plus clair/lisible pour l'utilisateur mais je crois que c'est plus difficile à prendre en compte coté outils d'assistance...

Par exemple un IDE lors d'une auto-complétion pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée), il n'y aurait pas besoin par exemple d'avoir un tokeniser/parser qui tienne compte du mot clé "private"...
Avatar de psancho
Futur Membre du Club https://www.developpez.com
Le 23/01/2019 à 9:22
je trouve, au contraire de mes camarades, la notation # plutôt intelligente: avec un seul caractère, on identifie tout de suite la portée de la variable où qu'elle soit utilisée. Nul besoin de convention d'écriture. D'autre part, ça rend la déclaration moins verbeuse.
Avatar de grunk
Modérateur https://www.developpez.com
Le 23/01/2019 à 9:41
Citation Envoyé par Beginner. Voir le message
Oui le mot clé "private" serait plus clair/lisible pour l'utilisateur mais je crois que c'est plus difficile à prendre en compte coté outils d'assistance...

Par exemple un IDE lors d'une auto-complétion pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée), il n'y aurait pas besoin par exemple d'avoir un tokeniser/parser qui tienne compte du mot clé "private"...
N'importe quel ide sait déjà gérer les mots clé de visibilité dans tous les autre langages.
Cela à encore moins de sens qu'il utilise le mot clé static.
Quitte à vouloir faire originale , autant être consistent dans les idées à la con
Code : Sélectionner tout
1
2
#variable_privee;
@variable_static;
Typescript propose plein de chose intéressante , il ferait bien de s'en inspirer un peu.

Citation Envoyé par psancho Voir le message
je trouve, au contraire de mes camarades, la notation # plutôt intelligente: avec un seul caractère, on identifie tout de suite la portée de la variable où qu'elle soit utilisée. Nul besoin de convention d'écriture. D'autre part, ça rend la déclaration moins verbeuse.
Perso je préfère écrire private une fois que devoir me traîner un # sur toutes les utilisations de la variable , ce qui, à mon sens , est autrement plus lourd.

Les conventions d'écriture sur les visibilités ou les types c'était bien y'a 15 ans quand les ide n'était pas au niveau où il sont maintenant. Ça fait un paquet d'années que je préfixe plus mes variables et ça ne m'a jamais poser le moindre problème , justement parce que les ide sont capables de gérer tout ça correctement à ma place.
Avatar de Beginner.
Membre chevronné https://www.developpez.com
Le 23/01/2019 à 9:54
Citation Envoyé par grunk Voir le message
N'importe quel ide sait déjà gérer les mots clé de visibilité dans tous les autre langages.
Comme tu dis toi-même : "dans tous les autre langages" mais là on parle de JS et les outils pour JS ne prennent pas (encore) en compte le mot clé "private"...

Faire évoluer ces outils est quand même plus difficile que de faire ce que je disais à savoir : Lors d'une auto-complétion un IDE pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée).

Les outils pour les autres langages ne peuvent pas servir pour JS mais si quelqu'un pense le contraire cela m’intéresse qu'on m'explique comment on peut faire ça...
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 23/01/2019 à 10:24
Citation Envoyé par Beginner. Voir le message
Comme tu dis toi-même : "dans tous les autre langages" mais là on parle de JS et les outils pour JS ne prennent pas (encore) en compte le mot clé "private"... .
Eh bien il faut faire évoluer les outils plutôt que de faire régresser le langage...
Avatar de grunk
Modérateur https://www.developpez.com
Le 23/01/2019 à 10:59
Citation Envoyé par Beginner. Voir le message
Comme tu dis toi-même : "dans tous les autre langages" mais là on parle de JS et les outils pour JS ne prennent pas (encore) en compte le mot clé "private"...
Des ide comme webstorm ou vscode le gère déjà avec typescript. Ils devrait être capable de s'en sortir avec du JS

Faire évoluer ces outils est quand même plus difficile que de faire ce que je disais à savoir : Lors d'une auto-complétion un IDE pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée).
Pour faire se filtrage , il va falloir dans tous les cas une màj de l'ide.
Et puis comme il vont supporter le mot clé static , il pourrait très bien supporter private en même temps.

Y'a peut être une vraie bonne raison derrière ce choix , mais faciliter la vie aux ide n'en est pas une.
Avatar de Beginner.
Membre chevronné https://www.developpez.com
Le 23/01/2019 à 11:03
Citation Envoyé par Sodium Voir le message
Eh bien il faut faire évoluer les outils plutôt que de faire régresser le langage...
Ce n'est pas si simple... Qui va le faire ? Et est-ce que cela sera gratuit et open source ?

Bon je pense que ceux qui travaillent sur TypeScript le feront peut-être, les outils pour TS fonctionnent aussi pour JS, j'ai d'ailleurs testé tsserver mais franchement ce n'est pas facile à utiliser car la documentation est rare, j'ai dû regarder l'intégration faite par d'autres pour essayer de comprendre...

Sur certains points je trouve que tern est plus efficace que tsserver mais hélas tern n'est plus maintenu par son auteur mais peut-être qu'il fera quand même évoluer le parseur Acorn (dont il est aussi l'auteur)...
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web