Javascript, c'est de la merde

17 · 12 · 2022

Allez, mon ptit post de rant à 2 balles de l'année, le dernier, vous me le laisserez bien passer…

Pour la petite histoire, j'ai décidé que HomeAssistant ne me convenait plus pour la gestion de ma domotique. C'est très personnel (comme l'ensemble de mes réflexions sur ce site, d'ailleurs), je peux comprendre que pour vous, ça marche comme vous voulez. Mais pour moi, c'est plus possible. Je ne vais pas rentrer dans le détail ici, ce n'est pas le sujet, mais du coup, il me faut une dashboard pour gérer tout mon bordel IoT.

Sauf que bien sûr, rien ne me convient. Je décide donc de me lancer dans le dev de ma dashboard. Et je sais d'avance que ça va être la merde, mais je m'en fout du moment que ça crash pas toutes les deux minutes. Voyez, je ne suis même pas hyper exigeant.

Ben en pratique, javascript, c'est de la merde.

Déjà, je confirme ce que je disais plus tôt cette année : les devs frontend ne touchent plus au CSS, et ne savent plus produire du HTML (et encore moins si le HTML produit par leur framework est potable). C'est vraiment affligeant.

Comme je ne me considère pas comme un dev full-stack, haïssant javascript par-dessus tout et n'ayant pas vraiment la patte artistique, de surcroît ne sachant pas où je vais avec ma dashboard et malgré mon rant à propos de Tailwind, je décide malgré tout de partir sur ce "framework" CSS auquel je suis déjà habitué, afin de prototyper rapidement une UI et avoir une idée de ce que je peux/veux en faire.

Et comme je sais que je n'y couperai pas (à moins de ne pas faire une app web, ce qui aurait été une autre option encore plus pourrie), j'ai choisi un "framework" javascript, en l'occurrence Vite. Étant déjà un habitué de Vue, je me suis dit que je n'allais pas être dépaysé.

Et en effet, tout cela fonctionne pas trop mal, sauf que mon code est vraiment dégueulasse. Comme mentionné dans mon rant contre Tailwind, le HTML est bloaté, le CSS est bloaté, et selon Tailwind, pour l'éviter, il faut faire des composants Javascript.

Je m'exécute et le résultat est à chier. Vraiment. HTML bloaté, check. CSS bloaté, check. Javascript bloaté, check. Je n'ai jamais produit un code aussi immonde, et qui, pourtant fonctionne très bien. C'est juste lourd, moche, pas maintenable, bref, la gerbe.

Donc, d'après moi, la suite logique, c'est d'opter pour un genre de framework UI, tel que Vuetify. Je me dis, naïvement, que puisqu'il y a "Vue" dans le nom, ça doit fonctionner sans encombre avec Vue ou Vite.

Haha, "que ne vous ait nenni". Le plus simple pour travailler avec Vuetify, c'est de démarrer avec Vuetify, et c'est d'ailleurs une marotte dans le milieu : il faut bien choisir la stack avec laquelle on veut bosser dès le départ parce qu'après coup, c'est la merde. On peut parfois réutiliser ses composants (dans mon cas, tant que je reste sur des "frameworks" se basant sur Vue), mais toute l'initialisation du projet est d'une opacité totale et angoissante.

Pour utiliser Vuetify à partir de mon app actuelle sous Vue, je dois installer un paquet npm et le déclarer dans l'instanciation de ma classe Vue. Rien de choquant n'est-ce pas ?

Le problème, c'est qu'avec ce système, pas de treeshaking. Pas de treeshaking signifie zéro optimisation sur le bundling : tout le code de tous ces frameworks/libs foireux s'empile dans un monstre gargantuesque de plusieurs centaines de Ko (voire, Mo). Tout ça pour afficher quelques données de capteurs en temps réel.

Alors, je me dis que je vais backup tout ça, et suivre la doc de Vuetify depuis l'installation du truc, au lieu de partir depuis une install de Vite.

À poil, sans rajouter la moindre ligne de code, juste en suivant la doc (une commande à lancer, pas la mer à boire), le bundle de production pèse plus de 500ko pour le javascript, et, pire, pareil pour le CSS. 1Mo la page, et je n'ai encore rien fait. On est en plein dans le paradoxe de Jevons : maintenant qu'on a Internet "gratuit et illimité" partout, on peut bien se permettre de faire de la merde qui pèse 1Mo de base. Déjà que je trouve la feuille de style de mon blog lourde… (elle pèse 13.57Ko)

Mais c'est même pas le pire. Mon dossier node_modules pèse à lui seul 104Mo. Je me tape plus de 100Mo de libs pour mettre à jour du texte sur une page web. Et tout ça en plus, c'est censé être mobile-first. Si encore c'était pour faire des apps natives, à la limite. Mais là on parle d'une simple page web, mobile-first.

Et c'est toujours pas le pire. Le pire, c'est l'absence totale de contrôle sur le HTML et le CSS. Tout est composants (mal) pré-stylés. Le code est immonde, parce qu'il amplifie la lourdeur du HTML vanilla.

Une grille de trois colonnes avec du code "classique", ça ressemble à ça (dans son plus simple appareil, optimisé et tout) :

<div class="row">
    <div>
        Colonne 1
    </div>
    <div>
        Colonne 2
    </div>
    <div>
        Colonne 3
    </div>
</div>

Et le CSS qui l'accompagne :

.row {
    display: flex;

    & > div {
        flex: 1;
    }
}

C'est simple, clair, sémantique. Avec Vuetify, ça devient :

<template>
    <v-container>
        <v-row>
            <v-col>
                <v-sheet>
                Colonne 1
                </v-sheet>
            </v-col>
            <v-col>
                <v-sheet>
                Colonne 2
                </v-sheet>
            </v-col>
            <v-col>
                <v-sheet>
                Colonne 3
                </v-sheet>
            </v-col>
        </v-row>
    </v-container>
