Les frameworks CSS

 

Aujourd’hui, je me permet de vous exposer mon point de vue sur les frameworks CSS. Avantages, inconvénients, je vais essayer de tout détailler ici.

Rappel sur les frameworks CSS

Apparus il y a déjà pas mal d’années et rendus célèbres notamment grâce à Bootstrap, les frameworks CSS ont été créés pour accélérer le développement front-end et améliorer la maintenance des sites, en utilisant des classes réutilisables.

Leur succès est également dû aux navigateurs obsolètes (comme Internet Explorer). Il suffit alors d’importer un ‘reset.css’ et comme par magie, tous les navigateurs se comportent de la même manière sur votre site.

Différents types

Comme pour tous les langages, il existe plusieurs types de frameworks CSS :

  • Les complets : Comme Bootstrap, ils s’occupent de tout : Boutons, menus, typographie, formulaires, responsive, … Ces librairies donnent rapidement un look complet à votre site web en fournissant des tas de gadgets. Il faut cependant pas mal de temps avant d’assimiler toutes les possibilités et comment les mettre en place.
  • Les rapides : Ceux-là ne s’occupent que de l’essentiel : Positionnement, responsive, formulaires et typographie.
  • Les grilles : Plus légers, ils ne s’occupent que du coté positionnement et généralement de l’affichage sur mobiles/tablettes. KNACSS en est un bon exemple, même si les possibilités ont tendances à grandir au fil des versions.

Tous ces frameworks ont tout de même des avantages et des inconvénients, c’est ce que nous allons voir.

Avantages

Toutes ces librairies offrent plusieurs avantages intéressants à ne pas négliger. Je vais passer rapidement dessus. Étant donné que je pars du principe où vous ne dormiez pas dans une grotte cette dernière décennie, je suppose que vous les connaissez 😉

  • Rapidité : Pour un développeur back-end, le fait de pouvoir mettre en place un design en 10 minutes est vraiment intéressant, surtout s’il n’est pas à l’aise avec le CSS.
  • Responsive : Pratiquement tous proposent d’afficher correctement votre site sur mobile en ajoutant quelques noms de classes.
  • Design : Pour les frameworks qui incluent un design sur les menus, formulaires etc, ceux-ci sont généralement en accord avec les tendances actuelles.
  • Reset CSS : Malgré le fait que tous les navigateurs actuels soient respectueux des standards, il subsiste quelques internautes ne souhaitant pas (ou n’ayant pas la possibilité) évoluer vers des versions plus récentes. Le fait de rendre compatible tous ces navigateurs est un bon point bien sûr.

C’est vrai que tout cela a de quoi ravir un dév. Pouvoir prioriser le fonctionnement du site sans pour autant négliger le design, c’est assez tentant ^^

Inconvénients

Voilà la partie intéressante ^^ Tous ces frameworks possèdent des gros points négatifs à mes yeux, en voilà les principales :

Lourdeur et sémantique

Tout d’abord, je trouve que couplé à un framework CSS, le code HTML en devient beaucoup trop lourd. Voici un code extrait de MaterializeCSS :

WTF ? Toutes ces classes définissent uniquement le comportement des div sur les types d’écran, on a pas encore intégré le design..
A mon sens, ce nommage est contraire à la sémantique de CSS : Il ne faut pas utiliser des classes comme un comportement spécifique, mais nommer ses classes en fonction de ce qu’elles représentent.

Un autre exemple du même genre :

Là encore, la classe « red » n’est pas adaptée et est sémantiquement incorrecte. Si l’on souhaite qu’un bouton soit rouge parce qu’il annule une action, voilà un meilleur exemple :

Ici, le code est plus clair, et bien plus maintenable. Mais pour autant, ça n’est pas beaucoup mieux..

Sémantique, le retour

Dans le dernier code, n’y a t-il rien qui vous choque ? Les frameworks CSS donnent de mauvaises habitudes, notamment au niveau de la sémantique HTML. Avec HTML5, nous avons vu apparaitre des éléments comme les « nav », « sidebar », « article », .. Pour autant, ce n’est pas un réflexe pour tout le monde, et je pense que ces outils en sont la principale raison.

Dans le code plus haut, ne serait-il pas mieux de remplacer le « input » par un « button » ? Bien sûr que si. Mais avec certains frameworks, si jamais je transforme mon code ainsi :

Mon bouton n’est plus pris en charge, ce qui pousse à ne pas utiliser les éléments comme il le faudrait.

