Mais qu’est-ce que vous avez fait de Javascript ?

Note préliminaire : cet article est avant tout un recueil de mes opinions. Il ne s’agit pas de faits, ou d’éléments soigneusement étudiés, mais plus d’irritations, d’incompréhensions. (Vu que cet article est en train de devenir mon plus lu, je préfère baliser le terrain)

Je viens de finir un bon paquet de développement Javascript « full-stack » avec Nodejs, Vuejs et tout un tas de trucs. Et franchement,

(oui, il va y avoir un paquet de tweets, parce que j’ai eu l’occasion d’en parler)

Mais qu’est-ce que vous avez fait au langage ?

a7fc014bf8488b37d60ed7dc6c76acbff5d3fb7491ff3cbd302a4a9a4743ef14Quand je faisais du Javascript, avant, on avait un chouette langage fonctionnel salement déguisé en Java par le biais d’un marketting stupide. Et un jour, V8 est arrivé, et comme l’héritage par prototype, c’est pas cool, ES5 et ES6 se sont succédés à un train d’enfer pour apporter toutes les folies des langages orientées objet : import, héritage, interfaces, closures, théoriquement, vous avez maintenant tout ça.

Le cas particulier de l’import

Ca marche comment l’import ? En Javascript classique, ça marche facilement avec requirejs (la doc est claire, et le besoin assez simple). Avec ça, écrire une application un peu complexe, c’est quand même raisonnablement facile (je le sais, je l’ai fait). Mais en ES6, si vous êtes côté serveur (dans Nodejs, kwa), vous écrivez

const expect = require('expect.js')

Mais côté client, vous écrivez

import localForage from 'localforage'

Mais c’est vraiment génial, cette idée de NE PAS UTILISER LA MEME SYNTAXE DANS DIFFERENTS ENVIRONNEMENTS ! Je ne sais pas combien de langages précédents ont eu cette idée … douteuse. Tout ce que je sais, c’est que je n’en connais aucun.

Non mais static, c’est static ou bien ?

Oui, parce que bon, superposer les concepts Java/C# sur une base Lisp, ça donne parfois des résultats curieux.

Du coup, quand vous créez une classe comme ça

class CaVaMarcher {
	static uneFonction() {
	}
	
	static uneAutre() {
		this.uneFonction()
	}
}

Est-ce que ça marche ? Eh bien je n’en sais rien. Mon code me dit que oui, mais ma tête me dit que non. PARCE QUE STATIC AVEC THIIS C’EST ENCORE UNE IDEE GENIALE ! A la décharge des fous qui ont créé ES5/ES6, this a toujours été un problème du Javascript.

Mais qu’est-ce que vous avez fait au build ?

Parce que bon, jusqu’à node/npm, livrer un projet JS, c’était pas super dur : tu prends tes fichiers, si tu es audacieux tu les minifie (mais en vrai ça n’est pas si important si tu caches bien ton JS, ou que tu utilises un CDN), tu les mets dans ton WEB-INF/resources (en Java), et BAM, c’est servi.

Webpack de l’enfer

escapefromhellgraphicEn 2017, comme tu fais de l’ES6, mais que ton navigateur ne le supporte pas forcément, tu passes par webpack pour le transformer en honnête Javascript.

Et dans quel enfer tu t’enfonces ? A côté de ça, générer les interfaces des EJB 1.0 avec ejbgen c’était de la rigolade. Que je vous raconte. Le truc génère un gros fichier Javascript (5 Mo pour notre application) à partir du paquet de code, d’images, de CSS (compilé depuis des préprocesseurs, parce que franchement, la syntaxe CSS n’est pas terriblement lisible – qu’ils disent). Pour ça, il faut configurer ça avec un fichier webpack.js à la syntaxe … Tellement merdique. Regardez donc cet exemple. C’est un cas vraiment super simple qui ne fait pas grand chose de sophistiqué. Et pourtant, c’est déja la merde non documentée. Alors quand il faut ajouter des trucs comme vuejs (j’en reparlerai, pas de panique), ça devient incroyablement tordu.

Surtout avec les histoires de sourcemap (qui sont un authentique exemple de complexité accidentelle) qui sont loin de marcher aussi bien qu’imaginé.

Du coup, webpack, ça marche, mais franchement, ça a un côté terrifiant de complexité inutile dans le concept et dans l’implémentation. Heureusement, le reste du build cache ça.

