Frameworks CSS, templates et thèmes de base. Comment bien démarrer vos projets web ?

Un développeur front-end a de nombreuses possibilités pour démarrer un projet plus rapidement. Il peut se servir de codes « boilerplate »,  comme un reset CSS qui a fait le tour de ses projets, ou encore quelques snippets avec un doctype et quelques groupes de balises basiques. Il peut également utiliser des « code starters ». Ces fichiers utilisés pour démarrer un projet, une intégration, ou autre thème pour CMS, sont parfois nommés « frameworks », même s’ils sont exploités comme une bibliothèque d’objets CSS.

Pourquoi les utiliser ?

Les avantages sont nombreux : vous souhaitez éviter de perdre des heures/journées sur des projets où tout avait déjà été fait ailleurs, mais où rien n’a pu être récupéré ? Ou vous désirez prototyper une idée rapidement,  mais sur une base évolutive ? Ou, tout simplement, vous souhaitez gagner du temps au debug, en implémentant des structures déjà testées et éprouvées ?
Le choix ne manque pas dans les projets existants. Pour de l’intégration pure, on regardera du côté de Bootstrap par Twitter, Zurb Foundation, la feuille de style KNACSS, ou encore mon CSSNormalize. On trouvera également de solides thèmes de départ pour WordPress, tels que Bones, Underscores ou Basics.

Créer le vôtre

J’ai néanmoins choisi de créer mes propres outils, préférant avoir un code starter à mon usage, répondant à mes besoins, suivant les conventions que je respecte en interne, et dont le développement et les droits d’utilisation sont maîtrisés par moi seul.
Je n’ai ainsi pas la crainte d’utiliser un outil dont le principal développeur souhaite prendre le large sans nommer de projet remplaçant, ou dont la direction change du tout au tout.

Par où commencer ?

Idéalement, il faut créer un dépôt Git privé ou public, selon la cible du projet et la volonté de le confronter aux retours de vos confrères et consœurs. Utiliser Git assurera la centralisation des sources du projet, un bon travail en équipe, un suivi des évolutions et un backup hors site si vous avez la bonne idée de le créer sur un serveur externe ou service dédié.

Une fois ce dépôt créé, il suffit d’y ajouter des fichiers basiques correspondant aux étapes initiales du développement : template HTML vide, fichier d’événements JS, squelette CSS… ainsi que les fichiers se retrouvant dans une majorité de projets (html5shiv ? Selectivzr ?).

Comment le maintenir et l’améliorer ?

Avant tout, ne pas se précipiter pour le remplir. Il faut travailler pas à pas : à chaque utilisation, à chaque nouveau projet, s’interroger. Cette fonctionnalité pourrait-elle être améliorée pour permettre cet usage ? Ce nouveau type de bloc pourrait-il être réutilisé dans un autre projet ?

Étudiez les commits de plusieurs projets en même temps : les derniers projets ont une étape « création du menu » d’une durée de 2 h. Ajouter un menu basique dans le starter permettrait-il de gagner du temps ?

N’hésitez pas à étudier les documents de debug  : quelles sont les erreurs les plus récurrentes ? Une modification de l’objet CSS associé pourrait-elle éviter ce type de bug ?

Utilisez-le en équipe pour tester ses limites : les stagiaires ont-ils trouvé facilement cette fonctionnalité ? Comment est utilisé ce layout de galerie ? Cette grille cause-t-elle plus de soucis qu’elle n’en soulage ?

Si vous le pouvez, donnez-vous une roadmap : fonctionnalités à développer, idées futures, compatibilité à améliorer, etc.

Quelles contraintes ?

Vous vous devez de documenter l’existant : devoir refaire une fonctionnalité déjà existante, mais non documentée, est un gâchis de temps et une atteinte à la modularité. L’utilisation d’une fonctionnalité mal comprise peut également causer de mauvaises surprises.

Le code doit rester facilement modifiable : il faut séparer distinctement les couches de structure, de présentation et de style visant une démo.

Pensez à la modularité : attention à ces parties contenant un gros pavé de code dont seule une petite partie est utilisée.

Il ne faut pas implémenter de style trop marqué, sauf s’il est récurrent dans vos projets. Il s’agit là de mon principal grief envers Bootstrap, dont le style rappelle trop Twitter, qui le rend clairement identifiable lors de l’utilisation.

Attention aux bases intrusives : un style de base qui doit être surchargé à chaque utilisation cause plus de problèmes qu’il n’en résout.

Synchronisez-vous : si vous proposez plusieurs versions (mobile, desktop…), ou si vous les distribuez par plusieurs moyens (Github, démo…), assurez-vous de répercuter les modifications en même temps sur chacune. Un petit script Shell pourra sûrement faire ce travail à votre place.

Comment l’utiliser ?

Si votre projet est une base non modifiée (comme un framework ou un pack de scripts), vous pourrez utiliser un sous-module Git, intégrant automatiquement les évolutions de cette dernière.

Les méthodes classiques, comme « picorer » des parties intéressantes, ou encore copier et cloner l’intégralité du code (et supprimer les parties non utilisées au fur et à mesure), fonctionnent elles aussi à merveille.

Mes exemples

Vous l’aurez deviné, je suis moi-même adepte de cette technique. Voici quelques exemples de « code starters » que j’utilise et maintiens au quotidien.

• CSSNormalize : styles de base et modules CSS récurrents.
• InteStarter : système de base pour une intégration, récupère CSSNormalize via un script Shell.
• Un starter WordPress, utilisé chez Colorz. Contient des fonctions, plugins et templates récurrents. Mis à jour par les devs et intés.
• Un starter Magento, utilisé chez Colorz. Contient des modules et templates récurrents. Mis à jour par les devs et intés.
• JavaScriptUtilities : regroupe les scripts JS, jQuery et MooTools que j’utilise régulièrement.

Conclusion

Vous l’aurez compris, les « code starters » sont indispensables à tout projet web. Leur utilisation fait gagner du temps, améliore la qualité de code et simplifie la maintenance. Attention toutefois, de petits projets peuvent être alourdis par du code inutilisé si la mise en place de vos starters est faite à la va-vite !