Le manque de recul

Le manque de recul (le 9 mars 2014)

S’il y a une chose qui me surprend toujours dans le domaine du web, c’est le constant manque de recul de bon nombre de personnes y travaillant. Pour éviter de me disperser, je m’en tiendrai aux développeurs et autres intégrateurs.

J’ignore si cela est dû à la jeunesse du support ou à un syndrome amnésique, mais je suis parfois stupéfait de cette capacité à réécrire l’histoire ou à l’oublier, que ce soit dans les approches, les pratiques et même les fondements.

Les approches

À mon sens, le propre du développeur est de rapidement voir les conditions limites d’une approche. Plus son savoir et son expérience sont étendus, plus il doit pouvoir jauger rapidement les limites d’un cadre donné : une méthodologie, un framework, une approche, un outil, etc.

Je suis effaré de voir déjà l’incapacité de voir les limites d’un cadre, et souvent assommées à grand renfort de certitudes. J’aime bien les super-slogans genre : « avec Wordpress, on fait un blog, avec Drupal on fait Wordpress ». Super, cela tombe bien, j’avais besoin de re-développer Wordpress. Et si je n’ai déjà pas besoin d’un Wordpress ?
Ou le classique « les vrais développeurs utilisent <mettez ici ce que vous voulez> ». Sous-entendu : vous êtes une sous-merde si vous n’utilisez pas ça.

Pire, voir ou mentionner ces limites ne doit pas servir à démolir une approche, mais juste à mieux apprécier le cadre posé, libre à vous de faire le choix ou non d’apprécier ce cadre. Mais nier que ce cadre existe… non !

Les pratiques

Un point m’amuse, ce sont les effets de modes : « tiens y a tel outil qui est révolutionnaire », les premiers affamés se jettent dessus, des articles sont pondus pour vanter les mérites, ça buzze à fond sur Twitter… et deux semaines après, y a un article qui vient dire « oui, mais attention, dans tel cas… » ou alors « des problèmes d’accessibilité sont apparus », « on devient dangereusement dépendant de cet outil » etc.

Je parle d’outil, mais les approches ont les mêmes problèmes quand elles sont lues un peu vite, combien de fois ai-je entendu : « mais on ne met plus d’id dans la source, vu qu’on utilise que les classes pour styler ».

Je me permets de citer Mehdi Kabab dans un commentaire sur 24 jours de Web :

Intégrateurs, votre cœur de métier ne se limite pas à pisser du CSS au kilomètre. Vos compétences et le savoir que vous avez acquis à la sueur de vos erreurs (vive l’apprentissage par l’échec, la meilleure école de l’intégrateur/développeur Web) ont de la valeur. Alors, s’il vous plaît, ne les rejetez pas sous prétexte qu’un personnage influent clame tout haut une opinion personnelle, mais qui se répand comme une traînée de poudre de part son statut de « gourou ».

Qu’on s’entende bien : c’est bien de tester des nouveaux trucs, de voir de nouvelles techniques, etc. je ne vais pas dire le contraire, c’est même indispensable.

Seulement, il y a les belles nouveautés et ce qui peut passer en production ou en standard dans un développement. Comme l’a très bien dit Mehdi Kabab ci-dessus, qu’une pratique soit intéressante n’empêche pas pour autant de l’utiliser sans jeter le bébé avec l’eau du bain.

Les fondements

Partons d’un bon exemple : j’adore cette animosité de nombreux développeurs front-end envers les préfixes CSS. Ok, je leur accorde que c’est parfois un peu pénible à gérer. De « je m’en fous » à « je ne mets que -webkit », « je m’en moque j’ai un pré-processeur », jusqu’à dernièrement le « on va le post-processer ». D’élément ignoré, ensuite central, après pré-processé pour finir post-processé. Genre on s’en fout, on s’en occupe, on pré-délaie et on post-délaie.

Mais hé oh ! Je vais vous rafraîchir la mémoire : à la base, c’est un système expérimental pour tester des implémentations. Si un certain Daniel Glazman a secoué le cocotier pour nous faire tomber des noix sur le crâne, c’est que nous avons été trop fainéants pour respecter la base du Web : son universalité (et accessoirement sa pérennité). Si les médecins qui ont prescrit trop d’antibiotiques doivent assumer les bactéries multi-résistantes, hé bien les préfixes, ce sont nos enfants, c’est à nous de les assumer.

D’aucuns vont me traiter de chiant, je leur répondrai qu’il faut assumer la part du contrat : le Web est un système pensé pour être universel et pérenne, alors on doit accepter de gérer cette universalité. Point barre. Je ne dis pas de le faire parfaitement, moi-même, j’en suis bien loin, je dois faire des choix.

