DÉVELOPPEMENT

L'ultime framework front-end… to rule them all

Publié le : 22 Novembre 2016

6 min.

Le merveilleux monde des frameworks front-end

Rappelons brievement le principe des frameworks front-end

Un framework front-end est une librairie permettant d'assurer une structure et une cohérence graphique très rapidement. Structure en colonnes, typographie (police, taille, titre, paragraphe), composants (bouton, formulaire, dropdown, carousel, onglet, tooltip, alert, modal), états, responsive ; ils amènent tous un certain nombre d'outils permettant de faire gagner un temps important dans la création de site web.

Qu'on les aime ou qu'on les détracte, personne n'y est insensible et chaque intégrateur qui se respecte a sa petite idée sur l'utilisation ou non d'un framework front-end. Cela déchaine d'ailleurs les passions depuis plusieurs années :

On estime aujourd'hui qu'environ 15% des sites (de tous les internets) utilisent Ouvre une nouvelle fenêtreBootstrap, ce qui prouve que c'est un véritable phénomène - au moins tout le monde est d'accord à ce sujet.

Mais il n'y a pas que Bootstrap dans la vie... Ouvre une nouvelle fenêtreFoundation, Ouvre une nouvelle fenêtreMDL, Ouvre une nouvelle fenêtreSemanticUI, Ouvre une nouvelle fenêtreTrowel... on pourrait prendre beaucoup de temps à citer toutes les alternatives tant il en existe. Chaque framework a ses spécificités et une communauté plus ou moins grande. Pour creuser le sujet, vous pouvez lire Ouvre une nouvelle fenêtrecet article qui tente de tous les comparer.

Le choix est libre, complexe et mérite de prendre du temps pour tester quelques alternatives avant de choisir quel framework sera le plus approprié pour son projet, sans foncer tête baissée avec Bootstrap :)

Notre problématique : l'interopérabilité des développements

Comme vous le savez sûrement si vous nous connaissez, nous développons Ouvre une nouvelle fenêtreVictoire, CMS open source basé sur Symfony et spécialisé dans les développements sur-mesure.

Les travaux réalisés jusqu'à présent ont établi une architecture en widgets qui permet une approche atomique du développement dont le but premier est d’accélérer la création de sites professionnels et évolutifs sur le long terme, pour tout type de secteur d’activité. Pour ce faire, les widgets ont besoin d’être inter-opérables, c’est-à-dire de pouvoir fonctionner avec n’importe quelle technologie, existante ou future, et ce sans restriction d’accès ou de mise en œuvre. Dans ce contexte, l’intégration d’un framework front-end est laissé à la discrétion du développeur en charge du projet, en fonction de sa stratégie de développement (qualité, temps, coût, graphisme, etc).

Comme expliqué plus haut, le nombre de frameworks front-end est très important et en imposer un seul compatible avec Victoire comporte des risques de restreindre le nombre d’utilisateurs ou d’être dépendant d’une technologie qui peut devenir obsolète dans le futur. Notre objectif est donc de permettre à tout framework front-end, actuel ou futur, de pouvoir être utilisé dans un projet utilisant Victoire, y compris dans la gestion de l’affichage de chaque widget.

État de l'art

La majorité des CMS délègue ce choix à leur système de thème qui peuvent, ou non, s'appuyer sur différents frameworks. Cela est largement utilisé par la communauté Ouvre une nouvelle fenêtreWordPress qui permet ainsi à l’utilisateur final de modifier uniquement le contenu et d’avoir déjà tous les éléments d’affichage gérés et paramétrés en amont.

WordPress propose ainsi des thèmes basés sur Ouvre une nouvelle fenêtreFoundation ou bien Ouvre une nouvelle fenêtreBootstrap par exemple. Sur Ouvre une nouvelle fenêtreDrupal, les mêmes options sont possibles, même si Ouvre une nouvelle fenêtrela question se pose pour les futures versions quant au choix du framework.

Certains CMS, comme Wordpress ou Ouvre une nouvelle fenêtrePerch, prennent aussi le pari de pouvoir modifier les templates directement depuis l’interface d’administration du CMS mais cela demande tout de même d’avoir des utilisateurs confirmés et ne permet pas une capitalisation rapide de l’ensemble des widgets.

Un système de thème ? Pourquoi pas mais c'est un autre sujet !

Nous avons déjà envisagé un système de thème comme celui présent dans WordPress. Il définirait alors le framework front-end à utiliser et apporterait uniquement des feuilles de style.

En analysant les cas de WordPress et Drupal, on remarque que leur méthode ne semble pas applicable à un CMS ayant une organisation atomique comme celle de Victoire. En effet, cela est problématique et peu évolutif puisque cette solution - bien que simple à mettre en place - ne permet pas d’utiliser un style global, défini au préalable, et entraîne la génération d’interfaces incohérentes en terme de graphisme et très peu maintenables.

