- Un ingénieur de Google a présenté au comité officiel de normalisation une proposition visant à scinder JavaScript en deux langages
- Il propose de le diviser entre un noyau implémenté dans les moteurs d’exécution et une variante dotée de davantage de fonctionnalités, reposant sur des outils chargés de la compiler
- La présentation a eu lieu plus tôt ce mois-ci lors d’une réunion de l’Ecma TC39
- TC39 est le comité d’Ecma International chargé de faire évoluer la spécification de JavaScript (officiellement ECMAScript)
- La présentation a été faite par Shu-yu Guo de Google, qui a rédigé les slides avec des co-auteurs de Mozilla, Apple, Moddable et Sony
- Shu-yu est spécialiste des JIT, VM, compilateurs et de la normalisation
- Les arguments des auteurs
- Les nouvelles fonctionnalités du langage dégradent presque toujours la sécurité, tout en ayant un effet neutre ou négatif sur les performances
- La fiabilité se dégrade parfois, et les fonctionnalités des applications ne s’améliorent que si les développeurs utilisent réellement ces nouvelles capacités
- Les VM JavaScript (machines virtuelles) sont déjà devenues très complexes sous la pression de la vitesse, ce qui compromet la sécurité. Cela paraît en outre particulièrement injustifié lorsque les nouvelles fonctionnalités ne sont pas adoptées
- Les failles de sécurité et le « coût de complexité » du runtime affectent des milliards d’utilisations, alors que les bénéfices sont en pratique limités aux développeurs et applications qui exploitent réellement cette complexité ; la technologie de base de JavaScript devrait donc rester simple
- Même si plusieurs organisations participent, cette initiative semble dans une certaine mesure pilotée par Google
- L’une des slides contient une clause de non-responsabilité indiquant que « cette solution possible est la solution privilégiée par Google et n’est pas nécessairement celle des autres implémenteurs »
- La solution proposée
- Il ne s’agit pas de revenir sur les fonctionnalités existantes, mais de changer d’approche afin que, à l’avenir, la plupart des nouvelles fonctionnalités soient implémentées par les outils plutôt que par les moteurs
- Le langage implémenté dans les moteurs serait appelé « JS0 », et celui implémenté par les outils « JSSugar »
- C’est une idée particulièrement adaptée à JavaScript, car de nombreux développeurs codent déjà en TypeScript et s’appuient sur des compilateurs comme Babel, Webpack et le compilateur TypeScript
- Si cette approche était adoptée, les futures fonctionnalités syntaxiques iraient dans JSSugar, tandis que seules les API et fonctionnalités fonctionnelles iraient dans JS0
- Un moteur compatible n’aurait besoin de prendre en charge que JS0
- La charge serait reportée sur les implémenteurs d’outils pour assurer la prise en charge de JSSugar
- Effet secondaire : les implémenteurs d’outils devraient davantage s’impliquer dans le processus de normalisation, et il pourrait être nécessaire de former un nouveau groupe technique
- La proposition est déjà controversée
- Certains développeurs demandent qu’aucun statut officiel ne soit accordé aux outils JavaScript, et beaucoup souhaitent moins dépendre de ces outils
- Il existe un large consensus sur le fait de donner la priorité à la sécurité, aux performances et à la fiabilité, mais l’idée de rendre JavaScript dépendant d’outils intermédiaires est impopulaire
- Un développeur a même déclaré : « RIP Vanilla JS »
L’avis de GN⁺
- Cette proposition pourrait entraîner un changement majeur dans l’écosystème de développement JavaScript. Elle suscite des inquiétudes, car les développeurs devraient davantage dépendre des compilateurs pour utiliser les nouvelles fonctionnalités syntaxiques
- Cependant, l’objectif même de réduire la complexité des moteurs d’exécution et d’améliorer la sécurité ainsi que les performances est positif. À long terme, cela pourrait contribuer à l’évolution de JavaScript
- Dart est un exemple d’autre langage adoptant une approche similaire. Il propose une syntaxe conviviale pour les développeurs tout en étant compilé en JavaScript pour s’exécuter dans le navigateur
- L’adoption de cette proposition devra examiner avec soin divers facteurs, notamment la compatibilité avec le code existant, l’expérience développeur et le support des outils. Il faudra aussi un processus permettant de recueillir pleinement l’avis de la communauté
- JavaScript étant un langage fondamental du développement web, on peut s’attendre à ce que les discussions et son évolution se poursuivent activement
4 commentaires
On dirait qu’ils veulent ajouter une couche supplémentaire et y intégrer des éléments qui améliorent la DX.
Rien que JSX montre que tout l’écosystème a été construit de façon à nécessiter une transpilation, donc je trouve que c’est un avis peu réaliste. On dirait qu’ils pensent que NodeJS résume tout.
Je ne suis pas sûr d’avoir bien compris, mais ça me fait penser à BOOST en C++. Si la proposition de Google est validée et qu’on intègre les bibliothèques existantes dans JSSugar, qu’est-ce qui y entrerait ? Babel ?
Avis sur Hacker News
La VM HotSpot de Java a apporté un grand succès à d'autres langages. Il serait raisonnable que JavaScript vise lui aussi un langage cœur, avec précompilation du sucre syntaxique
Il vaudrait mieux se concentrer sur WebAssembly. JavaScript devrait servir au scripting, et d'autres langages aux applications plus importantes
En tant que personne qui préfère VanillaJS, il y a de la frustration face à des fonctionnalités du langage qui changent de manière forcée. Il faudrait se concentrer sur l'amélioration des API afin que les applications web arrivent au niveau des applications natives
Désaccord avec l'affirmation selon laquelle il n'existe aucun cas d'usage pour BigInt. Même si les développeurs frontend de Google ne l'utilisent pas, d'autres développeurs JS s'en servent. Il faut se concentrer sur l'évolution du langage
Il aurait fallu séparer JavaScript et Wasm. À la place, Wasm a été transformé en citoyen de seconde zone incapable d'accéder aux API web
La solution proposée ne résout pas le problème de fond et rend les choses dépendantes des outils. JavaScript devrait basculer vers un nouveau langage afin de réduire les problèmes de performance et de complexité
Les problèmes viennent de la déconnexion entre le TC39 et la communauté des développeurs. Les outils TypeScript ne sont pas standardisés, et il n'existe pas de projet de portage vers Rust
Des changements dans JavaScript sont proposés à cause des problèmes de maintenance du moteur V8 de Google. Les problèmes de sécurité et le coût de la complexité ont un impact sur les utilisateurs. Il faudrait essayer un autre langage que le C++