JavaScript est-il malade de la compatibilité ascendante ?
Quels en sont les avantages et inconvénients et quelles solutions ?

Le , par danielhagnoul, Rédacteur
JavaScript incorpore sans cesse des nouveautés et des améliorations en assurant une compatibilité ascendante, mais il oublie quelque chose.

L'aspect positif : cela lui permet de faire tourner d'anciens codes.

L'aspect négatif : certains utilisateurs, même de nouveaux utilisateurs du langage, se complaisent à utiliser des vieilleries alors que le langage dispose d'instructions plus performantes, parfois depuis longtemps.

Certes, on fait un peu de ménage de temps en temps (voir fonctionnalités dépréciées), mais est-ce suffisant ?

En dehors des personnes obligées de travailler pour des horreurs dignes du musée, je pense aux anciens navigateurs et principalement à la série des IE, pourquoi utiliser des instructions dépassées ?

Quelques exemples :
  • "var" au lieu de "const" et "let" ;
  • "getElementBy..." au lieu des versatiles et performants "querySelector" et querySelectorAll" ;
  • "on..." au lieu du performant et versatile "addEventListener" ;
  • écrire du code ES2015 et en faire une horreur avec Babel alors que tous les navigateurs d'aujourd'hui sont parfaitement compatibles y compris pour les modules ES2015+.


Je pense que si l'on continue sur la voie actuelle on va créer des "clans" de programmeurs JS (et je n'ai pas parlé des nodistes) qui ne se comprendront plus entre eux, du genre discussions entre utilisateurs de Python branche 2 et de Python branche 3, mais en pire ! Il y a au moins un autre langage qui souffre du même mal : Java.

Je propose deux solutions :
  1. Donner un numéro de version à JS, avec un grand ménage sur les instructions qui existaient avant ES2015.
  2. Réviser le contenu de l'instruction "use strict" dans le sens ci-dessus et promouvoir largement son usage.


La deuxième solution, acte volontaire de l'utilisateur, aurait l'avantage de ne pas trop compliquer le fonctionnement du navigateur.

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster un commentaire

Avatar de Hyome Hyome - Membre du Club https://www.developpez.com
le 17/08/2018 à 9:19
"getElementBy..." au lieu des versatiles et performants "querySelector" et querySelectorAll" ;
querySelectorAll vs getElementsByTagName
https://jsperf.com/queryselectorall-vs-getelementsbytagname
getElementsByTagName: 962 582 895 op/sec
querySelectorAll: 38 070 op/sec --> 25 284 fois plus lent !

querySelector vs getElementById
https://jsperf.com/getelementbyid-vs-queryselector
getElementById: 837 269 329 op/sec
querySelector: 3 095 559 op/sec --> 270 fois plus lent !

Donc querySelector(All) c'est bien pour des selecteur CSS élaborés, mais dire qu'il est performant comparé à getElementBy... est faux.
Avatar de scandinave scandinave - Membre averti https://www.developpez.com
le 17/08/2018 à 9:25
Pour ce qui est des "vieillerie", il a encore beaucoup de windows 7 + IE en fonctionement crois moi.

Sinon le mythe de, je limite a mort le langage pour éviter que les dêveloppeur fasse de la merde est vieux comme le monde mais n'a jamais résolu quoi que ce soit.

C'est au développeur de se former et de se tenir à jour. Ce n'est pas au langage de corriger des lacunes.

Pour la version, ca existe, tu l'a cité, ça s'appelle ES 2015, 2016 etc.

Enfin tu cite java. C'est justement sa rétrocompatibilité qui fait ça grande force. Tu es sûr que le code continuera a tourner quoi qu'il arrive. Regarde comment les gens on hurler du passage de angularjs a Angular 2.
Heureusement qu'il y avait la force de frappe de Google derrière, sinon cela aurait été un échec.

Bref, pour moi rien n'ai à changé et tout fonctionne. Je ne me sens aucunement limité. Je pense que les mecs qui font Emacscript savent ce qu'il font.
Avatar de sirthie sirthie - Membre confirmé https://www.developpez.com
le 17/08/2018 à 10:14
JavaScript est-il malade de la compatibilité ascendante ?
Ça serait pas plutôt la compatibilité descendante ?

https://fr.wikipedia.org/wiki/Compatibilit%C3%A9_ascendante_et_descendante
Avatar de danielhagnoul danielhagnoul - Rédacteur https://www.developpez.com
le 17/08/2018 à 10:26
@Hyome : oui c'est plus lent pour des utilisations basiques dans les tests qui bouclent X milliers de fois la même opération. Mais sur une page web, la différence est à peine perceptible.

Avantage : il y a les sélecteurs CSS élaborés et la recherche d'éléments dans un autre élément du DOM.

Les méthodes "getElementBy..." sont celles de l'objet document alors que les méthodes "querySelector" existent sur chaque élément du DOM : Element.querySelector().

----

@scandinave : ES2015 et suivant sont les numéros de version d'ECMAScript pas de JS.

