Et c’est bien normal. C’est ainsi que nous découvrons nos outils, les personnalisons et atteignons leurs limites (ainsi que les nôtres).
Éternels insatisfaits
Cependant aucun outil magique n’existe. Parmi les outils auxquels je pense, Bootstrap et Foundation se tirent la bourre depuis quelques années pour le titre de « Meilleur framework de l’année ». Cependant tout le monde leur trouve des défauts :
- trop de dépendances ;
- trop de composants ;
- des choix techniques trop orientés ;
- des partis-pris graphiques trop saillant ;
- etc.
Un peu plus récemment sont apparues des alternatives — plus légères, agnostiques et moins élaborées graphiquement. On peut citer Röcssti de Nicolas Hoffmann ou Knacss de Raphaël Goetter.
Elles corrigent certains défauts des usines à gaz précédemment citées, mais ne sont pas pour autant exemptes de travers : elles reflètent les choix de leurs auteurs, et généralement nous n’aurions pas fait les mêmes.
What if?
Que se passerait-il si on détaillait vraiment les avantages de ces solutions ? Nous font-ils gagner autant de temps que nous l’imaginons ? Quid de la charge de travail qu’impliquent l’appropriation et la personnalisation des ces outils ?
Vous le savez peut-être déjà et l’aurez deviné sinon, je ne suis pas un grand fan des ces choses pré-mâchées. Ces outils permettent de démarrer rapidement un projet et de montrer des pages presque instantanément — mais ils font également perdre un temps fou dès qu’il s’agit de personnaliser le design, de rajouter des composants, ou d’optimiser les performances.
Les solutions de Nicolas et Raphaël sont un brin plus intéressantes puisqu’elles sont personnelles : vous y trouverez un condensé de leurs années d’expérience, des cas tordus qu’ils ont pu rencontrer. Cependant leur façon de nommer les choses, d’écrire leur code, et la limite qu’ils fixent entre une base propre et une ébauche de design leur est personnelle également. Peu de chances que vous vous y retrouviez totalement.
Mes deux centimes
Fut un temps ou j’ai fourché.[1]
Désormais lorsque je travaille sur des projets personnels, j’ai adopté mon propre framework prêt à l’emploi, simple d’utilisation, sans opinion ou choix technique contraignant, agnostique, sans parti-pris graphique…
Un fichier vide.[2]
Héhé, moi c’est justement en ayant marre de partir du fichier vide que je me suis constitué une base CSS nommée Röcssti. Et je ne cache même pas que l’idée m’est venue avec Knacss. 🙂
Comme tu l’as bien dit, elle reflète mes habitudes… et surtout elle est là pour « standardiser » l’organisation du travail au boulot : trop de perte de temps à avoir des CSS en bordel et à chercher le petit truc qu’on a oublié de reprendre du projet précédent. Grosso merdo, c’est 3/4H d’économisées au démarrage de chaque projet, et je ne parle pas de la maintenance facilitée. Maintenant, même le graphiste commence à utiliser les classes auto-* pour responsiver les sites. ^^
Après, ça dépend ® : si tu bosses sur un site unique et spécifique, Röcssti ne sera peut-être pas adapté. Si tu dois abattre du site en quantité, Röcssti tire son épingle. Sur le dernier site d’événement que j’ai dû pondre très rapidement, un browser sync, et attention la vitesse d’intégration.
Si par contre l’idée se voulait la même que Knacss au départ, les orientations sont devenues très différentes au fur et à mesure : Knacss est parti sur un chouette système d’autogrid et notamment sur du Flexbox dans sa dernière version, je suis resté sur le minimum viable qui doit tenir sur de vieux navigateurs (exit Flexbox en standard). Röcssti est en full-em, ce qui n’est pas le cas de Knacss si ma mémoire est bonne. Etc.
Bref, des choix différents : Knacss est un peu plus fourni en features automatiques donc plus pratique de ce côté-là, Röcssti est encore plus minimaliste (et peut-être plus atomique, même si ce n’est pas sa feature principale). Ce qui se confirme avec le poids : Knacss est à 17ko minifié, et Röcssti est à 7ko minifié.
Le vrai truc le plus important de Röcssti n’est pas ce qu’il permet de faire en responsive (même si je fais des trucs très biens avec :), mais surtout l’organisation rigoureuse qui vient avec : si l’inté ne fait pas le débile (et je veille au grain), je sais de suite si un élément est utilisé plusieurs fois, si c’est une exception, si le template est globalement homogène ou non, etc. C’est là àmha le vrai travail de l’inté : être méga-structuré.
Et surtout on minimise la quantité de code en tirant au maximum parti de la cascade : léger et rigoureux pour la maintenance. Je remarque d’ailleurs que plus je fais de l’inté avec, plus je suis parcimonieux dans l’écriture de code.
En tout cas, je suis content de voir qu’enfin les intés arrêtent de croire que « tel (micro) framework » est la solution ultime : des cas d’usure différents, des approches différentes, pas de mauvais choix, mais juste des choix. Perso, le site de Röcssti est juste là pour le crédibiliser auprès de mes clients, pas pour lui faire dominer le monde ! 🙂
D’ailleurs, tu as déjà pensé à releaser ta base de travail ? Je serais curieux de voir cela.
Héhé mais oui figure-toi 😀 Quand je bossais en agence, j’avais donc fourché Knacss. Tu pourras trouver sseeeedd sur GitHub. Comme tu peux le voir, ça fait un bail que je ne bosse plus en agence ! Ne l’utilise surtout pas.
Pour rebondir sur tes propos, en effet — comme je pensais l’avoir dit — dans un contexte industrialisé qui tend vers la productivité et l’efficience, ce type d’outillage est absolument indispensable. Cependant rien ne sert de tenter d’apprivoiser une solution tierce, surtout si elle n’est pas aussi minimaliste et agnostique que le sont Röcssti et Knacss. Ce serait du temps perdu, de la lourdeur, et des problèmes de maintenabilité. Vos micro-frameworks peuvent devenir une excellente base de travail, mais il me semble également futile de bêtement les utiliser tels quels. Je pense qu’une base de travail, de quelque sorte que ce soit (il n’y a pas que les frameworks dans la vie !), devrait être aussi unique que la personne ou l’équipe qui la conçoit. Elle doit être propre à un intégrateur, à une agence, à une équipe de développement, et dans certains cas transcender ceux-là pour être propre à une entreprise. C’est une question de pertinence à plusieurs niveaux, de valeur ajoutée et de savoir-faire.
Cet article questionnait surtout les gens® qui ne sont jamais contents de leurs outils. Heureux soient les simples d’esprit.
Dans mon cas, j’ai le luxe de travailler sur un produit vivant. Je compte mettre en ligne (bientôt) un projet embarquant plusieurs outils (que tu connais déjà si tu as détaillé la dernière année d’évolutions sur a11y.css :P). Grosso merdo, ce projet inclura un gros fichier Sass avec deux ou trois petites fonctions, et une approche de conception dite atomique (à compléter à l’échelle du projet, donc). Le plus (à mon humble avis) sera la documentation incorporée et structurée, permettant de générer un guide de styles avec Hologram. Et pour le fun j’ajouterai un ensemble de tâches Gulp bien huilé.
Je fais de jolies promesses. Mais encore une fois ce projet sera vivant. Et enfantera. Il finira arrière-grand-père et je finirais par l’enterrer dans un coin du web, quand plus personne ne s’en souciera. C’est ce que sont tous ces projets, tous ces outils, toutes ces tendances. Nous les avons écrits dans un fichier vide et ils redeviendront un fichier vide un jour.
C’est pourquoi je pense que ce projet ne sera pas utilisable en tant que base de travail — et en tout cas très peu éprouvé en tant que tel, je ne le recommanderai pas. Je le publierai avec comme seule ambition l’espoir que ça pourra inspirer certains camarades, donner des idées, provoquer des échanges, et (oh oui alors) recueillir un max conseils et progresser encore et encore grâce à vous.
Mais quiconque pensera s’en servir comme base pourra relire cet article pour connaître mon avis 🙂
Merci pour cet article. J’en suis venu à la même conclusion.
Nous faisons peu de sites par an, mais uniquement du 100% custom, avec un designer assez créatif ^^.
J’ai une fois eu l’obligation d’utiliser Bootstrap, plus jamais. J’ai perdu un temps fou à apprendre toute la nomenclature, à être surpris de certains comportements en responsive… sans compter du poids du fichier.
Et puis, je « souffre » d’une manie incontrôlable : il faut que toute ma nomenclature soit cohérente, je peux passer des heures (vraiment) à me poser la question si je dois utiliser telle ou telle bibliothèque juste parce que la nomenclature ne me plait pas…
Du coup j’avais créé un mini framework perso : https://github.com/maestrooo/maestrooo-sass
Il est encore beaucoup trop gros, je vais prochainement virer la moitié. Mais l’idée c’est juste d’inclure ce dont je suis sûr à 100% d’inclure dans TOUS les projets, sans exception aucune. Et surtout, je ne m’en sers jamais comme une dépendance bower, je le copie colle systématiquement pour pouvoir le modifier à la source, et non surcharger son comportement par cascade.
Au final, je m’y retrouve :p.
Perso je fais pareil. Un framework perso permet un worflow plus rapide et adapté à mes besoins, ainsi qu’une bonne source de montée en compétences.
Voilà un starter qui illustre mes besoins du moment -> https://github.com/sutter/Starter-STATIC
@Sutterlity : That’s the spirit!
Je vais regarder ton starter avec attention, merci pour ce partage 🙂
@Michaël : Ça a l’air bien, en effet 🙂
Merci beaucoup pour le partage — et si tu t’y retrouves, c’est que le plus important est atteint !
Je pense qu’il ne faut pas non plus abandonner l’idée des frameworks suite aux frustrations que peuvent apporter la mauvaise utilisation de Bootstrap/Foundation. Quand on enlève tout les partis pris superflus de ce genre d’outil, il ne reste pas nécessairement rien.
Plus qu’un fichier vide, je pense que c’est dans « l’emballage » que se trouvera la vrai valeur des « frameworks » css. Ce qui est commun à tous les projets d’une équipe : les outils qui vont autour. Une manière simple d’obtenir une base de travail saine est d’observer la globalité des projets d’un équipe. Il faut ensuite garder ce qui est présent dans la majorité de ces projets. Si les produits finis sont graphiquement indépendant et originaux, ce qui restera seront les systèmes d’automatisations et styles de normalisation (reset.css). Le choix que j’ai pris est d’avoir cette base de travail presque vide (mais bien emballée) et à côté une galerie de composants (graphiquement neutres) qui sont ajoutés au cas par cas.
J’essaie d’expliquer le processus qui à mené à cette outil ici: https://medium.com/dev-notes/dummy-2b44823d57db#.6mlwwor57
Là où je suis d’accord, c’est qu’une base de travail doit être « personnelle ». Il faut que chaque utilisateur se l’approprie et surtout travailler avec un framework et pas en dépit d’un cadre trop rigide.
Je ne dis pas dʼabandonner les frameworks, au contraire ! Mais ce sont des outils avec des capacités et des fonctionnalités très précises, et celles-ci doivent correspondra à lʼobjectif du projet.
Lʼorigine de cet article (que jʼaurais probablement du mentionner) est un discours trop souvent entendu du type « Bootstrap a un design trop avancé », ou encore « il a trop de fonctionnalité pour ce quʼil est censé faire ». Ce qui est idiot, il fait exactement ce pour quoi il a été conçu. Et ça ne correspond pas souvent aux besoins auxquels nous devons répondre.
Chacun sa solution, comme tu le dis si bien. La mienne est un fichier vide car je travaille depuis quelques années maintenant sur des produits, qui nʼont rien de commun. Cʼest un cas à la marge, mais vraiment on sʼy habitue bien 🙂
Idem 🙂
C’était un peu (mais pas assez de temps pour expliquer toute mon expérience passée) l’idée de ma conférence au #wcparis > https://fr.slideshare.net/FrederiqueGame/conception-de-thmes-construire-et-optimiser-son-espace-de-travail
C’est en effet, très personnel et je me concentre pour ma part sur les préprocesseurs et mes snippets, du coup, tout un classement en amont pour ne m’intéresser qu’aux zones (header, footer, etc… article…).
Une sorte de pré-flux ? Juste déjà un gain de temps pour ne pas refaire la boucle, ne changer ensuite que les polices et avoir une belle palette de couleurs Sass prêtes à l’emploi.
Puis appliquer un premier niveau d’ « assemblage » pour ensuite aller vers le détail (ça doit être ma formation d’arts plastiques initiale :)…
Pour finir, j’utilise essentiellement (mais pas toujours bien sur 🙂 Underscores et Genesis.
Voili :o)
Merci Frédérique pour ce partage 🙂 En effet jʼétais là au WordCamp et me suis pas mal retrouvé dans ton intervention !
> Je pense qu’une base de travail, de quelque sorte que ce soit (il n’y a pas que les frameworks dans la vie !), devrait être aussi unique que la personne ou l’équipe qui la conçoit.
Surtout le contexte dans laquelle elle est faite. Bootstrap est une solution tout-en-un, et je dirai même : prévue pour des gens qui n’ont pas le temps ou la connaissance, pour poser rapidement des choses. C’est un non-sens d’imposer ça à des intés avancés (enfin, àmha).
Ceci dit, en mode poil à gratter => je regardais certaines intés d’autres intégrateurs talentueux, je remarque que sur les sites actuels, ce sont à peu de choses près TOUJOURS les mêmes patterns qui reviennent : 2/3 colonnes qui se superposent en tablette/mobile, etc.
Et grosso merdo, ce sont les mêmes classes atomiques qui reviennent : les margin: 1em, etc. 🙂
En effet, mais c’est un biais je pense 🙂
Concernant les colonnes / grilles, selon la compatibilité attendue, l’objectif et la complexité de la grille tout devrait varier à chaque intégration, je crois.
Pour les espacements — et bien que je sois tombé dans ce biais moi aussi — il me semble que varier les valeurs d’espacements devrait être le standard, au lieu d’avoir une valeur standard. En terme de communication visuelle, l’aération graphique est primordiale et sert des objectifs précis : je doute fort que tous nos sites aient les mêmes objectifs.
C’est un standard par défaut plus qu’un choix conscient, je crois.