Univers

Informatique

Approche Utility First

Moins de feuilles de style, plus de productivité !

Temps de lecture : 8 min env.
Publié le mardi 02 mars 2021 à 00:03

Que de chemin parcouru depuis la création de l’internet.

Bien que peu important au début, il est aujourd’hui impensable qu’un site internet néglige son design; c’est d’ailleurs un critère déterminant pour savoir si un site est voué à la réussite ou non.

Selon une étude de 2004 intitulée Trust and Mistrust of Online Health Sites réalisée sur un panel de 15 personnes, 94% s’appuient sur le design afin de juger de la fiabilité d’un site internet.

On ne peut alors douter que le design ait pris une place prépondérante dans la conception d’un site, tout du moins aussi impactante par rapport à l’aspect technique.

Néanmoins, il ne faut pas oublier que pour pouvoir magnifier ce design, il a fallu des ingénieurs pour écrire un ensemble de règles cohérentes qui a aboutit au langage CSS. Aujourd’hui indispensable à tout site digne de ce nom, sa mise en place n’a pas été facile. D’ailleurs aujourd’hui, nous allons vous présenter une méthode de travail en CSS qui commence à faire son trou parmi les développeurs front-end: l’utility-first !

Qu’est-ce que l’utility-first ?

L’utility-first permet de faciliter la maintenance et limiter les effets de bord, c'est-à-dire les régressions dues à la mise à jour d’un ou plusieurs éléments communs aux composants.

Pour ce faire, on utilise des classes utilitaires, qui sont des classes qui ont une seule et unique fonction. Par exemple, .m-2 aura la fonction de mettre une marge de 0.5 rem (soit 8 pixels), ce qui change des classes classiques qui contiennent des dizaines de règles CSS multifonctions.

Cette méthode de travail a été mise en place suite à l'avènement des frameworks CSS, mais nous allons y revenir.

Avant l’utility-first, comment faisait-on pour styliser une page web ?

Old Website

"Google à ses débuts, c'est beau non ?"

Mis en place fin 96 par le CSS Working Group, les feuilles de style en cascade ou plus communément appelées CSS (de l’anglais Cascading Style Sheets) n’étaient pas encore répandues sur les sites internet et la majorité du style de la page était géré dans des attributs des balises HTML tel qu’align pour l’alignement horizontal ou color pour la couleur du texte, on parle alors de style “inline”.

Le résultat donnait une page facilement éditable, mais dont les limites étaient vite atteintes du fait de la duplication de différentes règles communes.

À partir de CSS 2 en 1998, la mise en page par feuille de style a commencé à être privilégiée, mais il fallut toute de même attendre début 2000 pour que les navigateurs commencent à bien prendre en compte les spécificités du langage CSS dû au fait qu’il fallait se démarquer face à la concurrence (lors de la guerre des navigateurs). Internet Explorer 5 sur Macintosh fut le premier à proposer une intégration quasi-parfaite de CSS 1 suivit de Netscape 6.

Les classes étaient définies de la manière suivante, par exemple .author pour styliser le nom d’un auteur, .button pour un bouton, néanmoins cela posait un problème, car si on fait une modification de la classe .button par exemple, tous les boutons du site seront modifiés.

Il existe cependant plusieurs méthodes pour remédier à ce problème :

  • Le OOCSS (Object Oriented CSS)
  • Le BEM (Block Element Modifier) ➜ Qui a encore les faveurs de Simplon.Prod.
  • Le SMACSS (Scalar and Modular Architecture for CSS) ➜ Permet de catégoriser le CSS selon 5 types : base, layout, module, state, theme. Peut-être utilisé en complément de BEM.
  • Le ITCSS ➜ Permet de découper de manière logique le code CSS, et de maîtriser son ordre d’inclusion en découpant en 7 niveaux: settings, tools, generic, elements, objects, components, utilities. Peut-être utilisé en complément de BEM.

Dans les faits, on définit un bloc (par exemple d’un témoignage avec la classe “.testimonial”) et ses éléments (par exemple l’auteur du témoignage aura pour classe “.testimonial_author”), on évite alors les effets de bord sur les éléments ayant également comme nom author.

Le problème réside dans le fait qu’il faut nommer chacun des éléments, même les plus anecdotiques, ce qui peut vite être pénible, car cela rallonge le temps de développement. Aussi, cela rend la maintenance d’autant plus compliquée du fait que pour rajouter un élément, il faut modifier à la fois la feuille de style et la page en elle-même tout en faisant attention à ne pas faire de régression.

La complexité grandissante des feuilles de style a vu apparaître à la fin des années 2000 les préprocesseurs qui sont des logiciels qui génèrent du CSS à partir d’un script qui contient des variables, des boucles, des imbrications…Ce qui rend l’écriture du CSS moins difficile. Les plus connus sont Sass et LESS, mais il en existe plus d’une dizaine.

Le début 2010 voit la démocratisation des frameworks CSS comme Bootstrap ou Foundation pour les deux plus connues. Ces frameworks proposent un ensemble cohérent de composants d’interface préconçue et réutilisable à souhait. Le seul hic, du moins au début, c’est que ceux-ci ne proposaient que très peu de possibilités de personnalisation. Pour prendre l’exemple de Bootstrap, la classe utilitaire .bg-primary s’il est appelé depuis une version déjà compilée de Bootstrap sera de couleur bleue, et le seul moyen de rajouter une couleur différente est de créer une surcharge aux classes de bootstrap, ce qui rajoute du CSS inutile. Néanmoins, si l’idée est de faire une interface graphique qui ne nécessite pas une esthétique élaborée, les frameworks CSS sont le meilleur choix, mais force est de constater que pour un site dont le principal intérêt est d’être la vitrine de votre entreprise, on se retrouve souvent avec beaucoup de sites qui se ressemblent.

