Du code front-end fait maison

Il y a quelque temps, j’ai voulu faire changer les fenêtres de ma maison. Pour plusieurs raisons, je souhaitais avoir des fenêtres en bois. J’ai donc contacté un menuisier pour lui demander un devis. Il m’explique alors qu’il ne fait pas de fenêtres en bois, mais uniquement en PVC et aluminium. Il commande des fenêtres à un fabricant et vient les poser.

Un menuisier qui ne travaille pas le bois, ça m’a perturbé pendant quelques jours avant de prendre conscience que mon métier se dirigeait lentement vers la même chose.

Actuellement, trop de développeurs front-end ne font plus de HTML, CSS ou de JavaScript. Ils utilisent plugins, frameworks et autres bouts de code « prêts à l’emploi ». Ils personnalisent et assemblent le tout pour arriver aux résultats demandés par la spec et pour que cela ressemble le plus possible à la maquette. La partie HTML/CSS/JavaScript de tout ça c’est juste la connexion et la personnalisation de ces différents éléments. Pourquoi faire comme ça au lieu d’écrire du code à la main ? Voyons les principales raisons :

Gagner du temps ?

La raison principale de cette tendance est le gain de temps par rapport à l’écriture du même code à la main. Et ça a du sens, si vous utilisez du code déjà prêt au lieu de l’écrire from scratch, vous gagnez du temps pas vrai ? Effectivement, si vous êtes très chanceux et que vous trouvez un plugin qui correspond exactement à vos besoins, qui fasse exactement ce que vous en attendez, qui s’installe et se configure facilement et n’a pas de bug bloquant pour vous, alors oui vous gagnerez du temps.

Mais dans la vraie vie ça n’est pas comme ça que ça se passe. Vous n’avez jamais perdu un temps considérable à juste configurer un plugin ? Ça ne vous est jamais arrivé, après plusieurs heures d’utilisation d’un plugin, de vous rendre compte qu’une de ses fonctionnalités ne marche pas comme vous l’espériez ? De tomber sur un message d’erreur improbable que vous semblez être le seul à avoir ?

Cela m’est arrivé de trop nombreuses fois, et à chaque fois j’aurais gagné énormément de temps à tout écrire à la main plutôt que perdre mon temps à chercher à adapter l’outil d’un autre à mes besoins.

J’ai tendance à penser qu’on gagne du temps à écrire du code à la main plutôt que d’importer du code déjà prêt. Peut-être pas immédiatement, car un plugin sera présentable plus rapidement. Mais sur le long terme, si on inclut le temps passé à se casser les neurones pour adapter, corriger, et faire évoluer, on gagne à écrire du code maison.

Obtenir du code de qualité ?

Bien souvent, en choisissant un plugin sur npm ou autres, on se dit que le développeur qui a écrit ce code l’a testé, re-testé, l’a fait tester à d’autres personnes et l’a soumis à une revue de code. On se dit que si plusieurs milliers de personnes l’ont téléchargé c’est qu’il fonctionne bien, non ? On peut aussi supposer que ces personnes ont remonté les éventuels problèmes au développeur qui les a aussitôt corrigés.

Et pourtant, que vous soyez débutant ou confirmé, en écrivant votre code à la main vous produirez du code de meilleure qualité que le plugin en question.

Votre code comportera uniquement les fonctionnalités dont vous avez besoin. Il ne supportera que les navigateurs que vous devez supporter. Vous ne subirez pas les bugs que rencontrera un plugin qui doit fonctionner partout et dans toutes circonstances. Votre code sera accessible à vos collègues développeurs qui pourront le modifier et lui ajouter des fonctionnalités futures. Votre code sera plus lisible pour vous et vos collègues car il respectera la norme mise en place dans votre équipe.

Vous ne pouvez pas faire ça avec du code importé, car si vous le modifiez vous perdrez vos modifications lors d’une future mise à jour. Vous ne le mettez pas à jour ? Vous ne mettrez pas, non plus, à jour les autres plugins qui dépendent de lui et vous vous exposez à des éventuelles failles de sécurité.

D’un point de vue des performances, c’est aussi extrêmement bénéfique. Une fonctionnalité codée à la main sera beaucoup moins lourde qu’un plugin importé qui est censé faire la même chose.

Ne pas réinventer la roue ?

Pourquoi s’embêter à coder un slider, un système de popin ou encore un date picker alors qu’il en existe déjà des centaines ?