</template>

(~~Même ma coloration syntaxique démissionne…~~ Elle ne démissionne plus depuis que je n'utilise plus Hugo…)

C'est toujours sémantique, mais c'est totalement opaque : que produit v-container, v-row, v-sheet ? Ne suis-je pas censé le savoir, surtout si je manipule un Shadow DOM ?

En fait, je ne pas censé me poser la question. Le sentiment que j'ai, c'est qu'on m'offre l'accès à des composants, et j'ai juste à fermer ma gueule. Le "framework" se débrouille seul avec le HTML et le CSS (basé sur Bootstrap et orienté Google Material Design, ça doit expliquer pourquoi ça me donne la gerbe), moi je me contente de travailler avec une abstraction de haut niveau. Je n'ai pas mon mot à dire sur les couches intermédiaires. Je ne suis pas assez intelligent pour ça.

Vous me direz, on a toujours râlé sur des évolutions qui sont devenues la norme, et quelques vieux cons continuent d'utiliser des vieux trucs qui font même pas le café. Dans le cas contraire, on coderait tous nos sites en assembleur. D'ailleurs, qui code encore son site… /s

On ne le ressent peut-être pas encore comme ça parce que nos métiers sont globalement encore jeunes : le développement web date seulement des années 90. Mais les devs comme moi sont des artisans dont le métier est en train de disparaître au profit de l'industrialisation déraisonnable. Nous sommes les forgerons d'antan, et je crois qu'il est crucial que, dès aujourd'hui, on s'inquiète de notre avenir.

Comme les anciens forgerons, nous allons devenir une minorité, détentrice d'une qualité de travail à laquelle personne d'autre ne peut prétendre, mais nous sommes coûteux et nous ne travaillons pas aussi vite que les p'tits jeunes biberonnés à ce genre de stacks. Nous autres artisans du web, qui mettons les mains dans le cambouis, qui comprenons ce que nous demandons à la machine et comment elle l'exécute, nous allons disparaître.

Pas du fait de l'IA (encore une fois, on est trop cons pour ça), mais du fait de l'industrialisation déraisonnable. De l'over-abstracting. Des multitudes de couches qui étouffent le coeur du métier, et le coeur du travail bien fait.

Mon discours sonne peut-être comme celui d'un vieux con aigri. Pas grave, j'ai l'habitude. Peut-être que tout ça va déboucher sur quelque chose d'enfin correct. Néanmoins, ça fait depuis, quoi, vingt ans, qu'on dit que javascript c'est de la merde. Et c'est tout son paradoxe : non seulement c'est toujours de la merde, mais en plus c'est encore là, et c'est de pire en pire.

1Mo pour une feuille de style et un fichier js pour mettre à jour du texte sur une page web à la réception d'un message. La même chose en vanilla prendrait quelques dizaines de Ko. Là je parle d'un truc tout simple à usage perso, je comprends bien qu'en environnement de travail, la situation n'est pas la même, mais le dev, c'est d'abord une histoire de passionnés, avant d'être un business…

Parce que, parlons-en, du côté business ; il faut compter toute la chaîne de production et d'exploitation de ce code : le code brut doit être stocké dans un dépôt (occupation sur disque qui a un coût), les dépendances doivent être téléchargées (encore plus de volume de stockage), puis compilées (coût d'occupation CPU), sachant que certaines d'entre elles peuvent être vérolées… Le résultat doit ensuite être testé (+QA), et s'il passe les tests, on recommence la procédure, cette fois avec les paramètres pour la production. Re-téléchargement, re-compilation, etc. Le cloud à la demande a de beaux jours devant lui, bien joué les hipsters, vous avez gagné. Ramassez votre pognon sur le dos des boîtes qui ne comprennent rien à ce système et qui payent une blinde pour utiliser un ordinateur qui n'est pas le leur.

Et le serveur qui doit héberger tout ça, il doit envoyer toute cette merde à chaque client qui le demande, donc ça a un coût en bande passante, en volume de données, et surtout, en énergie. Plus l'énergie requise pour désarchiver le bundle sur la machine de chaque client, plus l'énergie requise pour exécuter le bordel.

Le gaspillage est colossal, et si un jour, quelqu'un s'amusait à chiffrer ce gaspillage, peut-être que tout le monde en prendrait conscience et commencerait à être un peu plus responsable et économe. Y compris et surtout les entreprises : combien de millions d'euros pourraient être économisés si elles embauchaient de vrais développeurs au lieu de ces espèces d'usurpateurs qui sautent sur le nouveau framework à la mode, et qui ne savent pas coder.

Parce que, non, je suis désolé : maîtriser un framework ne signifie pas savoir coder, à partir du moment où tu ne sais pas ce que le framework produit. Pour le frontend, c'est encore plus important que pour le backend : en frontend, tu dois gérer le HTML, le CSS et le JS. En backend, PHP suffit (dans mon cas puisque je suis un dev PHP), ce qui ne m'empêche pas de savoir comment PHP fonctionne dans ses plus sombres rouages, et ce qui ne m'empêche pas de comprendre comment mon framework (Laravel) génère ce qu'il génère ni pourquoi il le fait, dans quel but.

Je vais m'arrêter là, ça sera suffisant pour me mettre à dos une grosse majorité de la communauté des devs (frontend ou pas d'ailleurs). Et je m'en tape. Ceci dit, mes commentaires ici sont relatifs à javascript parce que contextuellement, c'est ce avec quoi je travaille maintenant.

Gare à la commu go ou rust : si je décide de m'y mettre un jour, ils en prendront aussi pour leur grade.

Plus d'informations