Respecter le matériau

Depuis quelques années maintenant, lorsque l’on me pose la fameuse question du: “Et sinon, toi ? Tu fais quoi, dans la vie ?”, je réponds “des sites web, entre autres”. Et aussi, depuis que je réponds de cette manière, une certaine angoisse a commencé à naître et à prendre de plus en plus de place dans mon quotidien.

Celle de ne pas vraiment savoir faire de sites web.

Étrange, comme sentiment, pourrait-on penser. Certainement liée en partie à un syndrome de l’imposteur – dont je ne parlerai pas tout de suite puisque je prévois d’en parler ailleurs, prochainement – j’ai quand même réussi à trouver d’autres pistes, d’autres raisons claires qui nourrissent cette peur.

En fait, je vois le web et ce qui le constitue (sa sémantique, sa couche de styles, et les scripts qui viennent le dynamiser) comme les pierres et la brique qui constituent une maison. Comme un matériau, qui permet à la structure de tenir longtemps si ce dernier est de qualité, et que tout est correctement et logiquement assemblé. Il faut veiller à faire tenir les murs, à ce que le bâtiment ne penche pas, à ce que l’isolation soit bien faite.

Je trouve que c’est un peu pareil dans les métiers du développement, et je vais essayer de vous expliquer pourquoi.

---

Parle-t-on la même langue ?

Prenons l’exemple des conventions de nommage CSS. Entre OOCSS, BEM, l’Atomic… tellement d’approches et autant de façons de faire codifiées. J’ai longtemps essayé de suivre religieusement la méthode BEM, en pensant que c’était la “solution à tous mes problèmes”. BEM, pour les non-initiés, ressemble un peu à ça.

<button class="btn">
    Normal button
</button>
<button class="btn btn--secondary">
   Secondary button
</button>
<button class="btn btn--danger">
   Danger button
</button>

<header class="header">
   <div class="header__item">Index</div>
   <div class="header__item">Journal</div>
</header>

Cette logique est très efficace et évite de se poser pas mal de questions, mais comme tout, elle a ses limites. Du moins, je suis souvent amené à en rencontrer. Prenons un exemple très précis : dans un header__item, j’aimerais avoir des éléments enfants. Il faut donc trouver un moyen de les nommer. En BEM, la règle est la suivante: pas plus d’un niveau d’imbrication.

<!-- Exemple de ce qu'il ne faut pas faire selon BEM -->
<header class="header">
   <div class="header__item">
       <div class="header__item__subitem>My subitem</div>
   </div>
</header>

De ce fait, même si on trouve des éléments imbriqués les uns dans les autres, il faut continuer d’utiliser un seul séparateur en guise de nom de classe.

<!-- On est plutôt censé écrire ceci -->
<header class="header">
   <div class="header__item">
       <div class="header__subitem">My subitem</div>
   </div>
</header>

Plutôt clair, en somme. Sauf qu’en ayant beaucoup (du genre.. beaucoup) d’éléments les uns dans les autres, on commence à ne plus vraiment savoir qui est l’enfant de qui. On sait reconnaître le parent global de tout ce chaos, mais ça s’arrête là. Alors, on peut être tenté de dériver un peu de la règle et ainsi écrire :

<header class="header">
   <div class="header__item">
       <div class="header__item-subitem">My subitem</div>
   </div>
</header>

Le problème, c’est que je trouve cette syntaxe facile à confondre avec les class helpers cités plus haut (e.g les boutons et leurs modifiers). Ce que j’hésite souvent à faire, c’est de créer une nouvelle classe nommée indépendamment de son parent dans le but de pouvoir y imbriquer un nouvel enfant syntaxé en BEM.

<header class="header">
   <div class="item">
       <div class="item__title">
          <h2>...</h2>
       </div>
       <div class="item__meta">
          <div>...</div>
       </div>
   </div>
</header>

Bref: c’est facile et très tentant pour moi de me poser des questions et de perdre des heures à scroller, passer des dizaines de minute à juste réfléchir à un nom de classe, chercher la bonne pratique à tout prix, modifier la structure de mon code… pour finalement réaliser que ce n’est qu’une règle comme une autre.

Et comme toute règle, on peut se l’approprier, la contourner… et puis, “même si mon nommage CSS ne suit pas une logique implacable, on est bien d’accord que cela ne changera rien au rendu final”. Seulement, cette seule justification ne me suffit pas : je veux respecter le matériau qu’on me tient à disposition. Par souci de maintenabilité du code, par affinité avec ce qui est clair et bien organisé, et aussi un peu par peur qu’on vienne inspecter mon site pour exposer mes erreurs en plein jour.

C’est exactement pareil en ce qui concerne le layout de mes projets au moment du design. Quelle est la meilleure pratique? Maquetter sur une grille de 12 colonnes et 1180px de large? 1280? 1360? Et les breakpoints; il y en a des tas différents – je serais tenté d’utiliser les “most common breakpoints of 2021” … jusqu’à ce que j’inspecte un site que j’adore – à l’aide de la console développeur – pour réaliser que celui-ci utilise des breakpoints encore différents.

Et le doute revient à la charge.

---

Le bon outil