Non mais ce build JS

npm de merde

dessin-de-merdeLà ça m’énerve vraiment. Quand ces folies de build ES5/ES6 ont commencé, et que les besoins de gérer un cycle de vie et des dépendances se sont posés, il me semble que les Javascripteurs auraient pu, à défaut d’utiliser, tout au moins copier les idées de maven, par exemple, ou d’autres build tools du monde Java (ou d’autres, mais je ne les connais pas). Parce que franchement, les mecs qui ont créé npm (qui a fourni le format canonique du package.json) ne se sont pas trop fait chier : une liste de dépendances, et une map associant des noms de commandes, et c’est marre. Pareil pour la récupération des dépendances : les mettre dans un dossier node_modules dans le projet, sans trop se soucier de la version téléchargée, c’est une PUTAIN D’IDEE DE MERDE.

Yarn de super-merde

800px-kin_no_unkoA cause des défauts invraissemblables de npm, les mecs de facebook ont créé yarn qui « ccorige le problème des versions incorrectes ». PUTAIN MAIS ILS NE POUVAIENT PAS ETRE AMBITIEUX ? Parce que bon, d’accord, ces histoires de dépendances incertaines, c’est un problème. Mais il y en a d’autres.

Comme par exemple le fait que les commandes soient dans cette saleté de map, et soient en fait des exécutables système (qui doivent donc être dans le PATH, et ne marchent donc pas sous Windows – gg les gars).

Ou comme le fait qu’il n’y ait aucune espèce de build standard, et qu’il faut donc tout réécrire dans chaque projet.

Ou comme le fait qu’il ne soit pas possible de définir de modèle de projet, ou de modularisation du build.

Franchement, yarn, c’est bien de l’esbrouffe.

Et ces frameworks de merde

wrong-tool-pizzaParce que bon, angular, c’est l’horreur, tout le monde le sait, ça a été conçu par des mecs qui avaient trop fait de développement JavaEE et en avaient perdu l’esprit. React, je peux pas en dire du mal (mis à part le fait que si tu t’en sers sans la surcouche de Redux, t’as l’air d’être dans la merde, puisque tout le monde te dit qu’il faut utiliser Redux).

Du coup, forcément, tu suis tout le monde comme un mouton, et tu prends vuejs avec l’impression d’être un putain de révolutionnaire. Bon, c’est dommage pour toi, parce que Ractivejs, c’est comme vuejs, mais en mieux (si si, en mieux).

D’abord, t’as pas le concept complètement con de fichier .vue dans lequel tu mélanges le HTML, le Javascript, et le CSS. Parce que qu’est-ce que vous avez PUTAIN DE PAS COMPRIS DANS LA SEPARATION DES RESPONSABILITES ? Je veux dire, quand t’écris ton composant, tu passes pas ton temps à modifier les trois en même temps, si ? En bonus, le fichier .vue, ben ton navigateur ne le comprend pas. Du coup, tu dois aller modifier ton webpack.config.js qui était déja bien merdique pour utiliser le vue-loader, qui fout un peu la merde avec le sass-loader. Bon, mais ce problème de build n’est en fait qu’un épiphénomène.

Ben oui, parce que vuejs fournit peut-être des « composants », mais il faut encore que tu utilises un framework CSS, sinon tu vas galérer avec les resets CSS. Du coup, tu te rajoutes Bulma (oui, le nom est merdique pour les recherches dans Google) par exemple, mais tu dois aussi l’intégrer dans webpack parce qu’il est fourni en SCSS (re-argh).

Et bien sûr, c’est quand tu ajoutes Bulma, vuejs, et toutes tes dépendances, que ton fichier JS généré atteint les 5 Mo. 5 Mo, tout ça parce que tu ne veux pas que l’utilisateur attende au démarrage de ta page. Non mais qu’est-ce que c’est que cette merde ? Tout ça pour un PUTAIN DE SITE MOBILE. Comment vous croyez que ça peut marcher avec une connexion un peu faible ? Ben mal. Très mal. Trop mal.

Et ce offline de merde

pas-de-signal-panneLà, pour le coup, c’est chaud, mais je veux bien comprendre le concept. Quand ton navigateur est déconnecté, pour pouvoir utiliser l’application web, tu dois stocker toutes tes données dans le cache local.

Mais là, tu fais comment ? Tu utilises localForage directement ? Ou tu passes par des web workers ? Et là, j’atteinds ma limite, donc je ne peux pas râler en majuscules.