Un autre exemple, vu je ne sais plus où :

Ici, un élément « nav » n’aurait-il pas plus sa place qu’un « div » ? Clairement, si. Mais la possibilité de planter le design est fort si on ne respecte pas à la lettre la doctrine que nous impose le framework. Et je ne parle pas encore de ceux qui modifient le DOM par Javascript..
En fait si, parlons-en.

jQuery

Mettons les choses à plat : Je n’ai rien contre jQuery. Au contraire. N’étant pas un grand passionné de JS, cette librairie me fait gagner énormément de temps. Mais les frameworks en abusent..

Il y a une pratique que je n’apprécie pas dans tout cela, c’est la manipulation du DOM pour le design : On ajoute des classes avec jQuery, des icônes, des divs, etc afin de donner à l’utilisateur du framework moins de code à taper.
Mais que se passe t-il si l’utilisateur a désactivé Javascript dans son navigateur (ça existe..) ? Le site devient alors moins joli, moins fonctionnel, allant parfois jusqu’à rendre la navigation impossible..

Et pour en revenir à ce que je disais au dessus, si vous transformez un <div class="menu">  en <nav> , soyez sûr que votre joli menu déroulant transformé par JS ne déroulera plus rien du tout..

Maintenabilité et évolution

Reprenons notre exemple du bouton rouge. J’imagine alors que dans tout le site, on a des <input class="button red"> .
Puis la mode évolue, vous souhaitez alors modifier votre thème, et remplacer la couleur rouge de votre bouton par du bleu. Comment allez-vous procéder ?

La première solution est de passer tous vos input en class="blue" . Ça en fait du taf, pas génial..

L’autre solution plus rapide est de modifier directement la classe « red » dans le CSS, et lui appliquer un background bleu. Pas très logique tout ça..

Là où je veux en venir, c’est qu’avec le nommage qu’impose les frameworks CSS, il devient vite très fastidieux de faire évoluer son site. Et ne croyez pas que cela s’arrête aux choix des couleurs, il en va de même pour les tailles (  <span class="col-6">  ) et d’autres éléments..

Mon site ressemble à celui du voisin !

Un autre inconvénient des frameworks CSS (ceux qui proposent un design prêt à l’emploi) est qu’au final, tous les sites créés avec le même outil ont la même allure. Même si le thème vous plait, on a au final un tas de site sans identité visuelle, qui ne marque pas le visiteur et qui, l’air de rien, laisse un aspect assez immature..

Bien sûr, vous avez possibilité de le modifier ou changer de thème. Mais avouons-le, un site sous Bootstrap modifié aura toujours une allure de Bootstrap..

Bashing gratuit ?

Non. Il ne s’agit pas du tout de dénigrer les utilisateurs des frameworks CSS ni même les auteurs, mais simplement vous donner une réflexion personnelle sur leur utilisation. J’en ai utilisé, j’en suis revenu. Et vous ? 😉

7 Commentaires

