Propositions TC39 en 2026 : explication des décorateurs, des temporels et des signaux

Début des années 1990, les sceptiques ont déclaré à peu près une fois par an que JavaScript était « terminé », et à chaque fois, le langage a prouvé qu’ils se trompaient. Le TC39, le comité qui guide l’évolution d’ECMAScript, continue tranquillement de faire avancer des propositions qui transforment la manière dont on écrit du code au quotidien.

Si vous développez avec JavaScript full-stack, React ou Next.js, quelques propositions actuellement en cours de traitement méritent d’être suivies de près. Aucune d’entre elles n’est une fonctionnalité spectaculaire — ce sont plutôt des changements qui éliminent discrètement le code générique que vous avez écrit sans jamais y réfléchir pendant des années.

Voici les trois à surveiller.

1. Les décorateurs natifs sont presque là

Les développeurs TypeScript ont passé des années à compter sur les décorateurs grâce au paramètre de compilateur experimentalDecorators. Cette solution de fortune est sur le point d’être abandonnée. La proposition standardisée concernant les décorateurs est arrivée à la phase 3, ce qui signifie que les navigateurs et les environnements d’exécution JavaScript développent déjà des implémentations réelles de cette fonctionnalité.

// before: relying on experimentalDecorators + reflect-metadata
class UserService {
  @logCall
  fetchUser(id: string) {
    return api.get(`/users/${id}`);
  }
}

La spécification mise à jour abandonne l’ancien design basé sur reflect-metadata au profit de quelque chose de plus prévisible : une fonction décorateur reçoit désormais la valeur qu’elle décore ainsi qu’un objet de contexte la décrivant, et elle peut retourner une valeur de remplacement. Si vous avez déjà eu affaire à des versions incompatibles entre l’implémentation des décorateurs de Babel et celle de TypeScript, cette convergence est véritablement une bonne nouvelle.

En résumé : si votre framework de prédilection — l’injection de dépendances au style Angular, MobX ou des patterns proches de NestJS — repose sur des décorateurs, vous pouvez vous attendre à moins de problèmes liés aux flags du compilateur dans les versions futures.

2. Temporal est presque prêt pour le déploiement

L’objet Date intégré à JavaScript est une source de frustration depuis près de trois décennies. Il manque d’immutabilité, gère les fuseaux horaires de manière confusive et expose des méthodes mutantes qui posent problème même aux ingénieurs expérimentés. Temporal, une proposition soutenue de longue date par des contributeurs de Mozilla et d’autres parties prenantes, est maintenant arrivée à son stade final et devrait faire partie d’une future édition d’ECMAScript.

const meeting = Temporal.ZonedDateTime.from(
  "2026-09-14T10:00:00[America/New_York]"
);
const inTokyo = meeting.withTimeZone("Asia/Tokyo");

Avec Temporal, vous obtenez des dates et heures correctement gérées en fonction des fuseaux horaires sans avoir recours à une bibliothèque comme moment.js, et des conversions telles que le décalage d’une heure de réunion vers un autre fuseau deviennent simples, au lieu d’exiger des calculs manuels complexes. Si vous développez des fonctionnalités de planification au sein d’une application Next.js, il s’agit sans doute de la plus grande amélioration en termes de qualité de vie apportée à ce langage.

3. Signals : un standard pour l’état réactif

useState de React, ref de Vue et les signals de Solid sont toutes des solutions différentes au même problème fondamental : suivre des valeurs qui changent dans le temps et réagir à ces changements. La proposition Signals du TC39 vise à fournir à JavaScript une primitive réactive native sur laquelle les frameworks peuvent s’appuyer, plutôt que chaque écosystème d’inventer sa propre version de ce même mécanisme.

Cette proposition en est encore à un stade précoce, mais la direction qu’elle indique — jeu de mots intentionnel — est claire : moins de logiques de réactivité redondantes dans Redux, React et d’autres bibliothèques de gestion d’état, et davantage de blocs de construction partagés et réutilisables en dessous d’elles.

Qu’est-ce que cela signifie pour votre stack

• Les avantages de TypeScript arriveront en premier. Des définitions de types plus propres et standardisées pour les décorateurs ainsi que pour Temporal se répercuteront vers les outils que vous utilisez déjà.
• Votre couche d’interface utilisateur et votre configuration de stylisation, y compris des outils comme Tailwind CSS, ne seront pas directement affectés, mais une gestion plus rapide et fiable des dates/heures signifie moins de code utilitaire personnalisé encombrant vos composants.
• Même avant que les bibliothèques côté client n’adoptent pleinement Temporal, les composants serveur de Next.js constituent un terrain d’essai probable pour celui-ci, en particulier pour le formatage des dates côté serveur.

Rob Palmer, coprésident du TC39, a indiqué dans les mises à jour du comité qu’il est désormais courant que plusieurs propositions avancent au cours du même cycle de réunion. Ce schéma suggère que le rythme d’évolution du langage s’est réellement accéléré au cours des dernières années.

Pensée finale

Rien de tout cela ne modifie le JavaScript que vous utilisez actuellement. Mais la prochaine fois que vous aurez instinctivement recours à moment.js ou que vous ferez face à des problèmes avec un polyfill de décorateur, rappelez-vous qu’une solution native est déjà en cours d’élaboration. Être une ou deux propositions devant la tendance permet aux développeurs expérimentés d’éviter de se mettre dans l’impasse — et c’est aussi la raison pour laquelle beaucoup d’entre eux s’opposent à l’adoption de patterns qui créeraient une dette technique avant même que ces propositions ne soient finalisées.