WUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

Entre les malwares, les coins miners dans les repositoies, les typosquatting (dont MALWARE et MINER, et vols de mot de passe), les dépendances énormes dont une pour rajouter des ” ” pour aligner à droite (le truc pas trop compliqué en info) dont le retrait a fait s’écrouler une tétrachiée de paquet, j’ai du mal à voir où le packaging node est … meillleur.

Et étant packageur python depuis 10 ans, le packaging python a aussi ses défauts (presque les mêmes) mais en fait il y a moins de paquets pourris et de dépendance (le padding est de base par exemple). Ah, et nous, on signe nos paquets.

C’est qui les cons qui installent du code qui peuvent pas auditer (tellement il y en a) sans s’assurer que le code téléchargé est le code publié ? Node js !

Non tout est pourri dans le JS c’est comme un bourgeois

En ce qui me concerne, je n’arrive pas à m’accrocher au js ce qui fait de moi de facto un développeur web à ne pas recruter. Ce langage, je le trouve immonde. Immonde non pas pour sa syntaxe (après tout, dépasser les 100k de lignes de code sous lua c’est bien pire), mais du fait que ce langage soit une putain de coquille vide ou tu dois apprendre 10 technos/outils à la fois pour générer quelque chose de potable. Vous, vous êtes sénior vous avez 15 ans de JS vous n’avez aucun recul sur ce que doit endurer aujourdhui un étudiant pour se former à cette bouse. Il y a moins de 6 mois on m’a fait chier pour apprendre nodejs et 48 heures après il a fallu que j’apprenne le typescript (j’ai du me former à devenir un être bipolaire en gros) parce que c’est quasi impensable de faire sans apparemment … et ensuite, quand j’ai commencé à faire de l’asynchrone dessus on m’a expliqué les promises puis on m’a dit d’ajouter un package pour inclure async await car sans ça le code allait devenir bordelique. Serieusement, toutes les semaines ton boss vient te voir en te disant “il faut que tu apprennes ça, il faut que look ceci, il faut que tu prenne en compte ce nouveau package). Je suis fainéant moi et c’est bien normal j’ai pas signé pour être un prolo d’artisan alors ceux qui sortent “oui mais tu peux pas comprendre ce métier c’est de l’artisanat ….” vous méritez la biffle du christ cosmique …

Il y a un mec qui a sorti un exemple sur c# comme quoi sans framework c’est rien. Je suis d’accord mais au moins j’ai pas à réapprendre le language à chaque fois que j’ajoute une assembly. (pas la peine de me biffler sur le c# je l’aime mais sans plus, je ne suis pas un adorateur de langage informatique j’en ai rien à cirer des langages, ce sont juste des outils pour moi, rien de plus).

Par contre j’ai adoré la gestion de package sous node, autant que je l’ai detesté sous python (a ce qu’il parait aujourdhui c’est mieux, mais il y a quelques années en tout cas, vive la galère). Et la doc python, bordel le grand gouroux génère assez de fric avec sa fondation pour pouvoir se payer des tesla mais toujours pas capable d’offrir un site et une doc concise et parfaitement lisible ! Allez voir la doc, c’est une farce qui suinte de la dinde de noel que mamie jacqueline a enfourné avec tout son doigté. /me tacle sam & max avant de fuir !

J’ai pris 20′ pour lire ton article afin de réviser mes connaissances, voire d’apprendre plus, en me démontrant pourquoi true or false sur certaines assertions, et en checkant ce que je ne connaissais pas. Bref, une séance d’autoformation.

Je vois aussi qu’il y a réel effort de bien écrire. Toutefois, comme moi, comme tous, pas mal de coquilles. Est-ce que je peux contribuer en béné à fixer tes typos, et tu cites mon noms comme contributeur ? (j’ai un hobby dans le français et la traduction).

++

