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 TwitterZurb Foundation, la feuille de style KNACSS, ou encore mon CSSNormalize. On trouvera également de solides thèmes de départ pour WordPress, tels que BonesUnderscores 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 !

Kévin Rocher

À propos de Kévin Rocher

Kévin Rocher est Développeur Front-End par passion, et adore optimiser le monde qui l'entoure. Il publie sur le blog darklg.me et bricole sur son compte Github.

Vous pouvez partager cet article sur Facebook, Twitter ou Google+.

Faites un don pour soutenir l'association Les B-A des Satellites

L'association Les B-A des Satellites aide à offrir une école aux enfants de Niellé en Côte d'Ivoire.

Les fonds récoltés vont directement sur le compte PayPal de l'association. En cliquant sur le bouton « Faire un don » ci-dessus, vous allez être redirigé vers PayPal. Vous n'êtes pas obligés de créer un compte PayPal pour faire un don.

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

  1. Nico, le mercredi 5 décembre 2012 à 09:09

    En toute honnêteté, j'étais pas très convaincu quand j'ai créé le mien (RÖCSSTI pour ne pas le nommer), voici le genre d'interrogations qui tournent en tête :

    - ok, est-ce que je ne vais pas réinventer la roue ?
    - est-ce que le temps investi va réellement m'en faire gagner ?
    - est-ce que j'en profite pour faire exploser certaines techniques et en essayer de nouvelles au passage ?
    - etc.

    Au premier projet fait avec, je ne vais pas dire que c'était parfait (le cerveau fume un peu, normal, je bousculais beaucoup de mes habitudes en intégration), mais j'ai vu quelques petits avantages émerger. Au deuxième projet avec, j'ai réussi à gagner une heure là où je pensais ne plus arriver à gagner de temps. Au troisième, les gains continuent. Les projet suivants enrichissent la base.

    Une contribution m'a permis de fortement améliorer la présentation de mes CSS.

    Bref, de "pas convaincu" au début, je n'y vois que des avantages après. :)

    Ce qui me fait dire : si vous gagnez même un tout petit peu au début en faisant ainsi... ne vous posez plus de question : continuez ! Les gains vont augmenter au fur et à mesure.

  2. MoOx, le mercredi 5 décembre 2012 à 10:17

    Intéressante lecture. Merci.

    Je reste personnellement sur H5Bp pour la structure HTML, et au niveau des CSS, j'ai mes patterns CSS dans mon petit repo http://compass-recipes.moox.fr/

    Niveau JS, je découvre grunt et mon workflow n'est pas encore assez stable pour que j'utilise quelques choses de versionné :)

    Petite note sur CSSNormalize: le nom porte à confusion avec normalize.css, le projet sur lequel H5Bp se base (sur lequel tu te bases)... *brainfuck* :)

  3. Danny Turcotte, le mercredi 5 décembre 2012 à 13:56

    Yeoman.io (http://yeoman.io/) est très intéressant également. Il permet de démarrer vos projets très rapidement et offre pleins d'outils comme la compilation SASS et CoffeeScript en temp réel, un LiveReload pour votre navigateur, optimisation des images, minification des javascripts, gestion de cache,...

    Ça l'a été un peu long à installer, car il me manquait plein de dépendances, mais sinon ça fonctionne bien.

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.