Pourquoi vous ne comprenez rien au JavaScript ?

JavaScript
#1

J’aime le JavaScript, mais il n’en a pas toujours été ainsi.

Pensés limitantes

Ce qui m’a empêché de l’apprécier, c’est cette mauvaise habitude presque systématique que j’avais de vouloir transposer quelque chose que je ne connaissais pas (JavaScript), sur quelque chose que je connaissais (C#, JAVA). Je crois que c’est le lot de tout le monde, vouloir simplifier les choses pour les retenir, et les comparer avec une base commune.

Et avec le JavaScript, ça marchait… parfois, et parfois pas.

Dans mon cas, à cause de mon ignorance, couplé à mon égocentrisme il n’y avait qu’une possibilité : le JavaScript avait un problème, et moi j’avais raison, parce que dans mon étude de C#, de Java et même par certains aspects de PHP : certains problèmes que je rencontrais avec JavaScript, n’y existait pas. Ça ne me semblait pas si « compliqué » dans mes langages de Class appris en classe.

Et puis, je me suis mis de l’autre côté de la pièce. Soit le langage était vraiment mal foutu —comme je m’accordais à le penser— soit c’est moi qui n’avait pas compris quelque chose. Il y avait peut-être quelque chose qui m’échappait. Et s’il résolvait d’autres problèmes que j’avais avec le C#, était t-il même possible qu’en essayant de l’utiliser d’une autre manière qu’avec un langage de Class, ces problèmes ne se poseraient plus ?

Le JavaScript ? Si compliqué ?

Et de la même manière que je pourrais regarder une photo, sensé être prise sur la lune, et que je jugerais trop éclairée pour qu’elle ne soit pas un fake, est-il possible que je ne me soit pas dit que le JavaScript était trop bancale ? Limité ? Tricheur ?

Il serait tout aussi possible que ce soit moi qui n’est pas assez de compréhension sur les propriétés de réflexion de la lumière sur un sol lunaire et de connaissances sur les imperfections dû à la qualité optique de l’époque. Ainsi ce serait moi qui ne serait pas capable d’en comprendre l’authenticité… La solution devenait alors simple, il suffisait de faire l’effort de comprendre.

Oui, en JavaScript, on peut finir par avoir une architecture orientée objet, fortement typée et basée sur de l’héritage de classe, merci ES6 et TypeScript… Vous nous l’avez bien « adapté » notre langage à problème… Mais à quelle prix…

Et si vous passiez du côté face, au côté pile ?

Vous savez quoi, JavaScript n’est pas un langage objet fortement typé avec héritage basé sur les classes, C’est un langage faiblement typé, à typage dynamique, à portée statique, supportant l’objet et supportant l’héritage par délégation basé sur des prototypes. Et tant que vous n’accepterez pas qu’un même monde puisse-être vu de plusieurs manières différentes, vous ne pourrez que penser que « vous » détenez la vérité, comme je l’ai longtemps pensé. J’ai a présent compris que si une techno faisait parlez d’elle plus de 3 mois, et que ça me semblait non légitime, ce n’était pas qu’un effet de mode, mais qu’il y avait forcément quelque chose qui m’échappait, et quelque chose à en apprendre.

Si vous souhaitez mieux comprendre le JavaScript d’un point de vu technique, je vous invite à le redécouvrir par cette porte d’entrée que j’alimente au fur et à mesure, en français :

Bonne lecture.

PS : étant de très loin un très bon candidat à l’imperfection, si lors de votre lecture vous relevez des fautes (orthographiques ou de compréhension), faites moi progresser avec vos retours !

Et vous ? Vous et le JavaScript ? Vous en êtes où ?

2 « J'aime »
#2

Merci pour cette piqûre de rappel qui se résume par un bon vieux RTFM s’appliquant à toutes les technos, outils…

Aussi pas mal d’inexactitudes et raccourcis dans les articles associés comme:

“des mecs comme Adobe peuvent inventer des trucs sympa comme le Flash” -> FutureWave puis Macromedia
"En tout cas Joy se laisse pas abattre et implémente ES6 en parallèle du fonctionnement de ES5 dans Node.js" -> V8, donc Google
"setTimeout possède son propre objet this" -> WHAT?

etc…

Enfin un problème de copier-coller dans le résultat de ce code:

[7, 0, 8, 3].filter(function (c) {
       if (c % 2 === 0) {
           return true;
       } else {
           return false;
       }
   });
[0, 3, 7, 8] // <- ici

Le couple if / else y est d’ailleurs totalement superflu:

[7, 0, 8, 3].filter(function (c) {
    return c % 2 === 0 
});

et donc pour la version fléchée:

[7, 0, 8, 3].filter(c => c % 2 === 0)
1 « J'aime »
#3

Top ! Merci beaucoup @Delapouite. J’ai modifié le texte en conséquence de tes retours.

Pour le raccourci fléché je conserve ma version bloc conditionnelle plutôt que expression car ce que je veux mettre en avant est la nécessite des { et } pour un bloc dans une fonction fléchée (ce qui n’a pas de sens si j’utilise une simple expression (pas de return, pas d’accolade). La fonction fléchée avec une simple expression, je la met en avant avec cet exemple : [7, 0, 8, 3].sort((a, b) => a - b);

En ce qui concerne le this. Est-ce ma formulation qui ne convient pas ?

Car this, dans un setInterval ou setTimeout, il a sa propre valeur. La valeur de this change d’un contexte d’exécution à l’autre, et il s’avère qu’en fonction de la syntaxe utilisée pour appeler une fonction, ce contexte peut être changé. Tout ce qu’il faut savoir ici :

#4

setTimeout n’a pas sa propre fonction.
Il attend simplement une fonction de callback à exécuter. Mais comme en JS une fonction est aussi un objet, la valeur de this n’est plus celle du contexte appelant mais bien le this de la fonction callback.
C’est pour ça que ES6 à introduit les “arrow functions”, qui règle ce problème et balaie l’ambiguïté sur la valeur du this. Parmi d’autre vertus.
Je les utilise beaucoup déjà rien que pour ça et pour la lisibilité.

1 « J'aime »
#5

Excellent article @Haeresis ! Bon, l’inspiration (qui est elle-même une inspiration d’un article du blog de CircleCI sur la conteneurisation) est discutable parce que ça fait un peu paraphrase, mais c’est quand même très bien réalisé, la discussion est à jour avec les nouvelles technos, et ça nous dégoûte presque de faire du JS :)

Cela dit, si je peux me permettre quelques corrections dans ton article :

Donc, si je dois utiliser React, je le récupère depuis npm, puis je le rafine avec Browserify, c’est ça ?

rafine => raffine

● Ça l’ai. C’est pourquoi on utilise des gestionnaires de tâches comme Grunt, gulp ou Broccoli pour automatiser les transformations avec Browserify. Et tu peux même utiliser Mimosa.

Ça l’ai => Ça l’est

Tout le monde l’ai, mais tu ne devrais plus l’être avec SystemJS.

l’ai => l’est

Oh, parcequ’il nous permet d’utiliser le JavaScript comme un langage fortement typé, et réduit les erreurs à l’exécution.

parcequ’il => parce qu’il

Je veux dire, la POO était bonne avant, et est toujours utile de nos jours, mais tout le monde à réalisé que modifier des états était pas top

tout le monde à réalisé => tout le monde a réalisé

Les gars utilisant Haskell en parle depuis des années sans parler des gars de Elm.

en parle => en parlent

Les bibliothèques ont en a les sources, et nous avons les meilleures !

Je ne suis pas sûr de l’intention de la phrase, mais j’imagine qu’il faudrait remplacer “ont en a” par “on en a”.

Ça ne me dit rien. Un autre ?
● Transparency ? JsRender ? Markup.js ? Knockout ? Ce dernier permet la liaison de donnée bidirectionnelle.
● Non, d’autres ?

Je pense que tu devrais supprimer la bulle de la liste pour “Non, d’autres ?”, car c’est l’autre personnage qui parle

Et si je ne veux pas inclure l’entièreté de la bibliothèque, j’ai besoin de les chargés par module depuis npm.

les chargés => les charger

Essai Nuxt.js à l’occasion.

Essai => Essaie

Et si c’est pour échaper au JavaScript, sache qu’avec Cordova, tu peux aussi faire des applications mobiles en JavaScript, multi-support.

échaper => échapper

Tu peux en changer à volonter bien sur.

à volonter bien sur => à volonté bien sûr

Désolé ;)