C'est au développeur de se former et de se tenir à jour. Ce n'est pas au langage de corriger des lacunes.
L'histoire de Python et de Java montre que sans un mécanisme externe (pour JS, navigateur ne prenant plus en compte les instructions obsolètes) seule une petite partie des utilisateurs suivent et appliquent les nouveautés. La sortie de ES2015 c'était il y a 3 ans déjà.
Avatar de goldbergg goldbergg - Membre actif https://www.developpez.com
le 17/08/2018 à 10:33
"var" au lieu de "const" et "let" ;
Je ne vois pas ou est le problème a utiliser "var" partout ? Sa impact les perf?
Et sinon, même sous ie "const" est supporté depuis longtemps.

"getElementBy..." au lieu des versatiles et performants "querySelector" et querySelectorAll" ;
"querySelector" est ce qu'il y a de moins performant (en dehors de Jquery qui est encore pire), il y a enormement de test sur jsperf qui le prouvent.
Les "getElementBy" ne sont surtout pas a écartée si on veut un code optimale...

écrire du code ES2015 et en faire une horreur avec Babel alors que tous les navigateurs d'aujourd'hui sont parfaitement compatibles y compris pour les modules ES2015+.
Pour ce point je suis d'accord, je ne comprend pas pourquoi certains s'acharne a absolument utiliser Babel qui génére du code tous moisi...

certains utilisateurs, même de nouveaux utilisateurs du langage, se complaisent à utiliser des vieilleries alors que le langage dispose d'instructions plus performantes, parfois depuis longtemps.
Moué, ou pas...
Les sucre syntaxique tel que "class" n'ont rien de plus performent et n'ont rien d'une évolution (au contraire).
Comme dit plus haut, ton exemple avec les sélecteur rajoute au contraire de la lenteur (et je ne parle pas des mauvais usage a vouloir faire une sélection via des sélecteur CSS hyper chiadé, la ou souvent on pourrait faire bien plus simple).
Bref, je ne vois vraiment pas ou est le problème a utiliser des api qui date (mais qui on fait leurs preuves) plutôt que des nouvelles qui ne sont pas forcement top et qui risque d'être déprécié (malheureusement c'est arrivé plus d'une fois...)
Avatar de danielhagnoul danielhagnoul - Rédacteur https://www.developpez.com
le 17/08/2018 à 10:34
@sirthie : j'ai pris exemple sur le titre du livre sur Java, mais en effet mon choix est discutable.
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 17/08/2018 à 10:54
"var" au lieu de "const" et "let" ;
const et let n'ont pas vocation à remplacer var. var n'est pas devenue une vieillerie avec l'apparition de const et let

const = constante
let = variable à portée limitée au bloc , ce qui est parfois très bien mais peux aussi être génant auquel cas var prend du sens.
const et let sont donc des ajouts très intéressant au langages, mais ne remplaceront pas var

écrire du code ES2015 et en faire une horreur avec Babel alors que tous les navigateurs d'aujourd'hui sont parfaitement compatibles y compris pour les modules ES2015+.
J'ai eu le cas récemment avec IE10 et 11 qui sont supposé être compatible ES2015 et qui ne supporte pas TypedArray.prototype.slice(). Peut être que dans ce cas précis j'aurais évité un beau bug

Pour ce qui est de la compatibilité , comment on fait avec tous les sites écrit en js non moderne ? Du jour au lendemain on condamne des millions de sites ? Plein de petits sites sont en ligne , utiles mais non maintenu pour X raisons.

Quand on commencera à avoir des utilisateurs qui utilisent que des navigateurs evergreen on pourra envisager de casser la rétrocompatibilité , mais je pense qu'on à encore quelques années de souffrance devant nous , en particulier dans le monde pro.

Perso je vois pas le mal à gardé d'anciennes fonctionnalités à partir du moment ou elle ne mettent pas en péril le langage. Après libre à chacun d'être formé et d'utiliser les dernières nouveautés ou non. C'est comme en C++ tu peux faire un programme en C++98 comme en C++17. Idem en JAVA. La seul contrainte que ça apporte c'est éventuellement de freiner l'adoption des nouvelles versions (on change pas quelque chose qui marche).
Avatar de melka one melka one - Membre éclairé https://www.developpez.com
le 17/08/2018 à 15:17
on..." au lieu du performant et versatile "addEventListener
addEventListener a été créé après les evenements on.... pour palier au problème de cumule d'evenement le plus connu étant onload qui cumulé supprime l' evenement onload précédent et sa permet simplifie la mise en place de plusieurs scripts. removeEventListener donne la possibilité de supprimer l'execution d'une fonction sans retirer l'evenement complètement
Avatar de lmontout lmontout - Membre du Club https://www.developpez.com
le 17/08/2018 à 16:14
C'est au niveau de ton éditeur de code de te suggérer des évolutions de codes pertinents.
J'aime bien les outils (langage, edi, progiciel etc....) qui me garantissent de bien fonctionner à chaque montée de version sans passer des mois à lire les "breaking changes" et à imaginer les patch.
Avatar de Grulim Grulim - Membre actif https://www.developpez.com
le 17/08/2018 à 23:00
2 choses me choquent :
1) Babel qui produirait du code moisi : Babel transpile le code de façon conforme au proposition du TC39 (cf https://github.com/babel/proposals).
2) Je produis pas mal de code JS, je dois bien dire que je ne vois plus l'utilité de var (et très peu let).
Contacter le responsable de la rubrique Accueil