Ajouter un commentaire

  1. Bonjour,

    Je tiens à rebondir un peu sur ton article et ainsi ouvrir un petit débat ^^

    Tout d’abord, concernant la sémantique, il faut savoir qu’elle a été largement amélioré, et la plupart utilise les nouvelles balise html5. Concernant bootstrap par exemple (c’est le seul que j’ai déjà utilisé), le passage de la version 2 à la 3 a été quand même un vrai bon en avant tant la version 2 était lourde (niveau sémantique).

    Ensuite un framework CSS peut être vraiment très utile pour des petites équipes de développement (2 à 3 développeurs) où aucun n’est intégrateur, cela permet d’avoir un cadre de travail et ne pas se retrouver avec des feuilles CSS anarchique et non maintenable.

    Pour moi, l’utilisation d’un framework css n’est vraiment utilise que dans certaines situations (applicatif avec petite équipe) et est évidement à partir pour une agence qui fait du site web.

    • Bonjour,
      Merci de ton commentaire constructif. Si tu aimes les débats, tu seras toujours le bienvenu ici 😉

      Tout d’abord, il faut savoir que dans le billet, je ne vise aucun framework en particulier mais tous, qui ensemble, regroupent tous ces inconvénients.

      Concernant Bootstrap plus spécifiquement, il a en effet évolué dans le bon sens au niveau de la sémantique HTML. Par contre, niveau CSS, ça ne s’arrange pas.
      En regardant le code de la documentation, on peut lire par exemple :
      <div class="row">  <div class="col-sm-5 col-md-6">...</div>  <div class="col-sm-5 col-sm-offset-2 col-md-6 col-md-offset-0">
      Sérieusement ? Ici tu as déjà 4 classes (ce que je considère comme un maximum) uniquement pour le positionnement d’un div. Si en plus tu dois y rajouter tes classes, ça devient illisible, si ça ne l’est déjà.

      Selon moi, et c’est là où tous les frameworks pêchent, c’est qu’il ne doit pas y avoir (autant) de classes génériques. Le nom de la classe doit refléter ce qu’est l’élément, et ne pas être un détail de son aspect/positionnement/fonctionnement.

      Ensuite, en ce qui concerne l’utilisation de frameworks pour des petites équipes sans intégrateurs, je serai tenté de te dire oui.
      Mais si tu as de bonnes connaissances en langages de programmation, même sans connaitre le CSS, tu dois pouvoir structurer un minimum tes fichiers, séparer le design du positionnement par exemple.
      Ce que je considère comme ‘non maintenable’, ce sont justement les frameworks. Qu’en est-il lorsque les utilisateurs sont passés de Bootstrap 2 à 3 ? Ces 2 versions ne sont pas compatibles, pas génial. Et j’imagine qu’il en sera de même avec la V4.

      Enfin, pour les agences, bien évidemment je ne peux que leur déconseiller de partir sur un tel outil 😉

      Pour compléter mes dires, je tiens à préciser 2 choses :
      J’ai appris HTML et CSS avant PHP, ce qui me donne peut-être une fausse opinion sur la facilité de s’occuper soi-même du CSS.
      Enfin, le billet a été écrit avec ce que je voyais des gros frameworks, mais aussi ceux des amateurs qui essayent de nous vendre le leur. Gardez-le pour vous ! ^^

    • Bonjour,

      je ne suis pas tout à fait d’accord,

      presque tous ces frameworks restent des soupes de div, en particulier bootstrap, même aujourd’hui,

      et une équipe de 2 à 3 développeurs qui n’intègre pas d’intégrateur, bah c’est sans doute mal pensé également, à la base. 🙂

      • Je suis tout à fait de ton avis.
        Lorsque je dis que Bootstrap s’est amélioré coté sémantique, c’est qu’il est possible à présent d’utiliser les ‘button’, ‘nav’ etc.
        Je ne sais plus où j’ai vu ça, mais j’étais tombé sur un truc qui résumait assez bien Bootstrap. De mémoire, ça ressemblait à ça :

        ^^

  2. Bonjour,

    Point de vue intéressant…

    Mais comme j’ai souvent pu le lire sur des blogs ou forums : « Pourquoi réinventer la roue à chaque fois ? »
    L’utilisation de frameworks permet quand même un précieux gain de temps une fois maîtrisés.

    Pour ma part (amateur), j’ai découvert récemment le framework Skeleton (http://getskeleton.com/) et je le trouve assez minimaliste pour me servir de base dans mes projets.

    Quoiqu’il en soit, je trouve ton blog fort sympathique et je ne manquerai pas d’y revenir de temps en temps.

    Bonne continuation !

    AdVitam

    • Bonjour et merci de ton commentaire. Je n’ai pu y répondre plus tôt faute de PC..

      Alors, ne pas utiliser de framework ne signifie pas forcément ‘réinventer la roue’ à chaque fois, tout particulièrement avec le CSS, puisqu’il suffit de copier-coller du code et de l’attribuer à une classe/un ID pour que cela fonctionne.

      Personnellement, je comprends que l’on gagne du temps lorsqu’on utilise de gros frameworks qui nous facilitent la mise en place de boutons ‘dropdown’, menus responsives etc.
      Mais pour reprendre ton exemple de Skeleton, voilà comment il faudrait procéder pour avoir une sidebar et un élément de contenu :

      Pourquoi ne pas gérer directement le positionnement dans l’ID du div ?

      Et dans le CSS :

      Tu peux très bien récupérer ces valeurs (les width) sur le code d’un autre projet, ou sur un framework 😉

      Est-ce que gagner si peu de temps vaut le coup de perdre en lisibilité, maintenabilité (mais ça ça reste à l’appréciation de chacun) et de laisser de coté la sémantique ?

      Merci en tous cas, j’apprécie énormément ton commentaire 🙂

  3. Article assez intéressent, merci 🙂

Laisser un commentaire

Votre adresse mail ne sera pas publiée.

*

© 2017 Max-Koder — Propulsé par WordPress

Theme par Anders NorenHaut ↑