Le verrou majeur à l’inter-opérabilité des widgets est que le markup (syntaxe utilisée pour définir la représentation graphique) d’un widget diffère suivant le framework front-end utilisé. Si on peut répondre facilement au chargement du framework et du style général du site, le markup présent dans chaque widget est, lui, unique.

Il est donc inconcevable de demander à chaque créateur de thème d'implémenter le markup pour tous les widgets et, inversement, de demander à tous les créateurs de widgets d'implémenter son widget dans chaque thème déjà existant ...

Quelle solution alors ?

Le markup étant différent pour chaque framework css, nous avons d'abord intégré pour chaque widget autant de vues que de frameworks supportés ; chaque vue étant composée du markup spécifique au framework cible.

Nous avons tenté cette approche en prenant le pari de ne supporter que les deux frameworks front-end les plus répandus : Bootstrap et Foundation.

Un élément de configuration permettait de choisir quel framework était activé pour un site donné et avait pour effet de charger la vue correspondante.

Ce système s’est avéré fonctionnel mais comportait des freins qui l’ont rendu inexploitable :

le manque de maintenabilité : le nombre de vues à gérer était égal au nombre de widget multiplié par le nombre de frameworks supportés alourdissant de façon rédhibitoire le processus de création et d’évolution d’un widget.
chaque contributeur de Victoire qui souhaitait créer un nouveau widget devait impérativement maîtriser l'ensemble des frameworks supportés par Victoire pour que sa contribution soit acceptée.
en cas de changement dans l’API de l’un des framework supporté, il faudrait alors modifier le markup du framework en question pour chacun des widgets, rendant encore une fois critique la maintenabilité de Victoire.

Nous avons donc décidé de trouver une nouvelle solution pour contourner ces freins et répondre à notre volonté d'inter-opérabilité.

Il est apparu nécessaire de créer une couche d’abstraction pour les frameworks front-end que nous voulions supporter, afin de n’utiliser que cette couche lors de la création d’un widget et ainsi déléguer la gestion des markups spécifiques non plus à chaque widget mais à cette couche d’abstraction.

Ainsi, pour chaque composant d’un framework front-end, nous avons créé une syntaxe spécifique qui reprend l’essence du composant de façon abstraite, afin de générer les composants équivalents dans tous les autres frameworks supportés.

Pour un simple bouton, le sujet est toujours de générer un bouton d’une certaine taille, délivrant un certain niveau d’information, avec un label et ciblant une url.

Bouton créé avec une syntaxe unique et affiché avec le framework Bootstrap et Foundation

Techniquement, il ne s’agit plus de rédiger les composants d’une page web en HTML mais à l’aide de “twig extensions”, qui permettent de générer du HTML en profitant d’une couche logique apportée par le langage PHP.

Ainsi, lorsque la Twig extension “almanach_button” est invoquée, un algorithme détermine en fonction de la configuration du projet quel framework utiliser, puis convertit les options abstraites fournies en options concrètes relatives au framework. C’est ainsi que lorsque le thème “error” est demandé pour un bouton, une classe “btn-danger” sera générée pour Bootstrap et une classe “alert” pour Foundation.

Présentation de la librairie : l'Almanach

Nous avons réalisé une librairie open source nommée Ouvre une nouvelle fenêtreAlmanach permettant à tout développeur travaillant sur un projet se basant sur Symfony d’utiliser le système d’abstraction présenté - lui offrant la possibilité d'utiliser un autre framework front-end, ou de mettre à jour l'existant sans changer le code source.

L’objectif d’inter-opérabilité que l’on s’était fixé pour les widgets de Victoire est totalement atteint puisque ce système convertit le code en html propre au framework choisi dans le projet. Nous n'avons pas encore implémenté ce système dans tous les widgets mais dès lors, ils seront capables de passer d’un framework à un autre, d’un développeur à un autre et ne seront pas condamnés à devoir être réécrits afin d’utiliser les versions futures du framework.

Avancée des travaux

Lors des travaux de développement du projet Almanach, on a atteint quelques limites : certains composants n’existent pas dans tous les frameworks.

Par exemple, les boutons de type FAB (Floating Action Button) existent dans le framework Ouvre une nouvelle fenêtreMaterial Design de Google mais n’existent pas dans les frameworks Bootstrap et Foundation. L'usage d'un FAB dans un widget développé via Material Design renverrait ainsi une erreur à la génération si on traduisait, via Almanach, le projet vers Bootstrap.

La solution envisagée, afin de réellement avoir des widgets inter-opérables entre les différents frameworks, est de prévoir un système de polyfill afin de simuler ces composants / comportements lorsqu’ils n’existent pas dans un framework. Le polyfill agirait ainsi comme l'élément générique à utiliser.

Bibliographie

Leny Bernard

Développeur