Utiliser les thèmes framework est une vrai fausse bonne idée

Utiliser les thèmes framework est une vrai fausse bonne idée

Depuis quelques années, on entend de plus en plus parler de thème framework. Ils sont nombreux et de qualité diverses, mais derrière un aspect com qui laisserait à penser que ces outils apportent des gains de productivité et des sites de meilleurs qualités, est ce véritablement le cas ? De mon point de vue, c’est tout l’inverse.

Une sur-encapsulation d'encapsulation

Les CMS proposent aujourd'hui des composants de haut-niveau, c'est une de leurs forces, car ces outils sont bien adaptées à un métier, à une tache bien particulière : la gestion de contenu.

Mais c'est également une de leur faiblesse, car les éditeurs sont obliger de faire des choix qui ne correspondent pas aux problématiques métiers de votre projet.

C'est d'ailleurs pour cette raison que l'on a vu au cours de ces dernières années des techniques pour contourner ses problèmes. On peut citer par exemple :

Les themes frameworks viennent à l'encontre du principes qui a motivé ces ajustements. Elle rajoute encore une (ou plusieurs) surcouche, qui encapsule et contraint un peu plus le "développeur". Mais, comme cela pose les mêmes problèmes que la couche initiale du CMS. Même cause même effet, il rajoute des encapsulations supplémentaires avec des surcharges supplémentaires, des nouveaux points d'accroches, et des options configurables.

Un exemple : le thème framework Omega de Drupal

Je choisis non pas ce framework parce qu'il est mauvais, mais plutôt parce que c'est un des meilleurs et des plus utilisées

Prenons un exemple, il y en plein du même genre.

[[{"type":"media","view_mode":"media_large","fid":"1474","attributes":{"alt":""}}]]
Exemple de sur-encapsulation

La première ligne me fait froid dans le dos, je cite : "Fournir enveloppe pleine largeur autour de cette zone : L'activation de cette fonctionnalité vous donnera un “wrapper” autour de la zone elle-même, vous permettant de thèmer les éléments qui apparaissent en dehors de la zone de 960 pixels".

Ok, je reflechis 2 secondes, j'ai un panneau dans le backoffice qui me dit est ce que je veut mettre un div dans un fichier HTML. Mais, c'est tellement plus simple de mettre le code directement dans l'override du template qui va bien, non, un p'tit panneau caché, quelques requetes à la base, un template un peu moins lisibles sont autant de vertu qu'apporte ce genre d'outil.

J'allais oublié, il faut également penser à la gestion des droits qui va bien pour que le webmaster du site ne fasse pas sauté la mise en page en décochant malencontreusement cette case.

Si vous n'êtes pas convaincu, il faut quand même avoir à l'esprit qu'on a affaire à un système qui nécessite plus de clics et de chargement de page dans le backoffice, que de touche à actionner sur le clavier, pour un obtenir le même résultat.

Ce n'est pas le seule point de ce genre, il y en a des dizaines et des dizaines, il suffit de voir le contenu des écrans de configuration.

Pourquoi ces systèmes sont ils utilisées ?

C'est logiquement, une question qui se pose. La réponse est assez simple : cela ne nécessite pas de compétences en programmation.

En plus, il y a une configuration par défaut avec une configuration qui affiche quelques choses, donc il suffit d'en modifier que quelqu'un.

Et comme, il y a une configuration par défaut, on peut très sans sortir pour obtenir un résultat, et si le résultat ne nous convient pas, on va chercher un module qui va modifier le résultats en sur-encapsulant le tout, et le tour est joué. On retombera sur nos pieds.

Des conséquences désastreuses

Au final, avec ce genre de fonctionnalité, on arrive plus ou moins suivant le degrés de complexité de la création graphique à nos fins. Mais,cela rete du Quick and Dirty ce tour de passe-passe n'est pas sans conséquences.

Des coûts de maintenances et d'évolution beaucoup plus élevés

A force de rajouter des couches de sur-encapsulation, on a un code qui devient difficille, très difficile à lire. Il faut se souvenir que l'affichage de la balise est gérer par le 4ième onglet de la 12ième liste de configuration du sous-thèmes GrosBeta, lui même enfant du thème Omega.

Cela aurait quand même beaucoup plus simple d'avoir un simple template qui correspond à mon projet, et qui contient ou non la balise, et si j'ai besoin de la change je change juste le template.

Chère commanditaire, si un prestataire vous propose ce genre d'outil, vous savez déja que vous allez vous faire allumer sur la maintenance et évolution du site, compter le double ou le triple de temps par rapport à un site fait dans les règles de l'art.

Des "développeurs" non motivé

On sait que n'importe qui va plus vite quand il fait quelque chose d'intéressant, et je suis désolé de vous dire mais un développeur n'aime pas travailler dans un clickodrome, et en plus, il relativement conscient qu'il fait, excuser moi du terme, de la merde.

Il est donc moins motivé, donc moins productifs, et donc le postulat disant que ce genre d'outil fait gagner du temps (ce dont je ne suis déja pas certains à la base) tombe à l'eau.

Certains publics trouverons leurs comptes, des jeunes en début de carrières, des freelances ou des agences qui veulent faire du fric et se soucie guère de ce qui arrivera par la suite.

Des évolutions technologiques difficiles

Supposons que votre client ne regarde pas la dépense, et que vos développeurs ne sont pas parties, il reste encore un autre point assez problématique.

Pour mettre à jour un système vers une version supérieur, il faut que chaque couche puisse être mise à jour. Si un des maillons de la chaine n'est pas mis à jour, vous ne pouvez pas mettre à jour.

Prenons un exemple, je veut migrer mon template vers les versions les plus récentes pour bénéficier des dernières fonctionnalités. Il faut que chaque composant puisse être mis à jour, chaque surcouche est dépendante des autres couches. La mise à jour de certains éléments ne peut pas se faire sans l'autre. La dépendance de Drupal (ou autres CMS) vis à vis de PHP ne pose pas de problème, la dépendance des modules par rapport à Drupal, on a pas trop de soucis, généralement, on a des fonctionnalités en plus et des améliorations dans les algorithmes sous-jacents mais globalement les tests unitaires passe toujours, donc pas de soucis.

En revanche, sur un système qui se base sur un framework HTML / CSS tierces, la je suis beaucoup plus inquiets, dans notre exemple, on sait très que grid 960 évolue en changeant certaines classes, voir en changeant le reste CSS ce sera beaucoup plus difficile. Soit, il faut faire beaucoup d'ajustement pour corriger le tir et avoir le même résultat, on a plusieurs solutions :

Si on couple en plus, notre thème framework avec des modules commes Views, Features ou panel, je vais laisse imaginer le bordel.

Bref, dans tous les cas de figure, cette surcouche n'apporte que des ennuies, et vous pourrez être certains que votre site ne sera jamais mis à jour, et qu'au bout de 3 ou 4 ans, il faudra recommencer à 0.

Si vous comptez faire du One Shot et que vous ne trouvez pas de développeur, cette solution peut être envisageables. Dans les autres cas, cela sera beaucoup plus problématique mais vous ne le verrez que par la suite, dommage pour vous.

Conclusion

J'ai pris l'exemple du thème framework Omega mais grande majorité des thèmes framework sont dans cette veine, si vraiment vous voulez utiliser un framework efficace, redescendait d'un niveau d'abstraction allez regarder du coté des frameworks HTML comme Bootstrap ou HTML Boiler PLate, intégrer cela avec vos petites mains et un bon éditeur de texte, vous ferez à coup sûr un meilleur travail. Si vous n'y arrivez pas, je vous suggère très gentillement d'envisager une reconversion professionnel

Oui car la réalisation d'un site, c'est écrire du code avant tout.

J'aimerais juste terminé cet article par un passage du livre Coder Proprement, que je trouve adapté à la situation.

Certains pourraient prétendre qu’un livre qui traite du code est un livre dépassé – le code n’est plus le problème – et qu’il est plus important aujourd’hui de s’intéresser aux modèles et aux exigences. Il a même été suggéré que la fin du code était proche, qu’il serait bientôt généré au lieu d’être écrit, que les programmeurs seraient bientôt inutiles car les directeurs de projets généreraient les programmes à partir des spécifications.

Balivernes ! Nous ne pourrons jamais nous débarrasser du code car il représente les détails des exigences. À un certain niveau, ces détails ne peuvent pas être ignorés ou absents ; ils doivent être précisés. Préciser des exigences à un niveau de détail qui permet à une machine de les exécuter s’appelle programmer. Cette spécification est le code.

comments powered by Disqus
A la une
  • Rencontre du numérique 2019 - Nîmes
  • référencement naturel d'un hôtel
  • Développeur eZ Platform
  • Tech lead Symfony
  • Expert Qualité Web

Copyright - Sylvain FIX

2009 - 2019