Le temps humain est devenu bien plus couteux que le temps machine, oui NodeJS est bien plus rapide que Python mais pas le codeur, plus cher. (et en Python, y’a des solution quand même.) Et Django est un bonheur de clarté et de stabilité, comme tu dis. Peut-on espérer que WebAssembly permette à Django (et d’autres frameworks serveurs) de passer “de l’autre côté de la force”, sur le front?

Chance, quand même: JS est devenu tellement protéiforme que pléthore de langages plus clairs peuvent se transpiler en JS front: Elm, ClojureScript, Dart, et d’autres sont des grands bonheurs. Et d’un côté un serveur Clojure peut avoir son pendant front ClojureScript, un Elm marche idéalement avec Elixir/Phoenix, et un front Dart peut avoir un serveur Go ou surtout… Dart qui nous refait le même coup que Node, en mieux (https://medium.com/the-angel-framework et https://aqueduct.io/):

si Google utilise AngularDart avec +20 à 100% de productivité, avec des tonnes de devs tant seniors que junior, c’est qu’il y a une raison! Un ami CEO d’une start-up a choisi ClojureScript: “ça filtre les bon dev front et comme ils aiment ce qui est puissant beau propre, ils acceptent même une réduction de salaire”! :D

Bref, si JS est “pourri” (complexe, plutôt, car riche et trainant une dette technique de “mal né”, heureusement ce n’est pas bloquant: utilisons le mieux, cachons le ;)

J’ai un peu l’impression que JS est l’anglais: des tas de subtilités selon le pays, d’accents, mais in fine il est seul universel, et y’a quand même sur wikipedia un “simple english” pour tout le monde. Ce qui permet, contrairement au français élitiste et non permissif, grâce à cette souplesse, d’être accessible et toléré par tout le monde.

Quand à la framework fatigue… on peut toujours rester sur un vieux framework, ils sont opensource, les techos n’obligent personne à migrer 1 ou 10 ans de codes vers une nouvelle techno. Et si on n’avait pas cette dynamique, on n’aurait jamais inventé React et la programmation réactive, le fonctionnel, etc. seraient restés dans les cartons. Et il m’aurait toujours fallu 3 devs pour faire en Swift Java et JS ce que React Native fait avec un seul dev.

Ah, côté framework serveur, si on veut encore moins de fatigue, il suffit d’utiliser… Firebase ;-)

Et sur le front: Dart sur Flutter (d’ailleurs le framework choisi par Google pour le futur de Android: FuschiaOS! Dont aussi Rust, Go, Python, mais pas… JS…! :D)

Article intéressant Sam, provocateur, je ne suis pas d’accord avec tout, et en même temps je peux comprendre ta rage envers ce langage.

A mon avis le problème tient plus aux implémentations qu’au langage lui-même, et comme d’autres l’ont bien dit, on aurait eu les mêmes problèmes si le langage de script des navigateurs avait été… n’importe quel autre langage !

Pour ma part je suis venu au JS en développant des plugins WordPress. Bon, venant d’un langage assez douteux comme PHP, j’ai adoré JavaScript. Du coup je ne suis pas vraiment d’accord avec ton assertion que “personne ne fait du JS pour faire du JS”. Je n’ai pas l’impression de faire ça juste “par défaut” parce qu’il n’y avait pas d’alternative, j’ai vraiment aimé dès le début coder en JS, et encore plus maintenant avec ES6.

Il y a plein de trucs un peu “WTF” certes, mais au final, une fois qu’on sait ce qu’on fait, pas tant que ça. MAIS ça prend du temps d’en arriver à vraiment savoir ce qu’on fait en JS. Pour moi, dans ce langage comme d’ailleurs en PHP, il y a le côté “accessible et facile” où on peut coder 20 lignes en vrac et “ça marche”, mais après, plein de subtilités… Donc il est faussement facile.

Pour moi JS est essentiellement plombé par :