Moi qui pensais que les avantages des standards avaient suffisamment été compris, je vois que ce travail n’est pas terminé…

Évidemment, les préfixes ne sont qu’un symptôme. Quand je vois qu’on trouve révolutionnaire de penser d’abord HTML, ensuite CSS par dessus et enfin JavaScript, il y a de quoi faire un bond, ce sont les fondements du Web !

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1614

13 commentaires

Posté par Da Scritch le 09/03/2014 à 18:17:54
Tu as tout a fait raison.
C'est terrible d'avoir à la fois un manque de recul et surtout l'oubli de la mission première du web.
J'ai l'impression que bon nombre de gens que j'ai croisé ne songent qu'à mettre plein de brillants dans les yeux de leur prospects, sans même se soucier que cela va poser énormément de problèmes avant la livraison.
Posté par Thomas le 09/03/2014 à 20:36:35
Je te rejoins sur ce point de vue !

J'ai également constaté que de nombreux développeurs/intégrateurs ont tendance à oublier une chose essentielle sur le web : le résultat doit être conforme aux attentes du client et/ou des internautes, peu importe le moyen utilisé.
Posté par Lionel le 10/03/2014 à 9:01:32
Hello,
Antant je te rejoint sur le fond, autant je trouve que l'exemple et mal choisi. Le problème de l'utilisation des préfix se posent dès lors qu'on lie la réussite d'un projet à leur utilisation (flex-box, transition, etc), c'est ici que cela pose problème. Si leur utilisation n'est là que pour de l'enrichissement, alors je trouve que l'approche post-process est la plus saine, car elle fournit un résultat optimal pour une coût assez faible (l'utilisation d'un transpiler) tout en évitant de connaitre l'état de chaque feature css (ou mieux d'aller vérifier avant sur w3c, à chaque fois que l'on souhaite utiliser un prop css).
Posté par Nico le 10/03/2014 à 9:41:01
J'ai dû mal m'exprimer : évidemment, poser la réussite d'un projet sur un truc instable, c'est une mauvaise idée. Tu noteras que je ne dis pas que les préfixes sont mal, ce que je dis, c'est que c'est mal de ne pas les gérer correctement (peu importe la méthode).
Posté par Nyalab le 10/03/2014 à 11:03:01
Nicolas, ne confonds pas le manque de recul et ton manque d'avance. Le fait même de l'invention du pré-processing, de passer de pré-processing à post-processing, d'automatiser des tâches est le résultat de types qui prennent du recul.

Tu mélanges deux débats, le fait d'utiliser des préfixes ou pas, et le fait d'automatiser ceux-ci. Une fois que le choix est fait d'en utiliser, le moyen technique d'y arriver n'est pas important. Je ne vois pas en quoi limiter l'automatisation vient donner du crédit au fait d'en utiliser ou pas.

Y'aura toujours 3 groupes : les types qui adoptent trop vite mais font que le truc évolue, les types modérés qui eux adoptent quand c'est stable et font avancer le truc plus lentement mais à plus long terme, et les types qui adoptent en retard ou pas du tout, qui eux ne servent qu'à râler. Les 3 groupes existent toujours mais il y en a toujours un qui sert moins que les autres et qui même va essayer de freiner les 2 autres.

Bref, laisse les gens qui essaient d'aller plus vite et d'inventer de nouveaux trucs avancer et peut-être se casser les dents. Parce que sur la quantité de nouveaux trucs, même si tu te casses parfois les dents, il en ressort souvent de bonnes choses (et là je parle de la réécriture ou de l'oubli de l'histoire, que toi tu fais).
Posté par Nico le 10/03/2014 à 11:19:23
Nyalab : visiblement, tu n'as pas lu le dernier commentaire, ni le billet apparemment. Je te remets le passage du billet :

"Qu’on s’entende bien : c’est bien de tester des nouveaux trucs, de voir de nouvelles techniques, etc. je ne vais pas dire le contraire, c’est même indispensable.

Seulement, il y a les nouveautés et ce qui peut passer en production ou en standard dans un développement. Comme l’a très bien dit Mehdi Kabab ci-dessus, qu’une pratique soit intéressante n’empêche pas pour autant de l’utiliser sans jeter le bébé avec l’eau du bain."

Je te remets le dernier commentaire : "Tu noteras que je ne dis pas que les préfixes sont mal, ce que je dis, c'est que c'est mal de ne pas les gérer correctement (peu importe la méthode)."