1 « J'aime »
#6

Merci beaucoup pour cette relecture @Pierstoval !

C’est dans la boîte.

J’ai ajouté en pied de page un remerciement ou je cite ton pseudonyme et le site associé à ton compte sur Human Coders pour t’apporter un peu de visibilité. N’hésite pas à me communiquer un autre nom/site ou à me le faire retirer si ça t’ennui.

EDIT : C’est changé (cf. message suivant)

#7

C’est gentil de ta part :)
Je préférerais tu mettes plutôt mon compte Github, le site www.orbitale.io est relativement inactif et est juste là pour décorer :D

#8

Le problème avec JavaScript c’est qu’on le subit plutôt que l’apprendre. C’est le seul langage de programmation du Web. Et il a deux principales difficultés : le scoping/this et le type coercion. ce sont vraiment deux éléments très surprenant comparé à d’autres langages.

concernant le prototypage, je vois franchement pas trop la différence avec de l’héritage, hormis l’aspect dynamique VS statique. il a même l’inconvénient de favoriser la délégation par “héritage” plutôt que par composition.

Pour régler les problèmes de this, il ne faut pas oublier la fonction bind ;) D’ailleurs je trouve que ce sont les plus grosses lacunes des API/librairies en JavaScript : elles documentent rarement le contexte d’exécution et donc la valeur de this.

2 « J'aime »
Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s