L’industrialisation du front-end, les frameworks de création d’interfaces CSS JS

Difficile de passer à côté du phénomène Twitter Bootstrap, cet ensemble d’outils CSS JS et UI pour créer des interfaces web-app en moins de deux.
Il doit notamment sa renommée à sa gestion du responsive qui propose deux grilles css dont une entièrement gérée en unités relatives.

C’est un framework de création d’interfaces web avancées tout comme « Zurb Foundation », ou le nouveau framework « Pure ». Il diffère sur ce point de ses cousins les frameworks css « Zen grids », « KNACSS », et autres qui n’embarquent aucun plugin javascript et se concentrent sur la structuration de la vue.

Pour reprendre la phrase d’introduction sur le site de TB « Sleek, intuitive, and powerful front-end framework for faster and easier web developement » qu’on pourrait traduire par « un  kit de composants web html css js (front) puissant, intuitif et élégant, qui va vous faire gagner du temps et vous simplifiera la tâche ».

Sur le papier ça fait rêver, mais est-ce que dans les faits c’est toujours le cas ?

On va essayer de voir jusqu’à quel point cette affirmation tient la route, si il existe des contrindications à l’utilisation de ces outils et quelles sont les alternatives possibles.

I. Le cas de Twitter Bootstrap:

Ahh le framework, c’est un peu le couteau suisse de la conception. Ça aide bien dans certaines situations mais dès qu’on veut passer sur du gros œuvre ou de la précision, soit ça casse soit c’est difficilement maniable car trop lourd.

Bien qu’ayant de grandes qualités Twitter Bootstrap n’échappe pas à ce constat. En effet il a été créé avec des outils et des champs d’applications bien spécifiques.

Et de ces champs d’applications naissent des limites, comment peut-on alors les définir ?

Observons à la loupe la bête alias Twitter Bootstrap V2.2.2.

 

1. La loupe :

Deux feuilles de styles CSS dont une globale (124ko pour 6000 lignes) et l’autre qui gère l’aspect responsive « adaptif » mais sans les composants d’interface utilisateur (22ko pour 1200 lignes).

 

a. La surcharge pondérale CSS chez Twitter Bootstrap

Mr Fat (un des deux principaux créateurs de ce framework) ne dira pas le contraire, même si la mise en forme des formulaires, boutons et autres tableaux est bien gérée chez Twitter Bootstrap ça fait quand même beaucoup de CSS pour tenter de répondre à tout les cas d’usages.

La grille de mise en page CSS dans Twitter Bootstrap c’est :

  • une rangée appelée « row » (layout),
  • des gabarits de tailles différentes appelés « span » et des marges « offset » qui forment la grille CSS.
    Le tout fait à peu près 123 lignes de code CSS non minifié, « et le reste ? » me direz-vous.

Le reste c’est :

  • reset des valeurs CSS sur les éléments HTML (le même que HTML5 boilerplate),
  • édition et titrages (tailles, couleurs, comportement sur les « hover »),
  • style des formulaires, tableaux et boutons,
  • icones,
  • style des plugins js,
  • media queries pour gérer le passage aux petites résolutions

Ajoutez à ça les CSS propres au design du site et les surcharges éventuelles de la CSS de bootstrap…

De plus l’utilisation de sélecteurs avancés CSS3 ordonne des comportements génériques à certains blocks html, exemple :

.row-fluid [class*="span"] {

}

.row-fluid [class*="span"]:first-child {

margin-left: 0;

}

Le tout se transforme en un véritable casse-tête difficilement maintenable.

b. Le même constat en Javascript

On trouve le panel classique des plugins jQuery UI type tooltip, popover  modal, dropdown, carousel et autres interactions et bien sur la librairie jQuery elle même (32ko).

Encore une fois le constat est décevant, ces outils ne sont pas encore optimisés pour une utilisation mobile.

Un comble pour un framework qui se veut « responsive » donc mobile–friendly…

Le plugin « bootstrap-transition.js » n’en permet pas la compatibilité même si

partant d’une bonne intention il permet un fall-back sur les transitions javascript. Mais en choisissant la propriété « transition » à la place de « transform » il n’offre pas à ce fall-back l’accélération matérielle du téléphone et ainsi une animation plus fluide.

De la même façon qu’en CSS il faudra donc procéder au nettoyage des plugins non nécessaires à notre site internet.

 

2. D’autres solutions ?

a. adapter son Twitter Bootstrap

Autour de moi la plupart des cas d’usages pour Twitter Bootstrap concernent la structuration, responsive ou non. En effet les plugins javascript embarqués sont généralement peu utilisés car peu performants et dotés d’effets de transitions plutôt moyens.

Pour nettoyer l’archive des éléments non nécessaires, TB a mis à disposition un outil pour customiser son framework selon les besoins.

Mais cet outil suffit-il à répondre à toutes les situations ?

Le web front étant en perpétuelle évolution que ce soit graphiquement ou structurellement il est bien difficile de prévoir tous les cas de figure et futures optimisations possibles.

 

b. Zurb Foundation, un concurrent mal connu

Le cas de Foundation est intéressant, méconnu il est pourtant supérieur à TB sur certains points.

Alors que TB v1 ne gérait les tailles que par des unités absolues, celui-ci disposait déjà d’une grille CSS en «  responsive fluide ».

Il utilise la propriété CSS3 « box-sizing: border-box; » qui lui permet de contrôler le modèle de fonctionnement CSS des blocks html et ainsi de palier aux comportements récalcitrants des éléments HTML type « textearea » (dépendant du nombre de colonnes pour calculer sa taille).
Son système de grille est à mon sens plus respectueux des équilibres qu’on peut retrouver dans le monde de l’infographie. En effet il n’est pas basé sur le nombre d’éléments affichés mais offre un panel de choix plus large permettant ainsi de répondre à plus de design.

Utilisant un balisage plus « sémantique » que son concurrent, les mises à jours et autres modifications s’en trouvent simplifiées, mais là c’est plus une question de goût.

Son slideshow « Orbit » qui gère l’accélération matérielle est aussi plus adapté aux besoins de performance mobile.

À noter que la version 4 de « Zurb » ne permet plus le support sur ie7 et 8, mais qu’il existe un fix mis à disposition par les développeurs.

Mais bien que paramètrable, cette solution n’est malheureusement pas parfaite non plus.

On va donc essayer de comprendre quels sont les cas d’usages types, les limites et comment appréhender au mieux son projet pour savoir si celui-ci est compatible avec un framework web ou nécessite un travail sur mesure ?

 

II. Les limites des frameworks CSS

 

1. Grille typographique et gestion du contexte web

a. Grille modulaire éclatée et nombre d’or

La structure tabulaire des grilles CSS dans la plupart des frameworks CSS est prévue pour gérer des cas simples, c’est à dire des tailles de cellules calculées en fonction du nombre de conteneurs affichés. Mais que ce passe-t-il lorsque le designer utilise des valeurs tel que le « nombre d’or » ou la suite de Fibonacci pour calculer les tailles de ses blocks ?

C’est le cas bien plus souvent qu’on ne le croit, en effet la conception des grilles et équilibres dans le monde du design échappe à la plupart du commun des mortels, laissant apparaître la magie créative de nos supers DA.

Lorsqu’on veut intégrer une maquette photoshop basée sur une grille un peu plus avancée que celle présente dans un framework CSS, les acrobaties à réaliser pour adapter les gabarits tiennent parfois de la haute voltige !

Et il sera difficile de modifier les grilles CSS via les outils précités en fonction de ces équilibres autrement qu’en les surchargeant.

 

b. la volatilité actuelle du développement front

Les spécifications CSS3  n’étant toujours pas standardisées, les techniques pour gérer certaines problématiques liées au design responsive ne sont donc pas officiellement stables.

Et que dire de la démocratisation d’écrans HD et UHD qui maintenant est aussi à prendre en compte.

La logique webkit actuelle d’implémentation de propriétés CSS orphelines (non supportés par les autres navigateurs) type « -webkit-font-smoothing » n’aide pas non plus à stabiliser les conditions de développement-front.

Sans parler des sites à effets Parallax, et autres performances front avancées comme on peut trouver sur des plateformes type awwwards ou FWA.

 

2. Comment appréhender les besoins CSS pour son projet web

a. Web-app ou plateforme de communication web ?

Selon les besoins, l’utilisation de telle ou telle solution CSS peut-être définie.

En effet pour faire des applications web le frameworks CSS est la solution ! Profitant de gabarits génériques et embarquant des outils js et autres style UI, il constitue la manière la plus rapide de créer un prototype ou une web-app. De plus ses grilles sont adaptées au design générique des formulaires, boutons et autres menus contextuelles ou de navigation.

Mais lorsque le projet web est un peu plus complexe, difficile de se passer d’une stratégie CSS spécifique.

 

b. CSS ce n’est pas si compliqué

Il existe donc des cas où le sur-mesure reste une nécessité, et figurez-vous que ce n’est pas si compliqué !
En effet les unités relatives sont comprises depuis le navigateur Internet explorer 6, le responsive dit « fluide » est donc supporté par les navigateurs depuis de nombreuses années.

Voici un tutoriel rapide pour réaliser sa propre grille responsive CSS (compatibilité internet explorer 7 inclus) :

La démo

Le HTML :

<div class="grid-layout">

<div class="cell-1-3">
</div>
<div class="cell-1-3">
</div>
<div class="cell-1-6">
</div>
<div class="cell-1-6">
</div>

</div>

Notre conteneur se nomme « grid-layout » et les cellules contenues « cell-X-X ».  Ici « X-X » représente la taille en largeur de la grille divisée par le nombre de cellules. Cette indication permettra de savoir quelle taille en % fait la cellule par rapport à son conteneur (ndlr : ceci est ma propre convention de nommage, à vous de choisir celle qui vous convient). Gardez en tête que la taille globale ne doit pas dépasser 100%, ce qui équivaut à  » cell-1-1 « .

La grille CSS :

  • Tout d’abord assurons nous que cette grille saura résister aux comportements flottants dans les cellules (clear: both;),
  • Ensuite on attribue le ou les comportements par défauts pour toutes les cellules ([class*="cell "]{…}),
  • On construit la grille (.cell-1-1, .cell-1-2, etc),
  • Enfin on ajoute la touche « media querie » qui ajustera le layout pour les terminaux dotés de petits écrans (@media (max-width: 620px) {…}).

Et voilà notre grille flexible et responsive, vous n’avez plus qu’à créer ou récupérer vos éléments d’interfaces et les injecter à l’intérieur des cellules de la grille.

So hard ?