Car en plus de gagner du temps au final et d’écrire du code de meilleure qualité pour votre projet, vous apprendrez. Vous ferez des erreurs, vous bloquerez, vous progresserez. Vous découvrirez des choses, parfois simples que vous étiez seul à ignorer, et parfois moins évidentes qui vous donneront des idées d’optimisations sur d’autres projets. Dans tous les cas vous apprendrez plus de choses intéressantes qu’en faisant un « npm-install-mais-putain-pourquoi-ça-marche-pas ».

Le plugin est déjà présent sur le projet autant l’utiliser non ?

J’ai connu beaucoup de projets dans lesquels un plugin, que tout le monde rechigne à utiliser, est présent depuis le début, mais comme il est utilisé partout alors on continue de s’en servir.

Effectivement, à court terme, c’est la meilleure solution. Le plugin est déjà prêt, il est déjà utilisé à plusieurs endroits du projet, d’autres se sont cassés la tête avant vous pour tout faire fonctionner. Ce n’est pas pour autant que ce sera facile et rapide, mais vous avez déjà le chemin de tracé.

Mais est-ce une raison valable pour ne pas améliorer les choses ? Rien ne vous empêche de développer en parallèle une meilleure solution et de l’appliquer petit à petit. Pendant quelques temps les deux versions peuvent cohabiter jusqu’à ce que la nouvelle prenne entièrement la relève. Au final, tout le monde sera content et gagnera du temps à l’avenir.

Plusieurs outils sont très utilisés dans les projets web récents et amènent leur lots de bonnes idées qui sont sur-utilisées et deviennent de mauvaises pratiques :

Bootstrap

Bootstrap est énormément utilisé dans les projets web récents, et à l’instar de jQuery, il devient presque indispensable à chaque projet. On voit de plus en plus d’intégrateurs mettre en avant leur maîtrise de Bootstrap, et certains affirment « coder en Bootstrap ».

Cet outil est génial pour créer rapidement une interface web sans se prendre la tête. Sans contrainte graphique, on peut rapidement mettre en place une interface propre et fonctionnelle. Si vous devez créer une application dont l’interface n’a pas été imaginée graphiquement par un UX designer, utilisez Bootstrap, vous gagnerez du temps.

Mais c’est à ça que sert Bootstrap et à rien d’autre. Utiliser Bootstrap pour créer un site ou une application tout en respectant une maquette et un cahier des charges est donc une perte de temps et de performance. Cela revient à superposer deux interfaces sur votre site.

Imaginons un projet qui consisterait à fabriquer une voiture en respectant le travail fait en amont par un designer. Est-ce une bonne idée de prendre une autre voiture et de venir coller par dessus des morceaux de portière, de coffre et de capot pour qu’elle ressemble à celle souhaitée ? Même en supposant que le résultat soit visuellement acceptable, la voiture ainsi conçue serait deux fois trop lourde et deux fois trop imposante. Vous voudriez conduire une voiture comme ça ? Vos utilisateurs non plus.

Cela parait bête de penser à fabriquer une voiture comme ça, et pourtant c’est la logique appliquée à trop de projet web. Pourquoi s’embêter à fabriquer une portière alors que ça existe déjà ? C’est vrai, une portière c’est juste un bout de tôle avec une charnière et une poignée. Alors pourquoi les constructeurs automobiles ne font-ils pas comme ça ? Car aussi simple qu’une portière puisse être dans l’absolu, elle est repensée et recréée afin de s’adapter au design et aux contraintes de chaque nouveau modèle de voiture. C’est pareil pour votre projet web, le système de lightbox dont vous avez besoin est différent de celui d’un autre site même si les deux font la même chose.

les gestionnaires de paquets

Les gestionnaires de paquet comme npm, permettent très facilement d’importer des packages de code JavaScript, front-end ou back-end. Pour quasiment n’importe lequel de vos besoins dans un projet web, il existera à coup sûr un « quelquechoseJs » trouvable sur npm ou ailleurs. C’est tellement facile qu’on en oublie le coût de l’ajout de dépendances dans un projet, particulièrement pour du développement front-end. A chaque installation d’un package, il y a un grand nombre de lignes de code inutiles que votre utilisateur sera obligé de télécharger à chaque utilisation de votre site. Et ce poids augmente de manière exponentielle à chaque ajout de paquet. Sachant qu’il existe une inter-dépendance entre beaucoup de ces packages, imaginez le poids des fichiers à télécharger que vous faites subir à un utilisateur ayant une mauvaise connexion.