Mais pour tout le reste, clairement, le monde Javascript déconne à pleins tubes. J’espère bien que ça changera, parce que là, c’est super pour que les sociétés de service fourguent des consultants qui connaissent juste le framework à la mode. Mais honnêtement, c’est pas comme ça qu’on produit du logiciel durable. Mais est-ce que ça fait partie des besoins des clients ? Je n’en sais rien.

Mais du coup tu vas refuser de faire du Javascript ?

Non, parce que dans les bonnes conditions (donc sans node, sans webpack, sans framework aux idées à la con), développer une appli web Javascript (par exemple avec requirejs, Ractivejs, et un peu d’axios pour les requêtes Ajax, le tout en Javascript classique) est assez plaisant, et surtout très simple. Par contre, les outils actuels du développeur full stack Javascript sont, à mon sens, à la fois insuffisants et conceptuellement incorrects.

Publicités

4 réflexions sur “Mais qu’est-ce que vous avez fait de Javascript ?

  1. Désolé si ton projet s’est planté à cause de tous ces défauts ! De notre côté, on a énormément gagné en productivité avec les outils que tu détestes (webpack, npm, yarn, react …), je t’invite donc à utiliser ce qui marche pour toi et à ne pas perdre ton temps à bitcher.
    Et ne dis pas que tu n’as pas le choix : tu faisais du web avant cette stack.

  2. Hello

    Je sens comme un peu de #JSfatigue dans ton message 🙂

    Depuis quelques années, pour pouvoir gérer des single-page-apps de plus en plus riches, et donc complexes, l’écosystème JavaScript a explosé avec une variété de possibilités, tendances, frameworks… du bon et du mauvais, pour des petits, ou des gros projets, mais c’est cette richesse, grâce à l’anarchie de NPM, qui a permis de faire émerger de nouvelles solutions pour répondre à de nouveaux challenges (fast, maintenables webapps, reusable components…). Cette période d’instabilité a été douloureuse pour nombre d’entre nous, mais force est de constater que la situation s’améliore, et que les outils se standardisent pour chaque « stack ».

    Quelques commentaires sur tes irritations :

    – imports : il est tout à fait possible d’utiliser la même syntaxe sur le client ET le serveur, c’est là tout l’intérêt d’utiliser un seul language pour le front et le back : mêmes outils, mêmes language, partage de code… et il n’est pas obligatoire d’utiliser babel.

    – webpack : oui on s’est tous cassé les dents dessus, j’y ai moi même perdu de nombreuses nuits… mais le produit est maintenant stabilisé pour les stacks standards. Et le bénéfice qu’il apporte est quand même indéniable : plus besoin de gulp, grunt, flurp, blurp, plus besoin de s’inquiéter des « paths » des css, assets… c’est quand même magique…. une fois que ca marche 🙂

    – npm : je ne connais pas de solution de packaging/publication plus simple et efficace. Certes il peut y avoir des soucis de dépendances (surtout sur les gros projets), mais ca me parait inévitable quand ton projet utilise 90% ou plus de code externe que tu n’as même pas vérifié ou lu ! C’est le prix de l’open source et franchement ce n’est pas cher payé. Pour moi npm est l’argument de vente n°1 du JavaScript, et ce qui a permis cette explosion. npm publish #ftw !

    – frameworks : oui il y a un gros raté de « communication » sur react/redux. redux a été présenté à tort comme indispensable avec React, alors que pas du tout, et nombre de devs se sont rajoutés inutilement cette abstraction, dès le début, sans forcement comprendre l’intérêt de ce « pattern ». Je recommande de ne PAS utiliser redux au début.

    – offline : oui c’est encore compliqué, je n’ai pas encore vu de « silver bullet ».

    Pour résumer, il ne faut pas utiliser les outils dont on a pas besoin 🙂

    Allez je partage quelques pépites découvertes récemment sur cette stack, qui j’espère te redonneront espoir

    http://codesandbox.io : prototypage frontend rapide à base de webpack/babel 100% en ligne.

    http://zeit.co : deploiement instantanné de SPA ou serveurs NodeJS

    Et bienvenue sur http://slack-francejs.now.sh pour discuter de JavaScript !

  3. Salut Nico, merci pour ce grand moment de bonheur.

    Dis moi tu serais pas un descendant de Don Quichotte ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s