Da Linux French Page |
Lea-Linux |
Wikipedia |
Debian GNU/Linux |
O'Reilly
Si vous jetez un oeil au source de cette page (ou de n'importe quelle autre du site), vous ne verrez a priori aucune instruction CSS ou aucun script JavaScript dans le source XHTML; j'ai tout mis dans des fichiers séparés.
Loin de moi l'idée de vouloir me passer la pommade ou de me la faire passer mais le but est de montrer que c'est propre et réutilisable (encore faut-il avoir envie de le réutiliser me dira-t-on). En tout cas, je fais mon maximum pour simplifier la tâche du navigateur Web qui va interpréter le code pour l'afficher. Bref, tout ça pour introduire plus ou moins adroitement le modèle MVC appliqué au Web.
En fait, je me suis aperçu que généralement plus un modèle de conception était contraignant, plus il me plaisait. Masochisme? Allez savoir. En tout cas MVC me plaît bien. Il impose une séparation du contenu, de la forme et des actions que l'on peut réaliser. Plus de scripts JS de 500 lignes dans la balise <head>, de styles CSS dans un peu partout (je ne comprends pas ceux qui font ça d'ailleurs, autant rester avec les balises <font> et consoeurs), etc....
Du coup, on est "obligé" de travailler proprement, surtout lorsqu'on délègue toute la mise en page aux CSS (et non pas à grands coups de tableaux comme on le voit trop souvent) et qu'on attribue des noms de classes et des identifiants qui ont un rapport avec le contenu plutôt qu'avec la forme. Cependant, il faut veiller à ne pas tomber dans l'excès inverse: les tableaux c'est quand même utile quand on veut présenter des données ou autres sous forme de... tableaux.
Pour ce qui est des scripts, je dois avouer que la tâche est plus ardue. Je trouve la tentation des attributs onclick et autres tellement forte que je me demande si je m'en passerai un jour... Boah, allez, je vais essayer de faire sans, c'est vrai que ça fait plus propre mais ça demande un travail bien plus important. Le tout est d'espérer que ça rende le débogage et la maintenance plus aisée comme c'est le cas avec les CSS.
Ah, le JavaScript... Bouillie infâme pour certains, outil sympathique pour les autres (je reprends là les options d'un sondage sur LinuxFR), JavaScript a au moins ce mérite de ne laisser personne (parmi les geeks) indifférent. Plutôt tenté par la solution "bouillie infâme" il y a peu, je le (re?)découvre sous un autre jour qui ferait plutôt pencher la balance pour l'"outil sympathique".
Il faut voir qu'on est pas aidés avec le JavaScript aussi. En caricaturant à peine, on peut dire qu'il n'y a que les fonctions remplies par alert et confirm qui aient un résultat prévisible et une implémentation similaire sur l'ensemble des navigateurs et plateformes. Si le souci se limitait à plusieurs implémentations partielles, le mal serait moindre. Mais non, au lieu de ça on a des noms de fonctions, d'objets, de méthodes qui sont différents d'un éditeur à l'autre voire même d'une version de navigateur à l'autre (qui a dit IE?). On doit rivaliser d'astuce pour faire exécuter ce que l'on veut en conservant un code qui soit rapide et élégant. Le pire c'est que cela ne semble pas près de changer puisqu'en supplément des implémentations partielles et des implémentations différentes on nous offre une standardisation incomplète.
Un exemple? OK. L'objet XMLHttpRequest n'est pas standardisé. Ce qui est très con c'est qu'il s'agit de la pierre angulaire de ce qu'on appelle AJAX. Cependant, si la création de l'objet est différente sous IE et le reste des navigateurs, une fois l'objet créé l'API pour le manipuler est la même partout (ouf). Si ça n'avait pas été le cas, Gmail et le buzz AJAX qui s'ensuit n'auraient probablement jamais existé.
Un autre gros problème c'est que peu de gens tiennent compte du principe que JavaScript est un outil qui doit être là pour faciliter la navigation sur les sites sans l'entraver. Le code JavaScript doit réaliser un petit plus qui rend la vie sur un site un peu plus aisée mais sans devenir une obligation. Je prends l'exemple de la page sur le Toshiba Portégé R200: La table des matières est générée dynamiquement en fonction des balises <h?> contenues dans le document. Si on désactive JavaScript, il n'y a pas de table des matières ni de numérotation des sections mais la page reste parfaitement consultable.
Je ne surprendrai donc personne en avançant que la mauvaise réputation du JavaScript est due à un tas de gens qui ont foutu des popups, des boîtes de dialogues qui-te-demandent-ton-prénom-pour-afficher-bonjour-X-ensuite, des scripts de désactivation du menu contextuel, des images GIF animées qui suivent le curseur de la souris, etc. partout où ils pouvaient parce qu'ils venaient de découvrir un nouveau joujou aussi sensationnel que révolutionnaire. Ces gens-là auraient mieux fait de choisir des couleurs moins criardes pour leur site "made in Frontpage".
Enfin bref, tout ça pour dire que JavaScript ne mérite pas la réputation qu'il a. Son orientation objet basée sur les prototypes et non sur les classes est intéressante; la manipulation de fonctions comme des objets soulage franchement et il a le chic d'éviter autant que faire se peut l'écueil des méthodes get() et set() si lourdes et coûteuses comme le montre si bien Java. Si l'on ajoute à cela pour le JavaScript côté client une intégration aux navigateurs assez poussée et la manipulation via DOM des documents, on obtient un outil sympathique qui redore son blason grâce à Google et son Gmail.