Et ne t'inquiète pas pour mon « manque d'avance », tu parles à quelqu'un qui a son propre micro-framework CSS et qui publie régulièrement des infos sur des essais ou des approches.
Posté par swoop le 10/03/2014 à 11:29:04
BANG HEADSHOT
Posté par Nyalab le 10/03/2014 à 11:52:07
J'ai bien lu ton article et les commentaires Nicolas, du coup si on enlève le débat sur l'utilisation ou pas des préfixes vendor, il reste quoi ? 10 paragrpahes sur "prenez du recul", qui, sans exemple précis, ne veut pas dire grand chose (à la limite parle nous de flexbox je sais pas, un truc quoi).

Pour le reste "J'ai mon propre framework" is the new "J'suis pas raciste j'ai un ami noir". C'est pas parce que tu as push un truc sur Github que ça le rend bon, j'suis désolé, je suis allé voir ta lib et j'y vois rien d'exceptionnel. Tu n'utilises pas de notation particulière qui la rendrait réutilisable, tu nous fait le coup des classes css atomiques : .left { float: left } bravo, mais tu comprends que [dir="rtl"] .left { float: right }, ton css n'a plus aucune valeur sémantique. Et c'est pas ajouter une liste de w1, w2, ... w100 qui va apporter une quelconque valeur sémantique à mes css. Avoir un framework css qui fait que des raccourcis de noms de classes pour se retrouver avec un DOM div class="left center fontsize14 width100", autant m'écrire un style="...". Puis aucun namespacing, repli de "/* à adapter selon le design voulu */", je vois pas l'intérêt d'en faire un framework, tu t'es juste fait une feuille de style perso qui te va à toi, je vois pas en quoi c'est être dans le futur où la tendance est au réutilisable.

J'ai pas envie de faire tout le framework, parce que je veux pas que ce soit une attaque ad-hominem. Mais n'essaie pas de me décridibiliser dans mon commentaire en me disant que j'ai mal lu ou que tu as fait autre chose à un autre moment (sourire))
Posté par Nico le 10/03/2014 à 12:03:12
Libre à toi de ne pas apprécier mon micro-framework, comme on dit : feel free to ignore me.

Les classes atomiques ne sont que des helpers, enfin, on ne va pas ergoter sur ce « détail », vu que tu en es à me ressortir l'éternel débat des classes sémantiques.

Prends du recul, c'est l'utilisation qui en est faite qui est importante. Et laisse-moi me casser les dents avec. (Sourire qui tue)

EDIT : juste un détail, si cet article est si vide que ça, pourquoi perds-tu autant de temps à le commenter ?
Posté par Nyalab le 10/03/2014 à 12:10:54
Parce qu'avec tout le temps que j'économise en préprocessing de mes CSS, j'ai le temps de te répondre.

Hors troll, parce que faire changer les mentalités, pour moi, ce n'est pas perdre du temps. Et je n'ai pas envie qu'un jeune dev arrive sur ton billet, et se rentre dans le crâne qu'il faut toujours réfléchir 20 plombes avant d'embrasser le changement, qui plus est en front-end dev.
Posté par Nico le 10/03/2014 à 12:25:01
> Et je n'ai pas envie qu'un jeune dev arrive sur ton billet, et se rentre dans le crâne qu'il faut toujours réfléchir 20 plombes avant d'embrasser le changement, qui plus est en front-end dev.

Tu m'expliques où c'est marqué ? Je dis juste qu'il y a des choses qui ne peuvent pas passer en production ou en standard n'importe comment, j'ai pas dit d'être réfractaire à tout ! Science sans conscience n'est que ruine de l'âme.

Je vois pas en quoi ça empêche d'embrasser le changement quand il fonctionne et ne gêne en rien, et vu le métier, effectivement, vaut mieux s'y habituer.

Allez, fin du troll.
Posté par Knuc le 10/03/2014 à 12:25:46
Merci Nico33333333 j'ai ri.
Posté par Gaël le 10/03/2014 à 13:08:43
Je suis profondément d’accord avec le message — et je trouve l’exemple bien choisi.

Je reçois parfois des demandes (et j’en lis sur certains forums) de personnes qui ont lu un tutoriel sur Codrops et qui demandent de l’aide parce que « ça ne marche pas alors que j’ai tout bien fait ».

Sur la façon d’appliquer les préfixes, des outils tels que Compass ou Bootstrap sont tellement hors du coup sur certains points que ça en devient écœurant.

On peut également citer jQuery et sa pléïade d’extensions, qui sous prétexte de facilité d’utilisation bafouent la plupart des principes de bases de javascript et de l’accessibilité du web — malgré le travail incroyable du Paciello Group sur jQuery UI qui peut les aider.

Mais effectivement, n’importe quel exemple colportera son mini-troll; mieux vaut revenir aux fondements et aux valeurs du travail — quel qu’il soit : il n’y a pas de mauvais outils, il n’y a que de mauvais ouvriers.

(et j’ai ri aussi avec ce joli troll).

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.