Travailler le matériau demande aussi forcément d’utiliser les bons outils, et j’ai tendance à penser que dans le domaine du web, c’est facile de perdre de vue les bases. D’oublier ce qui fait qu’on arrive à afficher une page ; ce qui la constitue. Ce qui soutient la structure.

Dans le front (je vais rester sur ce domaine puisque c’est ce que je fais), ça fait très longtemps que je n’ai pas parlé de HTML et de CSS avec des développeurs. Tout le monde n’a que du Javascript, GSAP, des frameworks, du client-side rendering, ou de l’AJAX à la bouche. Mais sincèrement, je dis la vérité : ça me manque de parler des bases avec quelqu’un.

Avec le temps, les développeurs détournent le web et ses outils de leur usage premiers pour toujours aller plus loin : on ne veut plus que le web soit un support d’affichage, on veut qu’il devienne un écran qui répond à tous nos désirs. 3D, scripts à tout va, graphiques dynamiques, mini-jeux interactifs…

J’admire et j’ai moi-même envie de m’essayer à tout ça. Mon intérêt pour le développement créatif grandit à mesure que je passe des heures à scroller laconiquement mon fil Instagram, et je me dis que “moi aussi j’aimerais faire ça, un jour !“. Et c’est vrai. Seulement, est-ce que le web est le bon support pour ça? Lorsqu’on surcharge un WordPress avec des extensions dans tous les sens, et une surcouche d’e-commerce puis qu’on y greffe un modèle de page à la volée avant de tout balancer en prod… n’est-il pas légitime de se demander si on utilise le bon outil ?

---

Tous les voyants au vert

Je n’ai jamais aimé être noté. Soit tu assumes, car tu clames haut et fort que les notes te passent au-dessus, soit tu réponds en ayant le regard un peu fuyant et en t’assurant de ne pas parler trop fort. On risquerait de t’entendre. Et autant être clair : je faisais parti de la deuxième catégorie d’élèves.

Dans le web, les outils d’audit et les rapports de performance me provoquent exactement le même sentiment: en quelques clics, on peut savoir – juste avec l’URL de ton projet – si tu passes les tests de Google Lighthouse ou que sait-je encore. Et attention, car ces mêmes tests sont effectués par les jury d’Awwwards pour espérer décrocher des mentions et des récompenses lorsque tu soumets tes projets là-bas: il faut avoir une bonne note.

Et même si je ne compte pas soumettre le projet, que vont dire mes collègues ou mes amis qui développent ? S’ils voient que mon site n’est pas optimisé, qu’il y a des erreurs grossières ? Quelle angoisse. Alors je plonge le nez dans des articles, dans des lectures dont je ne comprends que le tiers et qui me demandant de considérablement changer ma façon de faire certaines choses.

Parfois, on sort même complètement du code – et c’est à ce moment-là que ça me dérange. Compresser ses images à outrance car “most users won’t see any difference” ; utiliser des librairies pour faire du lazy-loading (j’ai vraiment l’impression que dès lors qu’on a un besoin, la solution consiste en une nouvelle dépendance à glisser dans son package.json), et bien d’autres choses que je n’ai même pas le courage de lister…

Quelques modifications plus tard, on re-bundle l’app et on la remet en production. Seulement 85 en “best practices” car le contenu du site prend trop de temps à apparaître à l’utilisateur ? C’est sûrement à cause du loader que j’ai mis. L’audit n’est pas au courant qu’on a parfois envie de mettre un loader avant l’apparition du site.
Ah, je vois aussi que j’ai quelques soucis de contraste de couleurs qui font baisser le score. Pas facile à vivre quand on aime expérimenter des choses dans son design.

Respirons un coup. On s’occupera d’obtenir le score parfait plus tard.

---

Pas de chemin balisé

Mais alors, que font les bons développeurs, dans tous les exemples cités au-dessus ? Les développeurs de talent, qui font du bon travail ? Vous voyez vite venir le problème : il ne peut pas y avoir une bonne réponse à cette question.

Dans le panel d’outils à notre disposition, ce sera aussi à nous de faire les meilleurs choix tout en prenant en compte le temps disponible et la faisabilité (ou non-faisabilité) de ce qui est demandé. J’ai beau prôner le code soigné et le fait d’utiliser les bons outils, je n’ai parfois pas le choix de me contraindre à une autre techno car le chef de projet le demande. Je n’ai parfois pas le choix d’utiliser un plugin plutôt que de “réinventer la roue” (vous apprécierez cette phrase utilisée en abondance dans les agences ou par les profs) quand j’estime que le temps et mes compétences à l’instant T jouent en ma défaveur.

Chacun peut (et va devoir) et trouver ses propres pistes et ses propres combats. Je ne sais pas si on doit tant s’approprier une logique que plutôt se construire la sienne avec notre expérience. Je me questionne aussi sur le fait qu’on doit s’assurer que tous les voyants sont au verts, et pas seulement s’assurer que dans ce qu’on tient à soigner dans son projet, il n’y a pas un seul voyant rouge.

C’est à moi de mettre le curseur d’exigence où je veux en fonction de ce que je cherche à accomplir avec tel ou tel projet. Oui, je vais essayer de travailler comme ça, maintenant.