JavaScript ES2025 : les nouvelles features qui vont (peut-être) changer notre quotidien de dev

Mardi 7h23, café en main, j’ouvre VS Code. Notification GitHub : « ES2025 features available in preview ». Curiosité piquée.

Imaginez : vous êtes en train de débugger un switch dégueulasse avec 15 cases, vous maudissez JavaScript pour la énième fois, et là… ES2025 débarque avec du pattern matching natif. Coïncidence ? Je ne crois pas.

C’est quoi EcmaScript ?

Concrètement, c’est la spécification technique maintenue par ECMA International qui dit « voici comment JavaScript doit fonctionner ». JavaScript est une implémentation de ce standard. Quand on parle d’ES2015 (ES6), ES2020, ES2025, on parle des versions annuelles d’ECMAScript qui ajoutent de nouvelles features au langage.

Cette année, notre langage préféré (ou détesté, selon les jours) nous sort des features qu’on n’osait plus espérer. Pas de marketing bullshit cette fois – j’ai passé quelques soirées à tester ces nouveautés sur mes projets perso, et il faut qu’on en parle.

Entre trucs qui changent vraiment la donne et gadgets sympas mais pas essentiels, ES2025 dessine le JavaScript qu’on utilisera demain. Spoiler : c’est pas révolutionnaire, mais c’est malin.

Pattern matching : enfin un switch qui a du sens

Le Pattern Matching, actuellement en Stage 2 de la proposition TC39, arrive, et c’est une petite révolution dans la manière dont on va gérer les conditions complexes. Fini les if/else interminables ou les switch bancals :

let user = { role: "admin" };

match (user) {
  { role: "admin" } => console.log("Welcome, Admin!"),
  { role: "guest" } => console.log("Hello, Guest!"),
  _ => console.log("User not found.")
}
Langage du code : JavaScript (javascript)

Bon, sur le papier c’est sexy. Dans les faits ? J’ai testé sur quelques cas d’usage, et c’est vrai que ça rend le code plus lisible pour des logiques complexes.

Mais attention au syndrome « nouveau jouet » – j’ai vu des devs remplacer des if simples par du pattern matching juste pour faire le malin.

Ça brille surtout sur des structures de données complexes où on doit matcher plusieurs critères. Pour du basique, un bon vieux if reste plus clair.

Records et tuples : l’immutabilité native (enfin !)

Là, on touche à quelque chose d’important. Des données immutables natives, sans passer par Immutable.js ou des libs tierces :

let person = #{ name: "Alex", age: 30 };
let numbers = #[1, 2, 3];

<em>// person.age = 31; // ❌ Erreur !</em>Langage du code : JavaScript (javascript)

Honnêtement, c’est une feature que j’attendais depuis longtemps. Plus de bugs foireux parce qu’un objet a été modifié par accident dans une fonction random.

J’ai testé ça sur des projets React, et la différence est notable : plus de problèmes de re-render intempestifs, des comparaisons d’état plus fiables.

Le petit hic ? La syntaxe avec les # va surprendre au début. Mais bon, on s’habitue.

Async context : garder ses données dans le chaos asynchrone

Celui-là, c’est pour résoudre un vrai problème qu’on a tous vécu – perdre le contexte dans des opérations async :

import { AsyncLocalStorage } from 'async_hooks';

const storage = new AsyncLocalStorage();

function logUser() {
  setTimeout(() => {
    console.log("User:", storage.getStore()); <em>// Le user est toujours là !</em>
  }, 1000);
}

storage.run("Alex", () => {
  logUser();
});Langage du code : JavaScript (javascript)

Pratique pour des logs, du tracing, ou garder des infos utilisateur à travers des chaînes d’appels async.

Par contre, ça demande un support de l’environnement (Node.js pour l’instant). Côté navigateur, c’est encore flou.

JSON modules : import direct sans chichis

Bon, celui-là c’est du quality-of-life pur :

import config from './config.json' with { type: 'json' };
console.log(config.theme); <em>// "dark"</em>Langage du code : JavaScript (javascript)

Fini les fetch() ou les require() pour charger un simple JSON. C’est bête, mais ça fluidifie le workflow.

Testé sur quelques projets Next.js, ça marche nickel. Un petit gain de temps qui fait plaisir au quotidien.

Pipeline operator : le chaînage qui a de la gueule

Le fameux |> arrive enfin. Pour chaîner des opérations sans s’emmêler les pinceaux :

<em>// Avant</em>
let result = double(square(addOne(3)));

<em>// Maintenant</em>
let result = 3 |> addOne |> square |> double;Langage du code : JavaScript (javascript)

C’est plus lisible, surtout sur des transformations de données complexes. J’ai testé sur du processing de formulaires, et c’est vrai que ça aide à suivre le flow.

Le truc ? Ça marche bien avec des fonctions pures, mais dès qu’on mélange avec des méthodes d’objets, ça devient moins évident.

Mes impressions perso : évolution, pas révolution

Après avoir gratté ces features sur quelques side projects, mon verdict ? C’est du solide, sans être transcendant.

Pattern matching et records/tuples apportent de vraies améliorations pour du code complexe. JSON modules et pipeline operator, c’est du confort.

Async context résout un vrai problème, mais il faut attendre le support navigateur pour que ça devienne vraiment utile.

Le point important : rien de cassant, pas de paradigm shift majeur. JavaScript continue de mûrir sans brusquer l’écosystème existant.

Pour nous, devs qui bossons sur des projets clients, c’est plutôt une bonne nouvelle. On pourra adopter ces features progressivement, sans révolution dans nos stacks.

Support et adoption : le vrai enjeu

Comme toujours avec les nouvelles features JS, la vraie question c’est : quand est-ce qu’on pourra les utiliser en prod ?

Les premiers supports commencent à arriver dans les engines récents. Babel propose déjà des transforms pour certaines features.

Mon conseil perso ? Tester sur des side projects, se faire la main, mais attendre un support stable avant de les introduire chez des clients.