Alors que je parcourais gaiement le web, je suis tombé sur un article qui m’a interloqué et qui me permet de rebondir sur une idée très grossière selon laquelle Bootstrap serait « indispensable » à l’intégration d’un projet web. Après avoir rigolé, j’ai repensé à tous les projets / gens qui m’ont tenu des propos similaires, et devant la mode grandissante j’ai préféré remettre les points sur les i.

EDIT : suite à quelques remarques, j’ai remarqué que j’ai oublié de préciser le contexte. Je ne critique ici que de l’utilisation de Bootstrap dans la réalisation et le développement de sites web, que j’oppose à celle, plus bénéfique, de l’utilisation de Bootstrap dans le prototypage et le développement d’applications web.

Avant toutes choses : non.

Premièrement il faut remettre Bootstrap à sa place, ce pour quoi il a été conçu : proposer une base graphique et technique pour intégrer des projets rapidement. Ni plus, ni moins. Il semble qu’on ait assimilé Bootstrap a une machine à faire des sites web et encore plus, des sites web responsives.

Bootstrap est un framework, une base de travail utile et fiable pour un projet qui aurait été pensé dans sa globalité pour être développé via Bootstrap. Toute l’équipe doit préparer un projet pour être mis en place sous Bootstrap. Combien de fois je vois des projets, ou le designer bosse à partir de zéro dans Photoshop, et qu’on demande ensuite à l’intégrateur d’intégrer avec Bootstrap :)

Pour bien se lancer dans ce type de projet, il faut donc que, en amont :

  • le concepteur prenne en compte, par exemple, les modifications de comportement des blocs proposés par Bootstrap (pour ne pas proposer des écrans qui iraient complètement à l’opposé de la logique de Bootstrap)
  • le designer se cale au maximum sur la grille et les éléments de Bootstrap, sinon même topo

Ce qui veut simplement dire que si on ne suit pas la logique de Bootstrap, ça ne sert à rien d’utiliser Bootstrap : pure perte de temps (à recaler des éléments qui n’ont pas du tout été prévu comme ça dans le framework – et donc via un effet boule de neige, devoir tout retester / réimplémenter pour les différents appareils).

Deuxièmement : non.

Perte de temps et perte de performance : en plus d’être lourd en terme de taille pour le CSS et le JS (autour de 150ko minifié), Bootstrap s’appuie sur un code HTML extrêmement surchargé, à savoir qu’on hésite pas à rajouter des éléments HTML pour créer / adapter la mise en forme.

Donc si quelqu’un me dit qu’utiliser Bootstrap pour un site vitrine de 5 pages est un bon choix technique, je dis non (le site sera juste à peu près 3 fois plus lourd qu’il ne le devrait).

Troisièmement : non.

Perte de performance, perte de temps et perte de qualité. Concrètement, j’ai vu quelques projets où on évite de penser à la conception d’une interface pour plusieurs types d’appareils en se disant au final que « tout ça, c’est Bootstrap qui va le gérer ». Donc, on pense le site, on fait la créa du site et on l’envoie à l’intégrateur, lui reléguant toute la responsabilité de mettre en place le responsive. C’est normal, c’est lui qui met en place Bootstrap. Hmm.

Quatrièmement : toujours non.

Le problème de Bootstrap, c’est que beaucoup d’ « intégrateurs » s’y sont mis corps et âmes en sautant une étape : HTML et CSS. Concrètement, il n’est pas rare aujourd’hui de croiser des personnes qui pourront vous intégrer n’importe quoi avec Bootstrap. Enlevez-leur, ils ne comprennent plus rien à HTML et CSS. Flux HTML, logique de positionnement, comportement des éléments, ça passe à la trappe.

Cinquièmement : pourquoi pas ?

J’utilise Bootstrap aussi, mais pas forcément pour réaliser des sites web. Bootstrap est un gain de temps et une base solide pour le prototypage par exemple, ou pour avoir une interface à peu près clean quand on développe un outil et qu’on a pas trop de temps à mettre sur la créa (dans une logique de test, en fait). Preuve de ma bonne foi, je l’utilise aussi sur Vinylzilla : en effectif réduit, nous sommes parti sur une base Bootstrap, légèrement modifiée. Parce qu’on ne peut pas être au four et au moulin : ça répond à nos exigences, on voulait se concentrer sur le fonctionnel, sur l’ergo, en ayant une interface à peu près sympa. Bootstrap (mais on aurait pu aussi utiliser Foundation ou un autre) faisait l’affaire.

Donc finalement, on fait quoi ?

Chaque projet web a ses contraintes, ses objectifs : il faut faire le point et trouver les meilleures réponses techniques. Par expérience, dans beaucoup de situations, Bootstrap (ou Foundation ou autre) est très loin d’être recommandable : pré-processeurs CSS (Sass, Less), des post-processeurs CSS et des outils de build (Grunt, Gulp) pourront être à la base d’une solution beaucoup plus souple et plus légère (pour l’utilisateur) pour intégrer un projet web. Personnellement, à partir de cette base technique, au fur et à mesure des projets, j’ai pu identifier des besoins, des classes que je réutilise 100% du temps. C’est très léger, en Sass / Compass, ça correspond finalement à un reset CSS (Eric Meyer, parce que c’est le meilleur… bon je sors), quelques classes de positionnements / de float, quelques mixins, point. En laissant à GruntJS le soin de compiler, de vérifier (via JSHint) mon code JS et le concaténer / minifié. Ce site par exemple utilise 8ko de CSS. Je vous laisse faire la différence si j’avais utilisé Bootstrap.

Bootstrap est un très bon outil, mais il n’est pas magique et ne dispense pas d’apprendre HTML/CSS (et vice-versa : ce n’est pas parce qu’on connait Bootstrap qu’on est intégrateur ou qu’on connait HTML / CSS). Bootstrap est très bien, mais il ne convient vraiment pas à tous les projets, loin de là. Et comme tous les outils, s’il n’est pas foncièrement mauvais, beaucoup de gens l’utilisent mal, pour tout et n’importe quoi.

S’il n’y a qu’une chose à retenir, posez-vous juste la question en début de projet : est-ce que Bootstrap va nous servir ou nous desservir ? Il faut peser le pour / le contre et comparer avec d’autres choix et solutions techniques. Si vous le choisissez par « facilité technique », parce qu’il serait plus long / plus difficile de passer par du code natif, ou d’autres outils (pré-processeurs / post-processeurs / outils de build), malgré les inconvénients cités précédemment, c’est qu’il faut peut être reprendre les bases.