L’effet rebond des scripts compilés

Depuis quelques années, la grande tendance d’écriture des scripts dits statiques – javascript et CSS – va vers les versions compilées. C’est à dire qu’entre l’écriture par un humain et l’exécution par le navigateur, il y a un traitement automatisé. Pour faire vite, cela apporte trois grands intérêts :

1. Le script peut être minifié. processus de compilation retire toute mise en forme superflue, dont une machine n’a faire. Dans sa version lisible, le code peut donc contenir des commentaires à foison, une indentation et des sauts de ligne à outrance, le rendant plus esthétique et facilement maintenable, alors qu’une fois réduit, il sera compressé au strict minimum, optimisant ainsi le temps de chargement. Moins de trafic, moins de ressources consommées
2. Cela permet l’utilisation de nouvelles syntaxes, plus concises pour la personne qui écrit, tout en générant du code « plat », standard pour le navigateur.
3. Le code source peut être découpé en plusieurs fichiers et donc plus facile à maintenir.

Outre le gain de taille, cela permet d’accroître significativement la célérité de développement.

Mais gare a l’effet rebond.

En effet, l’utilisation de langages simplifiés peut facilement amener à perdre de vue qu’une fois compilé, le résultat peut s’avérer plus gourmand que prévu.

Un bon exemple est là version compilée de la CSS : le SCSS.

Par exemple, cette portion de CSS indiquant que les liens d’un bloc de classe « article » doivent être affiché en bleu, s’écrit comme suit :

div.article a{
   color: #2266cc;
}

Si l’on veut que le bloc lui même ait un fond jaune, on ajoutera ceci :

div.article{
    background:#ff0000;
}

Total : 38 + 40 = 78 caractères

Les deux règles doivent être énoncée de manière linéaire.

En SCSS, cela peut être écrit de manière imbriquée :

div.article{
    background:#ff0000;
    a{
        color:#3366cc;
    }
}

C’est plus facile a lire, et plus concis. Une fois compilé, le code généré deviendra :

div.article{background:#ff0000;}div.article a{color: #2266cc;}

Cela correspond exactement au premier exemple en CSS, mais avec seulement 62 caractères (tous les espaces ont été supprimés). Gain : 37,3%

Le soucis, surtout lorsque l’on travaille sur un fichier avec beaucoup d’instructions, est que l’on peut perdre de vue ce qu’il se passe. Par exemple, si l’on veut maintenant indiquer que les paragraphes de classe « jaune » doivent aussi s’afficher sur fond jaune, on peut être tenté de « juste » ajouter l’instruction à la suite de la déclaration des bloc article.

div.article, p.jaune{
    background:#ff0000;
    a{
       color:#3366cc;
    }
}

Or, Cela va se répercuter sur l’ensemble des sous règles :

div.article,p.jaune{background:#ff0000;}div.article a,p.jaune a{color: #2266cc;}

Ce qui donne 80 caractères, alors qu’en pure CSS, on se serait contenté du nécessaire avec 85 caractères :

div.article, p.jaune{
    background:#ff0000;
}
div.article a{
    color: #2266cc;
}

Le gain effectif tombe a 11,5%

Pour peu que l’on ne s’en rende pas compte, et que l’on ait déclaré de nombreuses sous règles, la version compilée va croître de manière exponentielle jusqu’à arriver à un gain négatif.

L’exemple fonctionne également très bien avec webpack, qui peut générer dans certains cas un fichier compilé minorité plus lourd que sa source.

Certes le confort d’écriture sera conservé, mais l’impact en terme de ressources s’en ressentira.

L’enjeu pour éviter ce piège est de toujours garder en tête la finalité et surtout une vue d’ensemble du projet.