Lors de la récente réunion du comité ECMA TC39, une proposition audacieuse a été mise sur la table : scinder JavaScript en deux langages distincts. Cette initiative, portée par Shu-yu Guo, ingénieur chez Google, envisage une version fondamentale et simplifiée, appelée JS0, et une variante plus sophistiquée, baptisée JSSugar, qui dépendrait d’outils de compilation. Une idée qui, à la manière d’une tempête sur un lac calme, a provoqué des vagues au sein de la communauté JavaScript.
JavaScript : une complexité devenue un frein ?
JavaScript, ou ECMAScript, est aujourd’hui l’épine dorsale du web moderne. Toutefois, son évolution rapide et l’ajout constant de nouvelles fonctionnalités posent des défis croissants en termes de sécurité, de performances et de stabilité.
Les auteurs de la proposition, qui incluent des collaborateurs de Mozilla, Apple, Sony et Moddable, ont souligné un constat dérangeant : la plupart des nouvelles fonctionnalités n’apportent que peu de bénéfices aux utilisateurs finaux. Elles compliquent les machines virtuelles JavaScript (VMs), augmentent le risque de vulnérabilités et freinent les performances.
Imaginez un couteau suisse dont la complexité finit par rendre chaque outil moins efficace. C’est ainsi qu’est perçue l’évolution de JavaScript par ces experts. Des exemples comme BigInt, conçu pour gérer de grands nombres mais peu adopté, ou Species, dont l’utilité est déjà remise en question par certains moteurs, illustrent ce problème.
JS0 : un retour aux fondamentaux
La pierre angulaire de cette proposition repose sur une vision minimaliste de JavaScript. La version JS0 viserait à simplifier les moteurs JavaScript en ne supportant que les fonctionnalités de base nécessaires à l’exécution des applications.
Objectifs principaux de JS0 :
- Sécurité renforcée : moins de complexité, moins de failles potentielles.
- Performances améliorées : les moteurs n’auraient plus à gérer des fonctionnalités rarement utilisées.
- Uniformité : en limitant les variations entre les implémentations des moteurs.
JS0 ne chercherait pas à réduire les capacités actuelles de JavaScript, mais à stabiliser son évolution future. Les nouvelles fonctionnalités syntaxiques, par exemple, ne seraient plus intégrées directement aux moteurs, mais déportées dans JSSugar.
JSSugar : l’allié des développeurs avancés
JSSugar, tel qu’imaginé dans cette proposition, serait un langage enrichi basé sur des outils de compilation comme TypeScript, Babel, ou Webpack. Ces outils, déjà omniprésents dans le workflow des développeurs, ajouteraient des fonctionnalités avancées avant de « traduire » le code en JS0 pour l’exécution.
Pourquoi JSSugar est-il nécessaire ?
Vous codez peut-être déjà en TypeScript ou utilisez des outils comme Babel pour profiter de fonctionnalités modernes tout en restant compatible avec des navigateurs plus anciens. JSSugar formaliserait cette approche, rendant la syntaxe avancée disponible uniquement via des outils standardisés.
Exemple d’utilisation avec JSSugar :
Un développeur pourrait écrire ceci dans JSSugar :
async function fetchData() {
const { data } = await api.call();
return data;
}Ce code serait compilé en JS0, réduisant ainsi la charge sur les moteurs d’exécution.
Un impact majeur sur l’écosystème JavaScript
Si ce changement est adopté, cela transformerait profondément la manière dont JavaScript évolue et est utilisé. Imaginez un fleuve qui se divise en deux cours : l’un, JS0, est simple et rapide ; l’autre, JSSugar, est complexe mais puissant. Ce modèle offrirait des avantages, mais il soulèverait également des défis.
Avantages :
- Moteurs plus légers : Les navigateurs et les environnements d’exécution comme Node.js pourraient se concentrer sur des fonctionnalités essentielles, améliorant ainsi la stabilité et les performances.
- Normes renforcées : Les outils de compilation comme Babel seraient d’avantage alignés sur des standards définis, réduisant les incohérences.
Inconvénients :
- Dépendance accrue aux outils : Certains développeurs craignent que cette approche ne rende les projets trop dépendants de l’écosystème de compilation, éloignant JavaScript de sa simplicité originelle.
- Barrière d’entrée : Pour les nouveaux développeurs, apprendre et configurer ces outils pourrait devenir un obstacle.
Des réactions contrastées dans la communauté
La proposition a rapidement divisé la communauté. Certains applaudissent l’idée de prioriser la sécurité et les performances, tandis que d’autres y voient une menace pour la philosophie « Vanilla JS » qui valorise JavaScript sans dépendances.
Un développeur a résumé cette inquiétude avec une formule percutante : « RIP Vanilla JS ». Cette phrase reflète une peur répandue : perdre un JavaScript simple, accessible à tous, sans outils intermédiaires. D’autres, plus optimistes, soulignent que cette division pourrait encourager une collaboration accrue entre les développeurs d’outils et les créateurs de standards.
Les enjeux techniques et organisationnels
Pour que ce modèle fonctionne, il faudrait un alignement entre les créateurs de moteurs, comme V8 (utilisé par Chrome) et SpiderMonkey (utilisé par Firefox), et les développeurs d’outils. Une idée évoquée est de créer un nouveau groupe technique, distinct de TC39, pour gérer JSSugar. Ce groupe pourrait définir des standards pour les outils de compilation, garantissant une compatibilité et une stabilité accrues.
Un pari risqué mais nécessaire pour l’avenir ?
Ce débat sur la scission de JavaScript reflète des tensions plus larges dans le développement logiciel : le besoin de simplifier les bases tout en répondant aux exigences croissantes des applications modernes. Vous, en tant que développeur ou utilisateur, serez au cœur de cette transformation, qu’il s’agisse d’adopter ces nouvelles pratiques ou d’observer comment l’écosystème réagit à cette proposition audacieuse.