Ce surplus de code, vous ne l’avez pas en écrivant du code à la main, vous ne dépendez de personne pour votre projet.

Aujourd’hui nous passons presque plus de temps à préparer un environnement de travail, qu’à réellement travailler. Pendant que vous vous cassez la tête à réparer un environnement ou à faire fonctionner un plugin, aucune valeur n’est ajoutée à votre projet. Rendez-vous service ainsi qu’à vos collègues et à vos clients : écrivez du code from scratch au maximum.

Créer

J’aime écrire du code from scratch, et la raison principale à ça ne figure pas parmi toute celles que je vous ai citées précédemment. Je trouve ça valorisant. Tout d’abord pour moi-même, mais aussi pour le projet.

Valorisant pour moi car si je suis devenu développeur, ce n’est pas pour assembler des bouts de code, mais pour les créer. Je veux créer. Créer des interfaces, des applications, des expériences utilisateur.

Valorisant pour le projet projet, car plus il contient de code maison, plus il est unique et donc plus il a de valeur. Je n’ai jamais compris comment on pouvait valoriser une application en y assemblant des bouts de codes qu’on trouve sur toutes les autres applications.

Pour en revenir à mes fenêtres, j’ai finalement trouvé un menuisier qui a pu me fabriquer les fenêtres que je voulais. Ça m’a coûté moins cher que ce que me proposaient des concurrents qui achetaient les fenêtres chez un fournisseur, j’ai eu exactement ce que je voulais et lorsque que j’ai une idée d’amélioration ou s’il y a un problème, je ne m’adresse non pas à un intermédiaire mais à la personne qui les a créées. Tout est donc plus facile et plus fluide. Et ça me laisse espérer que tous les projets web se déroulent aussi bien.

9 commentaires

  • Pauland dit :

    Bien le vieux ! On a le même état d’esprit à ce que je vois !
    Ça me donne souvent le sentiment de passer pour le « vieux » qui ne veut pas faire comme tout le monde quand je dis que « si je peux me passer d’un max de dépendance, je le ferai ».
    J’en vois parfois qui importent des libs, de plusieurs dizaines de millier de ligne de code, juste pour avoir accès à une méthode dans un Utils…

  • T. dit :

    Putain. T’es mon héros. Non j’abuse mais ca fzit 6 ans que je refuse de toucher aux cms style wordpress et autres. Je vais poster cet article à tous les gens qui me font chier

  • humanize dit :

    je me retrouve dans cet article, bravo pour cette déclaration!
    PS : et bravo pour le fait de ne pas avoir de trackers sur cette page, c’est rare et c’est beau

  • Miloon dit :

    Pareil. En ce moment, je suis justement dans un cadre de travail où on m’incite, on m’encourage à tout coder moi-même et je me retrouve dans tout ce qui est dit.
    Je vais d’ailleurs mettre un lien vers cet article dans mon futur post de blog ! Merci ! <3

  • Jean dit :

    Aaaah moi qui me sent différent (et isolé) quand je dis que je veux coder from scratch, « mais t’es fou y’a plein d’outils qui le font plus vite et mieux » ! Ben oui mais je suis développeur, pas joueur de Légo… Le plus rude c’est quand on dis en entretien « je maîtrise le langage truc », de suite la question qui suit est « oui mais le framework machin ? et les 10 autres qui en dépendent ? » Ah ben non, donc je suis pas retenu pour la mission 🙁

  • […] Du code front-end fait maison – un article à lire […]

  • Développeur web depuis plus de 17 ans, mais surtout toujours passionné, je me reconnais à 100% dans cet article.

    On pourrait tracer 2 courbes (plugin pour l’une, dev maison pour l’autre). Je pense que la 1ère serait assez stable, quand la 2ème, qui serait au début bien plus faible, permettrait de s’envoler dans ses capacités techniques. Bien sûr, ca prend plus du temps, il faut tester, apprendre, constamment. Mais ensuite, on n’est presque plus limité.

    Nos devs, c’est du 100% maison (on utilise juste jquery). Le dev web permet une création que certains framework ou lib peuvent bloquer.

  • shevabam dit :

    Excellent article dont je partage totalement le point de vue !

  • walid dit :

    je suis d’accord sur le principe mais la vie de tous les jours c’est autre chose on a des contraintes budgétaire et du temps.
    le vrai problème c’est le client pour revenir à ton exemple si le client veut du vrai bois il paye le prix mais le souci c’est que les gens ont envie du vrai bois au prix ikea et la c’est pas possible

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *