Hijax (Traduction)

Mon objectif, en écrivant Scripter le DOM, était très clair : il s’agirait d’une introduction à Javascript et au DOM, dans laquelle j’insisterai sur les bonnes pratiques. J’avais volontairement choisi de ne pas couvrir les sujets plus complexes tels qu’XMLHttpRequest.

Cependant, pendant que j’écrivais ce livre, Ajax décollait totalement et il est rapidement devenu évident que je ne pourrais pas l’ignorer, sans non plus en parler en détail. C’est pour cela que j’ai rédigé le dernier chapitre.

Comme dans le reste du livre j’ai tenté de faire passer l’idée que l’amélioration progressive inclut automatiquement la dégradation élégante. Je craignais en effet que les développeurs qui appliquent ce principe en CSS ou en scriptant le DOM n’en tiennent plus compte dès qu’Ajax entre en scène.

Dans leur excitation, les développeurs s’écriaient : “Ce ne sont pas des pages web, ce sont des applications web !”

Il n’empêche. La plupart des applications, en ligne ou non, fonctionnent avec des documents. Qu’il s’agisse de Word, de votre messagerie, ou même de Photoshop : toutes manipulent des fichiers. Ajax apporte la possibilité de manipuler un fichier via Internet sans devoir recharger toute la page sans arrêt.

Les applications et les pages web ne sont pas mutuellement exclusives. Les premières sont construites à partir des deuxièmes. Et bien trop souvent, les développeurs se focalisent sur le mot “application”, au détriment du mot “web”.

Il existe un grand nombre de définitions de la méthodologie Ajax, mais la mienne se résume à :

La possibilité de ne mettre à jour qu’une partie de la page.

(Il ne m’a pas échappé que cette définition met flash et les cadres dans le même panier qu’Ajax).

Avec cette définition, vous pouvez avoir l’une des deux réactions suivantes, selon la façon dont vous voyez les choses :

Et alors ? Ajax nous permet de ne modifier qu’une partie de la page au lieu de la page entière, c’est tout.

Ou bien :

Nom d’un chien ! Ajax nous permet de modifier une partie de la page, au lieu de la page entière !

Les deux attitudes sont valides l’une autant que l’autre : la vraie valeur d’Ajax se trouve quelque part entre les deux. La valeur d’Ajax c’est de savoir qu’on peut récupérer des données du serveur de manière asynchrone, sans forcer un chargement complet de la page, tout en gardant à l’esprit qu’il s’agit d’actions sur des documents.

Si vous l’envisagez ainsi, utiliser Ajax pour créer des application Ajax qui se dégradent gracieusement est un jeu d’enfant. Je l’expliquais récement dans amélioration progressive avec Ajax, et l’idée est toute simple :

1. En premier, créez un site web traditionnel qui envoie des informations au serveur à l’aide de liens et de formulaires. Le serveur répond à chaque requête par une page complète.
2. Là-dessus, utilisez Javascript pour intercepter les liens et les soumissions de formulaires et transferez les informations au serveur via XMLHttpRequest à la place. Il ne reste plus qu’à mettre à jour la seule partie de la page qui en a besoin.

J’ai même trouvé un nom sympa pour lancer le buzz sur de cette technique : Hijax.

Bone, je vous l’accorde, ce n’est pas si simple que ça. Vous devez avoir conçu une architecture côté serveur suffisament modulaire, capable de renvoyer soit des pages complètes soit des fragments (astuce : les APIs c’est super).

Il peut vous sembler paradoxal de devoir concevoir un backend adapté alors que je viens de vous demander d’utiliser du HTML classique pour commencer, mais il n’y a rien de paradoxal si on pense Hijax dans l’ordre suivant :

• Concevoir pour Ajax dès le départ.
• N’implémenter Ajax qu’à la fin.

En vous y prenant ainsi, vous aurez construit à la fois un site web 2.0 et un site web 1.0, comme l’a récemment démontré Chad Dickerson. Il a testé deux applications Ajax (Gmail et Backpackit) avec Lynx, le navigateur en mode texte. Gmail est totalement inutilisable, alors que Backpackit fonctionne parfaitement.

Vous pouvez faire le même test vous-mêmes avec ma propre application Ajax/Hijax, Adactio ailleurs. Si vous utilisez Lynx ou un navigateur de mobile, rien ne manque hormis l’avantage du rechargement partiel que permet Ajax.

Thomas Vander Wal résume bien les problèmes des applications Ajax :

Quoi qu’il en soit, elle doit se dégrader gracieusement. Elle doit être accessible. Elle doit être ergonomique. Sinon, un certain nombre de gens (voire beaucoup) n’y verront qu’un joli machin inutile.

Si vous envisagez sérieusement d’utiliser Ajax et la dégradation gracieuse, pensez Hijax. Et si vous voulez un enseignement pratique et exhaustif sur Ajax, Hijax, l’amélioration progressive et la dégradation gracieuse, venez assister à mon atelier Ajax le 10 février prochain à Londres.