Les applications Backends sont à juste titre dotées d’une structure et d’une équipe dédiée chargée de sa conception dans la recherche d'une architecture cohérente et résiliente. Le manque de structure logique dans les applications frontend me dérangeait lorsque je passais d'une couche à l'autre.

Ce qui aurait dû être assimilé à une «architecture frontend» était généralement un processus de structuration ad-hoc déterminé par les exigences du moment, souvent sans considérations pour les ramifications futures. Quelque soit l'expérience utilisateur ou le design de l’application, les choses avaient tendance à être en désordre sous ce joli glaçage.

Quand l'architecture n'est pas complètement réfléchie au début, travailler avec une base de code frontend de moyenne à grande échelle peut être un exercice frustrant et difficile. Par exemple, il est peu probable qu'il y ait un protocole défini à suivre lors de l'ajout ou de la modification d'éléments et du code source. Il sera laissé à la discrétion de chaque développeur de structurer à sa sauce le frontend.

Cela crée un «developer lock-in» (blocage du développeur), car explorer et gérer le frontend nécessite de comprendre la structure implémentée par les contributeurs précédents, afin d’en synthétiser les règles existantes sur « ce qui va où », et « pourquoi ». En réalité, on a rarement accès aux personnes qui ont posé les bases d'une interface. Il faut analyser leur raisonnement et croiser les doigts dans l'espoir que leur architecture soit intelligible.

Les bonnes pratiques relatives à l'architecture frontend ont récemment gagné en popularité, probablement en raison du fait que les machines Frontend à la complexité grandissante et les workflows qui en résultent nécessitent une approche plus structurée du développement. Micah Godbolt, auteur de «Architecture frontend : un modèle moderne pour des sites web évolutifs et durables» définit l'architecture frontend comme : «Une collection d'outils et de processus qui visent à améliorer la qualité du code frontend, tout en créant un workflow durable. ». Cette définition pousse clairement la communauté des développeurs à prendre au sérieux l'architecture frontend.

Pendant des années, nous avons eu accès à des scaffolds qui fournissent un ensemble commun de composants UI et une bibliothèque de style, chacun avec ses propres conventions sur la façon de gérer la couche de présentation. Le style était la principale préoccupation, aux dépends de la structure. Bien que cette limitation soit compréhensible pour diverses raisons, il y a tout de même une place pour framework qui va au-delà du style, fournissant une plate-forme résiliente sur laquelle construire votre frontend.

Nous avons accès à de puissants langages de balisage et d'abstraction du style, ainsi qu'à ES2015, tous offrant une grande indulgence sur la façon dont nous pouvons structurer le code de nos interfaces utilisateur. Les technologies Frontend ont atteint le niveau de maturité nécessaire à la création d'une architecture générique qui impose une mise en page structurelle cohérente. Ma suggestion pour une telle architecture serait que, à la base, les piliers structurels suivants soient présents:

1. Décrit son architecture avec un vocabulaire structurel sémantique
2. Assure l'intégrité structurelle avec des règles pour la gestion des assets
3. Expose des modèles qui permettent une mise à l'échelle prédictive

Un framework qui adhère à ces trois règles structurelles peut évoluer et façonner ses caractéristiques opérationnelles et conceptuelles sur une base solide. Celles-ci peuvent inclure des points intéressants tels que:

• La prise en charge de workflow du projet avec un pipeline d'assets intégré
• Quelques styles standards passe-partout
• Une collection de « utility classes »
• Une bibliothèque de composants standardisés

A partir de 2013, j’ai commencé à rassembler des extraits de balisages, de styles et de scripts, dans le but d'améliorer la réutilisation de modèles récurrents - un processus probablement déjà vécu pour nombre d'entre vous. C'est aussi à cette époque que je suis devenu un préprocesseur CSS et que j'ai dû choisir un package. Le jeu de fonctionnalités de Stylus et sa flexibilité syntaxique m'ont séduit, et mon choix a été fait dans ce sens. A l'époque, aucun frameworks qui n’utilisaient Stylus. Mon choix impliquait d’abandonner des solutions efficaces et bien contrôlées comme Bootstrap de Twitter et la Fondation Zurb.

A ce stade du développement, soit vous modifiez une solution existante, soit vous déployez la vôtre. J’ai opté pour la seconde stratégie. Au début de l'année 2014, en partant de ma collection toujours croissante d'extraits, j'ai entrepris de créer mon propre scaffold, reliant dans le même temps toutes ces pièces à un modèle de base, dans un template multi-page. Celui-ci a d'abord fonctionné sur HTML 5, Stylus et la logique pré-ES6, puis il a été testé en production sur quatre projets distincts de petite à moyenne taille.