Les différences entre navigateurs, malgré les libs comme jQuery et frameworks à la Angular, React, etc. Vécu récemment sur un projet que je venais de livrer. Tout “marchait” et d’un coup ma cliente m’avertit qu’une partie ne fonctionne plus. Après enquête, il s’est avéré que c’était une dépendance du projet Angular qui foirait, uniquement sur Firefox 57 aka Quantum (son Firefox s’était mis à jour tout seul depuis la v56). Au final ça a été plus simple de virer cette dépendance mise là par mon prédécesseur et de ré-écrire un bout de code qui a fait le job. Mais j’étais quand même bien deg (putain ça marchait sur Safari, IE et Edge quoi !).
La trop grande multiplication des librairies et frameworks, que ce soit côté front-end ou côté back-end. Côté front, rien qu’en citant les “gros” tu as Backbone (bon un peu l’ancêtre maintenant), Angular 1.x, Angular 2, Ember, React, Vue.js… Etc. etc. etc. ad nauseam, au point que les devs JS parlent de “JavaScript framework fatigue”. Côté backend, Express et Koa pour les “légers, et puis Sails, Strapi, Lux, etc. etc. etc. Avec ce truc totalement ouf des types qui créent leur micro composant pour tel framework. react-router ne me plaît pas ? Tiens si je créais mon propre routeur, après tout je ne serais que le 101è gusse à faire pareil ! Tiens, y a pas assez de librairies pour faire des requêtes HTTP entre request, fetch, axios, etc., si j’en créais une ?
Et même une fois que tu as choisi un framework, la complexité pour mettre en place une stack de développement propre, avant même de commencer à coder une appli, est assez sidérante (React + Router + Redux I’m looking at you… mais je suppose que c’est le revers de la médaille pour avoir un code commun au serveur et au client).

Donc, sans avoir lu ton article “La communauté JS est actuellement une machine à créer de la dette technique”, je suis à 100% d’accord avec le titre ! Ce n’est pas tellement pire que la prolifération des distros Linux qui pullulent comme des rats, en attendant on est pas aidés, comparés à Python ou Ruby qui ont un “gros” framework web (Django et RoR) et des “petits” bien établis (Flask et Sinatra), sans que tout le monde se sente obligé d’en créer un nouveau chaque jour. Même la communauté PHP est probablement mieux structurée de ce point de vue, car certes vu l’ancienneté du langage il existe des palanquées de frameworks et CMS, mais en gros tu as quand même Zend, Symfony et Laravel pour les gros, et à côté des “micro” (Slim etc.), devenus très matures avec le temps. Je n’ai pas connaissance qu’il existe un seul gros framework node qui se détache nettement et offre le même niveau de fonctionnalité qu’un Django.

Du coup comme le dit Joel29, pas étonnant que maintenir une appli soit un vrai merdier. Le temps de finir d’écrire une app, le nouveau framework du trimestre est sorti, et on est sommé de l’adopter. C’est aussi dû aux évolutions dans le modèle de programmation : par exemple passage du modèle “escalier de callbacks” à “chaîne de Promise” et bientôt à “async / await”.

Voilà, pour moi c’est vraiment ça le problème, le langage souffre, mais pas plus que CSS par exemple, des différences d’implémentation entre navigateurs, et de cette dispersion de la communauté, ce “Not Invented Here”. Reste que, pour moi, CSS donne largement plus envie de se taper la tête contre les murs que JS, sans comparaison possible. Si tu fais du web et que tu survis à CSS, JavaScript c’est une fucking piece of cake ! Mais ce n’est qu’un point de vue personnel !

Ma conclusion serait : finalement les rants sur tel ou tel langage c’est défoulatoire et cathartique, j’ai bien donné dans ce registre sur PHP… Mais finalement une fois qu’on connaît vraiment bien telle ou telle techno on arrive à passer outre ses limitations (ce qui n’est pas manifestement mon cas avec CSS). J’ai même retrouvé un certain plaisir à faire du PHP avec Laravel, ce que je n’aurais jamais cru possible, tellement ce langage a pu me filer des boutons.

Sorry for the gros pavé guys!

