Mon propos de l’époque était un peu brouillon. L’article était court, avec des analogies bancales (j’ai quand même réussi à parler de construire la Tour Eiffel avec des allumettes en conclusion !) mais l’idée était plutôt simple : malgré les outils qui permettent d’industrialiser le développement Web, il est parfois important de maîtriser les bases.

Une partie de la communauté que je suis sur Twitter a tendance à se diviser dernièrement sur l’utilisation de certains outils, certains arguant qu’ils ne servent à rien, d’autres qu’ils sont au contraire essentiels à leur travail/projet. Et j’aurais tendance à dire qu’ils ont raison dans les deux cas.

L’industrie a besoin d’outils spécifiques

Toutes les entreprises n’ont pas les mêmes besoins : certaines sont spécialisées dans le développement massif, leur objectif est alors de produire vite et/ou pas cher. Les frameworks leurs seront alors essentiel pour gagner en efficacité et répondre aux exigences de leurs clients dans des délais ou coûts serrés.

Beaucoup d’outils servent d’ailleurs à ça : être plus efficace dans les situations prévues par celui-ci en éliminant beaucoup de tâches répétitives et fournissant un socle technique avec lequel construire. Pas forcément à satisfaire un besoin de façon unique, qui est plutôt le rôle du développeur du produit (comprendre le site ou l’application vendu au client).

Les frameworks et librairies vont alors permettre aux développeurs de travailler avec une base établie, connue et documentée plutôt qu’avec une structure maison qui réinvente la roue d’une nouvelle façon.

De la même façon qu’un professionnel du bâtiment va utiliser des équipement et machines également utilisés par leurs concurrents plutôt que de créer sa propre perceuse ou presser ses plaques de BA13, un développeur peut utiliser des composants pré-développés adaptés à son besoin.

L’artisanat reste essentiel

Comme dans d’autres domaines, les artisans ne répondent pas forcément aux mêmes demandes : plutôt que de cherche à produire de façon formatée, ils répondent à des besoins plus spécifiques, avec un résultat sur mesure.

Les outils industriels restent disponibles si besoin (après tout les menuisiers aussi utilisent des machines pour se faciliter la tâche), mais le travail est plus minutieux avec une attention plus poussée sur les demandes exactes du client. La priorité est alors moins le prix ou la rapidité mais le résultat sur mesure qui va durer et pourra être maintenu.

Il ne s’agit pas de faire du prêt-à-porter ou de simplifier le processus de production, mais bien de satisfaire le client avec un résultat de qualité. Parfois en passant plus de temps sur un détail qui peut paraître insignifiant (comme refaire intégralement une interface d’admin très peu utilisée ou ajouter des Easter Eggs bien cachés), mais qui rendra le produit final unique.

Sur le Web maîtriser les techniques de bases (HTML, CSS, JavaScript) peut aussi permettre de mieux comprendre comment les frameworks ou librairies fonctionnent : en connaissant les mécanismes sous-jacents on pourra plus facilement passer d’un outil à l’autre. Et on pourra plus facilement investiguer en cas de bug.

Le concours de hype des outils Web

Ces dernières années le nombre de frameworks et librairies front (JS ou CSS) a explosé et chaque outil a ses particularités. Il devient alors compliqué de s’y retrouver, de tout suivre. S’en suit alors un concours de notoriété (ou hype dans le jargon), avec chaque communauté qui porte son outil, en fait la promotion… parfois de façon excessive (certaines communautés deviennent parfois agressives ou violemment défensives lorsque leur outil préféré est critiqué).

Donner de la visibilité aux outils est important, les partager est essentiel surtout s’ils peuvent être utiles à d’autres : après tout le Web a une culture open source assez prononcée qui va en ce sens.

Mais tout le monde ne peut pas se permettre de connaître chaque outil ni de les tester : il faut donc savoir faire preuve de bienveillance et être capable d’expliquer les avantages et les inconvénients de chaque outil, en toute transparence. Aucun outil n’est parfait en toute situation, quel que soit le métier que vous exercez.

Il faut aussi savoir accepter la critique : quand votre outil préféré n’est pas adapté à certaines situations ou a une valeur ajoutée trop faible pour gagner en popularité ce n’est pas une catastrophe. Vous avez alors le choix de vous concentrer sur une niche qui vous sera reconnaissante d’avoir son besoin à cœur ou de revoir votre outil pour l’adapter à d’autres besoins (potentiellement au risque d’en faire une copie d’un autre ou de le rendre lourd).

Trouver son équilibre

Alors oui, j’ai utilisé Angular pendant des années (et je ne le regrette pas, j’adore TypeScript et ai découvert les Observable grâce à ça) et ai même formé des équipes dessus. J’utilise même Laravel sur ce site/blog que vous êtes en train de lire.

Mais j’ai aussi fini par supprimer Tailwind qui servait sur l’interface de gestion pour passer à du SCSS maison : le HTML est plus lisible, simple à maintenir et utilise un nommage plus sémantique sans surcouche. Le processus de build a aussi été accéléré et le CSS final est plus léger. Oui ça m’a pris près de 3 jours, mais le résultat est comme je le souhaite (finalement être son propre client a ses avantages).

Vous avez donc bien lu le titre : en démarrant un nouveau projet je ne cherche pas à utiliser l’outil qui me plait, mais celui qui sera le plus adapté au projet. Et s’il s’agit de créer un simple blog personnel sans gros besoin, je m’en tiendrai à quelque chose de très basique comme Jekyll, tant pis si je n’ai toujours pas utilisé React ou votre framework préféré. Je n’en ai juste pas besoin, ce n’est pas une attaque personnelle.

J’en profite d’ailleurs pour remercier les clients qui m’ont fait confiance en me donnant quasi carte blanche pour améliorer leurs projets, les faire monter en qualité, ajouter des tests unitaires pour prévenir les régressions dans le futur… Vous êtes géniaux et j’espère de tout cœur que vous continuerez à faire appel à mes services ! ❤️