Back to Top

Les incohérences de javascript

Javascript, du troll en code

Bon, les articles qui trollent Javascript sont légion sur internet, c’est vrai. J’apporte de l’eau a ce gigantesque moulin, car je considère que ce serait un crime de ne pas taper sur ce langage.

Alors vous vous demandez sûrement « pourquoi taper sur ce pauvre langage ? après tout s’il ne vous convient pas prenez en un autre ». Et bin non ! On n’a pas le choix, c’est javascript en entrée, plat et dessert si vous voulez faire du web ! Évidemment, le problème n’est pas que ce soit l’unique outil sur le marché, mais que cet outil est cassé. Oui Javascript est cassé. Des choix techniques on été fait a sa création, probablement après mûre réflexion d’ailleurs. Mais ces choix apparaissent aujourd’hui comme complètement illogique vis-a-vis de l’utilisation que l’on a du langage.

Il ne faut pas l’oublier, il n’y a pas si longtemps le Javascript c’était bien pour faire mumuse sur son blog perso. Afficher des feux d’artifice ou faire neiger sur l’écran a mamie en se prenant pour Bill Gates, mais c’est quand même relativement léger comme application. Et encore, on voyait déjà que ça ramait. Mais comme les sites un peu dynamiques et beaux a voir dans les années 2000, avec des effets dans tout les sens, c’était pas la principal préoccupation du secteur, on a laissé les enfants s’amuser avec leur jouet difforme et laissé le monstre en sommeil.

Mais quand est venu l’avènement du web, tout le monde a voulu un site qui roxe du poney et a dégainé Javascript. Bon évidemment les performances étaient hideuses. L’industrie a donc investi des millions pour sortir une machine virtuelle avec des performance digne de ce nom -merci google et chrome d’ailleurs-, pour que la techno devienne utilisable.

Au vu de l’investissement consenti, les performances ne sont plus vraiment un problème. Regardons maintenant la bête.

Quand les spécialistes s’en mêlent…

Pour ceux souhaitant investir dans un livre et apprendre le langage, ça existe : David Flanagan en a écrit un qui fait référence, « le guide définitif », il fait 1100 pages. Douglas Crockford, inventeur du JSON, a aussi écrit un ouvrage de référence, « les bonnes pratiques », il fait 6 fois moins de pages. Quand les experts du langage recommandent d’apprendre quoi ne pas utiliser en premier lieu, moi je me questionne.

Entre autres joyeusetés, des mots clés à ne pas utiliser. Oui carrément, les mots clés, comme with, c’est même dit dans la doc. Pour ceux qui ont fait des études d’informatique théorique ou étudié les structures de données, vous pouvez aussi oublier : vous avez des objets, ça vous suffit pas bande d’ingrats ? Ah oui il y a aussi des tableaux, vous êtes content maintenant j’espère ? On est de vrais développeurs nous, si on veut une pile ou un set on les ré-implémente. C’est beaucoup plus rigolo.

Une gestion des types… atypique

Autre aberration du langage, son système de type et d’égalité. En parlant de l’égalité, une bonne pratique selon Crockford est de ne pas utiliser == entre autre parce que 0 == '' et que 0 == '0' mais que '' != '0'. Alors je veux bien que la transitivité ne soit pas quelque chose d’automatique, mais là on est sur des chaines de caractère et des nombres, par sur des constructions mathématiques complexes. A noter qu’il existe certains cas dégénérés ou même === ne lève pas toutes les ambiguïtés, mais il faut vraiment le vouloir donc je m’abstiens.

Vient ensuite la gestion des types, qui est une vraie prouesse d’illogisme, avec 10 == [10] qui est vrai. N’essayez surtout pas de tester des choses vous semblant logiques bande de malheureux, par exemple (10, 20) est de quel type ? object ? array ? number évidemment. -et vaut le dernier élément pour les curieux. Oui, (1, 2, 3, 4) + 6 renvoie 10, ça vous pose un problème ? Je ne vois vraiment pas pourquoi…
On a aussi les additions qui ne sont pas commutatives, après tout pourquoi pas on est plus à ça près -et c’est une des chose les plus logique- []+{} renvoie « [object Object] », {}+[] renvoie 0, encore un choix qui évite un maximum de bugs dîtes moi.

Et si ça ne suffisait pas…

Une autre jolie trouvaille :

 var arr = [];
 arr.length → 0
 arr[3] → "undefined" //pourquoi pas après tout, même si une erreur out of bounds serait plus logique
 arr[3] = "toto";
 arr.length → 4 // on ajoute 1 élément et la taille augmente de 4, pourquoi pas
 delete(arr[3]);
 arr.length → 4 // il n'y a plus rien dans le tableau, comme au départ, magie magie nos idées ont du génie

Dans les choix dégénérés des inventeurs du langage, le choix d’un unique type pour les nombres. Alors pourquoi râler sur ce choix ? Et bien parce que Javascript n’arrive même pas a remplacer une calculatrice digne de ce nom, en effet :
0.1 + 0.2 == 0.3 renvoie false. C’est assez cool d’un autre coté, 0.99999… est égal a 1. C’est peut-être à rapprocher avec la limite de 9*10^-1-n. Mais hors délire de matheux pour trouver un sens, c’est surtout source de bug.

La politique de Javascript fait que tout est clairsemé un peu partout sur le web. Regardez les dépendances d’un projet web utilisant Node pour vous en convaincre.

blank

Les failles de sécurité sont donc nombreuses et invérifiables. Qui va regarder les milliers de codes intégrés automatiquement à sont projet ? La documentation est disponible, mais fragment par fragment à travers le web. C’est très stimulant, mais on n’a plus forcément l’âge pour les chasses au trésor. Donc on ne vérifie pas.

Javascript pour l’algo ne dépasse aucun langage existant, quelque soit la catégorie dans laquelle ont fait la comparaison.
Il est l’incarnation de la dette technique.
Bref, c’est un bug.

Comme je suis gentil, en plus d’être très salé, je vous met un lien recensant les technos permettant de transpiler vers du Javascript, au moins vous pourrez vous passer de cet immondice.

Par Clément Caffin


Random_meme()

Rechercher:





Suis-nous sur les réseaux sociaux!

Instagram

S'abonner