Le scaffold fonctionnait, mais il n’avait pas de structure claire, et ne pouvait pas évoluer de manière homogène du fait d’une organisation plus monolithique que modulaire. Cela ne facilitait pas la réutilisation des composants et manquait d'un pipeline d'assets intégré. J’ai capitalisé mes expériences de développeur dans ce projet fil-rouge en l’enrichissant constamment face aux nouvelles perspectives et à la mutation de l’environnement frontend.

Travaillant toujours sur des interfaces existantes disparates, je remarquais que l'absence de structure générique demeurait une problématique récurrente et chronophage. Quelque chose devait évoluer. C'est à ce moment-là que j'ai décidé de reprendre mon projet au long cours pour une refonte majeure. L'idée était de créer une architecture robuste pour une partie du développement qui demeurait sans consensus avéré à l’époque. A la mi-2015, j'ai franchi le pas et commencé à retravailler le scaffold en l’insérant dans une structure intuitive.

Le projet "Platframe" était né. Essentiellement structuré plate-forme, il servirait de base au framework. J'ai remplacé le HTML avec Pug, et ai adopté le désormais stable ES2015. Cette couche m'a permis d'obtenir une modularité sur la couche structurelle, mais aussi sur la présentation ainsi que la couche dynamique. J’ai opté pour Grunt sur la prise en charge des pipelines d'assets, tandis que l'ensemble est articulé avec l’humble tentative d'une conception structurelle plus explicite.

Notez que j'aurais pu utiliser toute autre combinaison de couches, tant qu'elle était dotée des fonctionnalités pertinentes pour maintenir l'intégrité de l'architecture. Au cours du travail de refonte, j’en suis venu à penser qu'un système de couleurs standards pourrait être une bonne solution. Cette solution visuelle permettrait de gérer des composants autonomes et réutilisables qui pourraient être partagés entre les projets basés sur Platframe. Le résultat final est un framework qui est:

• Structuré avec une architecture claire et définie
• Capable d'évoluer de manière transparente avec des modèles récursifs pour la gestion des assets
• Optimisé sur le Workflow, avec un pipeline actif intégré
• Conscient du Don’t Repeat Yourself (DRY), avec des modules interchangeables
• Structuré avec un système de couleurs prenant en charge les packages partageables
• Bootstrappé avec des styles standards et un modèle de démarrage
• Prescriptif a minima sur la méthodologie de développement

Je vais éviter d'étendre la liste ci-dessus par souci de brièveté, mais je vous invite à lire la documentation du projet qui traite de l’ensemble des points.

Il a fallu beaucoup de travail pour réaliser le jeu de fonctionnalités ci-dessus dans un package intégré, mais j'ai finalement réussi à finaliser celui-ci en février 2018. Depuis, j'ai décidé d'ouvrir ce package en open-source car l’avantage essentiel du projet repose sur l'expertise transverse des développeurs.

Petit aparté : Platframe est loin d'être complet, et encore plus loin de la perfection. Dans son état actuel, il s'agit d'un effort pour établir une idée de ce à quoi pourrait ressembler un framework frontend structuré. Alors que sa version actuelle est prête à être utilisée en production, Platframe peut bénéficier à plus de développeurs et être plus utile avec les améliorations suivantes:

• Séparation et codification de l'architecture. L'architecture sous-jacente devrait être clairement découplée des technologies spécifiques. Il servira alors de directive générique qui pourrait être adoptée par n'importe quelle couche qui satisferait l'ensemble des fonctionnalités requises pour l’implémentation.
• Une plus grande sélection de composants. Il n'y a actuellement qu'une poignée de composants pour illustrer le concept de packages réutilisables dans le framework.
• Plus de schémas de couleurs. Le framework est livré avec trois schémas standards. Les schémas sont faciles à intégrer dans votre projet et peuvent se répercuter jusqu'aux plus fins détails de coloration de votre interface utilisateur, y compris les composants assets.
• Sélection d'utilitaire étendue. La sélection actuelle est limitée et deviendra obsolète avec le temps. Elle a besoin d'une mise à jour et d'une extension pour inclure une plus grande variété d'éléments d'interactions.
• Un système de construction de niveau inférieur pour réduire l'empreinte globale de la dépendance.
• Un gestionnaire de package natif pour les composants (quoique faible sur le triage).

Je vais continuer à travailler sur la liste, mais sachez que toute aide est la bienvenue :-)  Les détails pour contribuer sont sur la page GitHub du projet.