Dièse

Le buzz du moment, c'est Twitter qui va enlever le # de ses URL. Mais pourquoi ??? Essayons d'expliquer ça vulgairement.

Dièse

Serveur, client

Traditionnellement, une page web est générée par un serveur. Ce serveur contient des applications sous forme de script PHP par exemple, qui, selon l'URL demandée, construira un fichier HTML afin de l'envoyer à votre navigateur. Celui-ci se contentera d'afficher un rendu à partir des balises HTML du dit fichier et des CSS et Javascripts liés. Quand le client (vous, le visiteur) cliquera sur un lien, l'URL du navigateur changera, ce qui provoquera une requête vers le serveur indiquant que vous désirez le contenu de la page située à cette nouvelle adresse. Et ainsi, une nouvelle page est chargée, détruisant (dans la mémoire du navigateur) la précédente.

Dièse

Ressources

Twitter a conçu son site web sous forme de WebApp. Beaucoup d'autres ont fait ce choix : Facebook, Google+, Deezer, Overblog… Le but est de déporter une partie du calcul des pages sur le client. Quand on regarde de plus prêt le contenu d'un site web généré par le serveur, on se rend compte qu'une énorme partie des pages sont identiques : le header, le footer, les liens de navigation… entre chaque page générée, peut etre seulement 10% du contenu diffère avec la page précédente. Cependant, 100% doit etre recalculé par le serveur. Certes, on peut économiser des ressources en utlisant un cache. Cependant, sur un backoffice où on veut avoir des données constamment rafraichies, cette solution est loin d'etre efficace.

Pendant ce temps, les clients (vous) sont dotés de machines de plus en plus performantes dont les capacités sont sous exploitées. Ce que ça signifie, c'est qu'on peut exécuter de lourds scripts Javascript sans que cela n'ait d'impact sur votre expérience utilisateur. Donc, profitons de ces ressources inexploitées en faisant construire une partie des pages web par le client.

Dièse

WebApp

Quand vous chargez une première page d'une webapp, celle-ci est accompagnée de fichiers javascript qui vont construire le site web à la place du serveur. Ce javascript va constuire et assembler des morceaux d'interface et saura faire des requetes simples et rapides vers le serveur pour ne lui demander que des données unitaires à afficher. Par exemple, sur la page des derniers tweets, au lieu de demander au serveur de renvoyer 10 fois un gros pavé de tags HTML contenant le tweet, son auteur, la date formatée dans la bonne langue, les liens des retweets, le tout dans une soupe de tag suffisement complexe pour etre joliment mis en page, le serveur ne renverra qu'un objet JSON décrivant les données brute. Et la web app, le client, ira placer ces données dans les templates adéquats pour afficher le contenu dans la page web.

Dièse

Dièse

C'est bien beau tout ça, mais ça ne réponds pas à la question de départ ! Ce dièse, il sert à quoi ??

Une webapp, vous l'avez compris, c'est beaucoup de javascript. C'est lourd à charger la première fois. Les fois suivantes, les fichiers sont mis dans le cache du navigateur et ne sont pas rechargés, cependant, le navigateur nécessite un peu de temps pour lire et exécuter ces scripts. Dans un fonctionnement classique comme expliqué dans la première section de cet article, nous serions dans la meme situation que si vous quittiez et relanciez Word à chaque nouveau paragraphe. Il fallait donc trouver une solution à ça !

Le but est donc de permettre à l'uilisateur de changer d'URL, donc de page web, sans recharger le navigateur. Et c'est là que le dièse entre en jeu. Le dièse est utilisé pour faire un lien interne vers une ancre de la page. Cela veut dire que si je me contente de rajouter un #quelquechose à l'URL courante (http://www.alt-i.fr/diese.html#kikoo par exemple), le navigateur ne va pas demander au serveur cette nouvelle URL, mais va se contenter de chercher dans la page courante un élément possédant un ID identique au texte situé à la droite du dièse. La webapp est capable de regarder régulièrement (toutes les 10ms par exemple) quel est l'état de l'URL courante et elle est donc capable de savoir qu'à un moment donné, le hash, de son vrai nom, donc le dièse et son texte associé, a changé, et peut ainsi exécuter une fonction particulière, comme charger une nouvelle vue à afficher au visiteur.

Si vous avez tout suivi correctement, le dièse permet donc d'indiquer à la webapp un changement de contexte sans pour autant recharger la page.

Dièse

Suppression

Ok, mais… pourquoi on l'enlève alors ??

HTML5 arrive avec pléthaure d'API extrement pratiques. Parmi celles-ci vient l'API History. Cette API permet, en javascript, de changer l'URL courante sans provoquer de rechargement de la page. Et oui, ça fait exactement la meme chose que le dièse, mais de façon dédiée. Nous avons enfin une procédure conçue pour ça au lieu de devoir utiliser un workaround. Cette API permet de lire l'URL courante, de modifier celle-ci et d'envoyer un évènement quand elle change. Ansi, il suffit de modifier les liens pour que, au lieu de suivre leur adresse associée, il fasse appel à History pour lui demander de créer une entrée nouvelle dans l'historique. Un évènement est envoyé, et la webapp, avertie du changement d'URL peut exécuter le script qui va bien, demander les bonnes données au serveur et afficher la nouvelle vue sans avoir à recharger complètement la page.

Hybride

Pour finir, il faut encore expliquer pourquoi cette API History accélèrerait l'affichage des pages.

Le hash de l'URL n'est jamais envoyé au serveur. Donc quand vous demandez twitter.com/#!hadrienl ou twitter.com/#!search/alt-i, pour le serveur, la page demandée, c'est toujours twitter.com/. C'est donc toujours la même page qui est renvoyée, et c'est le javascript qui va, une fois chargé, lire le hash et aller chercher le bon contenu. Ce qui rallonge le temps nécessaire à l'affichage de la page de départ.

Avec History, les URL n'ont plus de hash. Le serveur prends donc connaissance de l'intégralité de l'URL : twitter.com/hadrienl ou twitter.com/search/alt-i. Ainsi, le serveur peut générer la page demandée, qui va s'afficher avant que le javascript de la web app ne soit chargé et exécuté. Puis celui-ci prendra la suite pour générer les pages suivantes.

TL;DR

Twitter propose donc le meilleur des deux mondes : un site web généré à la fois par le serveur et le client. C'est une gymastique très difficile mais qui tends à se démocratiser grâce aux nombreux frameworks qui apparaissent depuis quelques mois.