Heureusement, il existe une solution pour pallier ce problème !

Ainsi naquit l’utility-first

L’approche utility-first présente de nombreux avantages :

  • Il n’impose aucune structure précise pour créer les composants.
  • Le résultat fourni sera facilement compréhensible au premier coup d'œil, car chaque classe utilitaire à une fonction.
  • Il existe pour chacun d’entre eux une documentation claire sur l’utilisation de chaque classe.
  • On peut réutiliser le code facilement sur d’autres projets.
  • Et plus important encore, on n'a pas besoin de nommer les classes.

Il existe pourtant des réfractaires à cette méthode, voici quelques reproches vus ici et là :

  • Cela ressemble à du style inline ➜ Oui, mais les styles inline ne gèrent pas le hover, le focus, les media queries, les pseudos éléments. Aussi, on peut limiter l’aspect peu reluisant du code en découpant en composant et partial.
  • Il faut conserver une séparation des responsabilités (separation of concerns en anglais), le HTML gère le squelette de la page, le CSS le design ➜ Oui, mais comme le dit lui-même Adam Wathan, le créateur de Tailwind CSS dans l’un de ses articles de blog, il existe forcément une dépendance du code HTML avec le CSS et inversement.
  • Ça génère énormément de classes inutilisées ➜ Oui, mais uniquement sur un environnement de développement. Sur un site en production, grâce à l’utilisation de Purge CSS, on peut supprimer du fichier CSS, les classes qui ne sont plus utilisées. De plus, aujourd’hui les navigateurs modernes gèrent beaucoup mieux la répétabilité des classes, c’est-à-dire qu’ils mettent en cache les classes qui sont les plus utilisées dans le code HTML pour un traitement plus rapide des feuilles de style et donc un temps de réponse moindre.
  • Les utilitaires devraient être utilisés en complément de composants ➜ Oui, mais on parle de utility-first et pas de utility-only. On garde la possibilité d’abstraction des classes utilitaires pour les utiliser dans des classes plus classiques.

En plus des points positifs citées plus haut, l’approche utility-first augmente notre productivité et baisse notre dette technique. Thomas Catinaud Taris Lead Développeur Frontend et responsable du pôle Front chez Simplon.Prod

Tailwind CSS, le framework privilégié par Simplon.Prod

TailwindCSS

Tailwind CSS est un framework CSS utility-first développé par Adam Wathan, Jonathan Reinink, Steve Schoger et David Hemphill en 2017. Il est actuellement à la version 2.0.4. Ses points forts sont les suivants :

  • Il est avant tout mobile-first : le framework est avant tout conçu pour une utilisation pour les mobiles.
  • Il est extensible : on peut rajouter plusieurs plugins pour ajouter des classes utilitaires.
  • Il est configurable : on peut rajouter ses propres classes grâce au fichier de configuration JavaScript créé au moment de l’installation.
  • Il est facilement maintenable : en cas de mise à jour d’un composant, seul le HTML est touché.

Si l’utilisation des classes utilitaires peut être mal venue sur certains composants (exemple un bouton ayant plusieurs formes) on peut toutefois utiliser les classes utilitaires Tailwind dans des classes classiques grâce à la directive @apply.

Mon retour d’expérience avec Tailwind CSS

Après 3 mois d’utilisation de Tailwind CSS sur deux projets de la Prod à savoir : une PWA et l’un de nos starters kit Craft CMS, ce qui m’a sauté aux yeux est l’incroyable rapidité à développer avec celui-ci, on a rarement besoin de définir de nouvelles classes, et si cela est inévitable, on a juste à rajouter une nouvelle règle dans le fichier de configuration prévu à cet effet.

De plus, on passe très peu de temps à réapprendre les fondamentaux grâce à une documentation à la fois claire et très bien fournie, et extrêmement efficace grâce au moteur de recherche algolia.

Un autre point très appréciable : la majorité des éditeurs de texte et IDE du marché contiennent des plugins (gratuit) comme TailwindCSS Autocomplete pour PhpStorm ou Tailwind CSS IntelliSense pour Visual Studio Code pour augmenter la productivité en suggérant les classes Tailwind CSS, ainsi que les règles personnalisées définies dans le fichier de configuration.

Pour finir, tout en restant subjectif, ce qui me plaît le plus dans Tailwind CSS, c’est qu’il nous oblige à une rigueur de tous les instants, ainsi qu’une bonne maîtrise du CSS en amont.

Certes, on pourrait reprocher à l'approche utility-first de rendre le code HTML peu lisible, mais il ne faut pas oublier que c’était déjà le cas à l'arrivée du BEM ou des frameworks comme Bootstrap. Chaque évolution a amené ses lots de mécontentement, mais essayons de rester ouvert d’esprit et faire ce qu’il y a de mieux pour l’industrie, les projets, mais encore plus important : les utilisateurs.

Je tiens tout simplement à remercier Thomas Catinaud Taris et Alban Jubert pour tous les conseils qu’ils ont pu m'apporter pour l’écriture de cet article.

En complément

  • Une conférence intitulée “A Real-Life Journey Into the Opinionated World of ‘Utility-First’ CSS with Simon Vrachliotis”, présenté par ce même Simon, qui est désormais DevRel chez Tailwind Labs lors du dotAll 2018 à Berlin.
  • Une autre conférence, cette fois-ci présentée par Sarah Dayan, Senior Software Engineer chez Algolia lors du dotCSS 2019 à Paris.
  • Un article de Tailwind CSS qui explique pourquoi passer à l’utility-first.