Présentation des frameworks d’interface – Partie 1

En tant que développeur, vous avez sans doute déjà entendu parler de Bootstrap. Pour faire simple, dans le monde des frameworks CSS il y a lui et les autres !

Bootstrap est un framework CSS open source développé et mis en avant par Twitter en 2010 et qui reste à ce jour le framework CSS le plus populaire sur GitHub. Il propose une collection d’outils permettant de faire des mises en page pour des sites et applications web.

Parmi ses outils, Bootstrap propose une multitude de composants CSS et JS comme une grille flexible, des éléments de formulaires, des boutons, des classes utilitaires, des modales etc.

Ces composants d’interface prêts à l’emploi peuvent ensuite être utilisés n’importe où dans un projet web.

Section intitulée la-force-de-bootstrapLa force de Bootstrap

Grâce à cette boîte à outils, il est théoriquement possible de construire un site ou une application web sans avoir besoin d’une expertise poussée en CSS.

En effet, un fichier de configuration global écrit en Sass permet de configurer et de personnaliser la majorité des composants d’interface fournis par Bootstrap, sans devoir modifier les fichiers sources.

Bootstrap s’adresse donc généralement à tous développeurs souhaitant construire des interfaces de façon simple et rapide.

Depuis plus de 10 ans, ce framework CSS ne cesse de s’enrichir de nouvelles fonctionnalités, possède une communauté active et une documentation complète qui contribue également à sa popularité.

Bootstrap paraît donc être l’outil idéal pour construire son site web.

En parallèle, d’autres frameworks CSS ont vu le jour, parmi les acteurs majeurs on peut citer notamment Foundation et Materialize.

La plupart de ces frameworks CSS « concurrents » se veulent plus légers, plus fonctionnels et plus simples d’utilisation… Mais ont tous comme point commun, celui de proposer une grande variété de composants d’interface prêt à l’emploi. C’est ce qu’on appellera par la suite, les frameworks d’interface.

Section intitulée la-limite-des-frameworks-d-interfaceLa limite des frameworks d’interface ?

Proposer des composants d’interface génériques et préconçus n’offre pas que des avantages.

Choisir de concevoir un site web avec un framework d’interface c’est aussi se restreindre d’un point de vue UI.

En effet, la plupart de ces frameworks d’interface vont proposer une personnalisation limitée des composants : changement de couleurs, de typographie, d’espacements, etc.

Mais la structure du composant restera telle quelle et ne pourra pas véritablement évoluer (à moins de modifier le composant lui-même, ce qui n’est généralement pas recommandé).

Section intitulée le-grand-detournement-a-ne-pas-reproduire-chez-vousLe grand détournement (à ne pas reproduire chez vous)

En règle générale, lors de la conception d’un site web, les équipes d’UI vont travailler sur des composants d’interface en accord avec l’identité de leur marque, et non en se basant sur les composants préfabriqués des frameworks d’interface (qui leurs sont même probablement inconnus).

A ce stade, vous connaissez certainement la suite de l’histoire… ? 😇

…2 mois après, la majorité des composants fournis par les frameworks d’interface ne seront pas (ou plus) utilisés.

Les développeurs auront créé de nouveaux composants plus flexibles et spécifiques répondant à leurs propres contraintes d’UI.

Cela aura pour conséquence d’alourdir et de complexifier les fichiers CSS, en embarquant inutilement des composants issus de ces frameworks d’interface, et par la même occasion d’accumuler de la dette technique.

Section intitulée quand-utiliser-les-frameworks-d-interfaceQuand utiliser les frameworks d’interface ?

En règle générale, si vous n’avez pas de contraintes poussées d’UI, les frameworks d’interface sont fait pour vous ! L’exemple typique est celui du back-office d’un site e-commerce. L’aspect fonctionnel étant privilégié à l’aspect esthétique.

Section intitulée et-pour-le-reste-quelles-solutionsEt pour le reste : Quelles solutions ?

Section intitulée on-part-de-zeroOn part de zéro ? 🤔

C’est la solution qui, dans un premier temps, vient naturellement à l’esprit. Ne pas embarquer de framework d’interface permet d’être totalement libre sur les conventions de nommage, l’organisation des fichiers CSS et le choix (éventuel) des préprocesseurs (Sass, Less, Stylus, PostCSS, etc.) utilisés pour le projet.

Malgré ces nombreux avantages, des inconvénients sont également à prendre en considération, comme la nécessité de :

• Créer un fichier de configuration afin de déclarer les variables globales (couleurs, espacements, éléments typographiques, etc.) utilisées au sein du projet ;
• Générer éventuellement des variables CSS (en se basant sur le fichier de configuration créé au préalable) via des scripts personnalisés ;
• Créer une grille modulable et flexible ;
• Ajouter une librairie de classes utilitaires (ou en créer une spécifique au projet) ;
• Définir des feuilles de styles de base (Reset CSS, Normalize, etc.).

Ce processus de configuration devra être réitéré à chaque nouveau projet, ce qui, en plus d’être rébarbatif, peut potentiellement avoir un impact négatif sur les temps de développement.

Idéalement, automatiser l’ensemble de ces tâches permettrait au développeur de se consacrer entièrement à la conception des composants d’interface (qui reste son objectif principal).

Section intitulée le-meilleur-des-deux-mondesLe meilleur des deux mondes ?

Comme nous venons de le voir, nous avons d’une part, les frameworks d’interface proposant une bibliothèque de composants riches mais peu flexibles, avec néanmoins, un fichier de configuration global et de nombreuses automatisations de tâches (génération de grilles, variables, etc.).

Et de l’autre, une solution beaucoup plus flexible, sans framework d’interface, mais également sans configuration globale, ni automatisation de tâches.

C’est dans cette optique que nous avons conçu Atomic Builder, un framework CSS conciliant les avantages de ces deux méthodologies de travail, à savoir :

Automatiser l’ensemble des tâches de configuration d’un projet sans en impacter l’UI.

C’est ce que nous verrons ensemble dans une seconde partie ! 😊