13 commentaires pour “L’industrialisation du front-end, les frameworks de création d’interfaces CSS JS”

  1. Merci pour l’article !

    Au delà de la simplicité de mise en oeuvre, un autre avantage des Framework CSS est de « normaliser » les choses de manière à ne pas réinventer la roue MAIS SURTOUT rapidement comprendre un projet pris en marche.

    Nous avons fait le choix d’utiliser et d’enrichir Bootstrap sur notre outil GED/CMS/RSE/Portail/Collaboratif justement pour ces raisons.

    Sans qu’on s’en rende compte, de nombreux sites sont maintenant réalisés avec un Bootstrap surchargés.

  2. Oui, je suis d’accord avec Jean-Philippe : certains projets choisissent résolument de privilégier la maintenabilité et la vitesse de production à l’optimisation du poids des pages (et peuvent partir sur du Bootstrap sans avoir de besoin mobile identifié).

    Typiquement là je bosse sur un gros back-office où on utilise Bootstrap uniquement pour gagner en vitesse de production pour éviter de ré-inventer la roue sur pleins de trucs. Faut faire vite et bien.

    En plus le gros problème du CSS « from scratch » c’est qu’il n’y a pas deux développeurs front qui bossent pareils et il y a donc beaucoup de lourdeur quand un deuxième mec doit repasser sur le boulot du premier. Bootstrap apporte (un peu) de normalisation dans tout ça (surtout avec l’usage de Less).

    Dans une logique agile (et voir même Lean Startup), on veut parfois privilégier un résultat rapide à une optimisation de l’appli (sans pour autant sacrifier la qualité du code).

  3. Quand ferez-vous enfin la différence chez Octo entre Framework et librairie ? Twitter Bootstrap n’est pas un framework.

  4. Elle alors Jean ? C’est quoi la différence ? T’as une doc ou des articles de références à suggérer pour aiguiller là-dessus ?

    Moi intuitivement je me dis qu’une librairie doit adresser un problème précis là où un framework doit apporter un moyen de structurer une façon de travailler pour améliorer des notions tel que productivité et maintenabilité. Je pense vraiment que Bootstrap rentre dans la seconde catégorie, mais je suis curieux de savoir en quoi ça n’est pas le cas pour toi…

  5. @kossdav tout à fait d’accord sur la définition de framework, de plus ce sont les créateurs même de Twitter Bootstrap qui le disent et j’ai aussi tendance à les croire.

    Après pour le problème des différents patterns CSS « from scratch », il existe des outils et ateliers (dispensés à Octo par Frédéric Mérizen) qui peuvent permettre d’homogénéiser les pratiques de tous (cf http://blog.octo.com/vendredi-2604-lecole-du-tech-lead-parle-de-revues-de-code/ et http://blog.octo.com/coder-a-pas-de-chaton-a-lecole-du-tech-lead/ ).

  6. Oui, c’est bien d’homogénéiser les pratiques, mais en pratique c’est très rare de le faire comme tu le suggères au travers d’une formation externe. C’est plutôt quelque chose qui n’est soit pas adressé (auquel cas il faut trouver un standard « de fait » est Bootstrap en est un), soit adressé en interne (l’équipe de développement qui formalise petit à petit ses pratiques et organise des ateliers en interne ou des mets en places des méthodes comme le binômage ou des contrôles qui permettent d’assurer une diffusion progressive des bonnes pratiques).

  7. +1 kossdav

    Il y a des dizaines de bouquins, formation, forum, podcast, etc … sur « comment bien coder ».

    Bon en pratique c’est le stagiaire avec le tampon « expert » sur son CV qui va mettre les mains dans le code pour le projet qui doit être fini hier.

    Donc si de-facto l’équipe utilise un framework qui impose déjà toutes les bonnes pratiques une partie du chemin est fait. Il ne reste qu’a RTFM (ce qui n’est déjà pas gagné)

  8. Le problème vient justement de « c’est le stagiaire avec le tampon « expert » sur son CV qui va mettre les mains dans le code pour le projet qui doit être fini hier ».

    Les technos front devenant de plus en plus complexe (contextuellement comme techniquement) il ne faut plus considérer le CSS ni le HTML par défaut, et pousser vers une vrai logique d’ingénierie du code.
    Sinon c’est la porte ouverte à toutes les douleurs connues, interopérabilité, portabilité, pérennité du code dans le temps, douleurs lors des modification car le code est non modulaire, etc…

    L’idée n’étant pas d’aller chercher ailleurs une formation pour former vos équipes mais de les responsabiliser en leur proposant de mener eux-mêmes ces ateliers de « revus » entre eux, et d’ainsi remettre leur pratique en question pour trouver les bon pattern CSS qui correspondent à leur pratique.

  9. @Jean-François Fraisse on est 100% d’accord en théorie mais dans la pratique ce n’est pas ce qui se passe, surtout chez les grands comptes.

    Il y a une conf à ParisWeb13 sur le sujet qui me semble excellente:

    La folle journée, ou les fourberies d’un projet
    http://www.paris-web.fr/2013/conferences/la-folle-journee-ou-les-fourberies-dun-projet.php

    Avec un sondage en préparation:
    https://docs.google.com/forms/d/1ImAS_YcvI0pkgXDao-ZD6xNTtc9YfTJoO19AWDaAEdg/viewform

  10. On sort un peu du sujet principal (on parle méthode et plus vraiment CSS ou front).
    La conf décrit un modèle qui à mon sens n’est pas à suivre mais bien à éviter.
    Et le but de cet article (mais aussi de mes réponses) est de proposer des pistes permettant de palier à cet état de fait (tout du moins côté CSS).

    PS: Et que dire de l’acte 4 de la futur conf !

  11. @Jean Un framework étant la formalisation d’un cadre de travail … j’estime aussi que TB est un framework !
    Une librairie c’est jQuery, on y fait appel régulièrement selon le besoin mais on je conforme pas tout son code à ses besoins…

  12. Ma remarque précédente était simplement lié à l’argument « Il faut venir se former et faire bien les choses », ce qui est malheureusement rarement le cas surtout sur les gros projets.

    D’ou ma première remarque concernant les framework comme boostrap dont la valeur ajouté n’est pas la simplicité de mise en oeuvre mais surtout cette normalisation permettant de coordonner le travail des équipes.

    C’est encore plus vrai si l’on extrapole au « responsive design » pour lequel de nombreux experts expliquent qu’il ne faut surtout pas s’attacher aux détails mais s’intéresser à l’UX.

    Typiquement si le framework fournit une mécanique de grille il ne faut surtout pas aller en refaire une autre pour être au pixel prêt.

  13. TB ou Foundationsont pour moi des framework.
    Certe ils fournisse un ensemble de fonctionnalité tel une librairie.
    MAIS avec ces outils et je parle essentiellement de FOundation que j’ai adopté après de longs mois d’essais sur différents framework CSS, ces outils permette do’betenir un cadre de travail pour faire son CSS via LESS ou SASS.
    Donc ce sont bien des framework si vous prenez la peine de devenir des utilisateurs avancé de TB ou Foundation.

    Par contre si vous faites un simple DL et une intégration oui ce sont des librairies.

    Sinon Foundation écrase toute la concurrence, plus performant, meilleur syntaxe, fréquence de mise à jour impressionnante. Une doc complète avec exemple et explications pour améliorer le framework avec SASS. Le tout avec des exemple de template.
    Tout simplement merveilleux.

Laissez un commentaire