Je viens de lire un peux tout cela et pour ma part, la seule chose que j’ai pu constater c’est que les projets JS fond double le temps de réalisation estimé et que pour la TMA c’est un bordel monstre à maintenir. Déjà les rustines sont présentes tous au long du code et je ne parle pas de la relecture pour essayer de comprendre à quoi cela sers. Donc une bonne masturbation cérébrale et quelque plaquette de paracétamol…. Juste un petit message aux Architectes, la prochaine fois que vous vous faite plaisir à mettre ce genre de chose an place, vous viendrez développer et maintenir tous seuls votre appli ;-) .

C’est peu constructif mais symtomatique d’un manque de discernement.

On peut mieux faire.

Javascript hérite de Self (à prototypes d’objets) qui hérite de SmallTalk (à classes d’objets). Si l’on a développé dans plus d’une dizaine de langages, compilés, interprétés et d’assemblage et que l’on connaît bien la conception de logiciels et la programmation par objets, une analyse fine de JS indique au contraire qu’il est sans doute l’un des langages les plus puissants actuellement et, pour des raisons théoriques difficiles à expliquer ici, asymptotiquement le meilleur possible.

Contrairement aux affirmations qui parsèment le texte originel, bien contré par Plop le14/03/2014 à 13 h 28 sur certains points, Javascript n’a aucun comportement bizarre si l’on a compris AU PRÉALABLE que tout est objet en JS, y compris les fonctions, et qu’il n’y a pas de classe mais des constructeurs d’objets, y compris pour les objets primitifs, et que pour simplifier la vie des développeurs on a imaginé un mécanisme de changement de constructeur d’objet, à l’exécution.

Exemple :

Les 6 instructions suivantes :

affectent respectivement à toto :

7true, 8, 8, 7true, true7, 8.

Si l’on ne connaît ni le principe de compilation des expressions algébriques, ni celui des conversions des types primitifs (classes primitives si l’on préfère), il est difficile de prévoir ces résultats.

De toute façon ces exemples ne démontrent qu’une facilité conjoncturelle, pas une méthode de développement. Ceux qui en abusent sont de mauvais développeurs car ils forcent les autres, ceux qui reprennent leurs scripts, à une attention soutenue bien inutile.

Le drame de JS c’est qu’il n’est finalement pas réellement enseigné, sauf pour bricoler dans les pages Web, souvent par copier-coller, par exemple sur Stack Overflow où l’abscons confine parfois à la bêtise de ceux qui veulent éparter la geekerie.

Je conseille aux sceptiques et à ceux qui veulent produire du logiciel de qualité en tirant profit de la puissance des fonctions et des prototypes d’objets, de commencer par lire la doc d’ECMAScript) et l’ouvrage de Flanagan.

Il y a 20 ans lorsque j’ai commencé à développer en JS, je trouvais le langage un peu bricolo (je suis de la génération des développeurs en C, SmalTalk 80, FORTRAN 90, Pascal UCSD, ADA…). Après l’avoir étudié de près (comme préconisé ci-dessous) j’ai complètement changé d’avis.

En revanche il y a beaucoup à dire sur la partie JS qui manipule les objets du DOM. Les développeurs ne connaissaient sans doute pas en profondeur les fondamentaux de JS et du développement par objets, sinon il n’y aurait pas tant d’incohérence dans les valeurs ou les « classes » de retour de certaines fonctions. Peut-être est-ce aussi dû à un manque de management du développement ?

Exemple : on suppose que toto est un Element. Alors :

toto.childNodes retourne une NodeList

toto.childNodes retourne une NamedNodeMap

Pourquoi pas une AttributeList ?

Mais il y aurait tant à dire que je ne peux développer ici. En revanche on peut lire un article permettant de s’ouvrir l’esprit sur une façon de développer permettant d’être à la fois plus proche de l’utilisateur, en utilisant son vocabulaire, et à la fois plus libre dans son développement, en utilisant parfois des astuces de programmation : Modules avec ILO.

Bonne lecture.