Le second chapitre de « Even Faster Web Sites » m’a plus satisfait que le premier.Second chapitre. Il est nommé « créer des applications web réactives » et rédigé par Ben Galbraith and Dion Almaer, les fondateurs de ajaxian (vous connaissez forcément pas mal de mes liens pointent là bas).
Il n’y a plus de phrase qui accroche le lecteur, ce qu’on rapporte chez soi dépend du niveau d’implication qu’on souhaite y mettre, mais là nous avons un vrai chapitre d’informations techniques.
Réactif
Tout d’abord c’est un grand plaisir car on ne parle pas de javascript rapide mais d’application réactive. Le changement de point de vue est important, il s’agit de tenir compte de l’utilisateur comme de l’architecture mise en oeuvre. On ne se contente plus de tenter d’aller « plus vite » à code identique.
Ben et Dion reprennent les références de Jackob Nielsen, dont j’ai parlé il y a quelques jours.
Fils d’exécution
Sur la suite on parle beaucoup des fils d’exécutions (threads) et de l’incapacité du navigateur d’en gérer plusieurs. Votre navigateur fait le rendu, l’interface et javascript en un seul fil d’exécution. Si quelque chose bloque ou ralenti, c’est tout qui devient lent.
On y parle donc des « workers » de HTML 5 et de Google Gears. Là on nous donne des exemples de code, des explications, et on nous fait un petit encart sur du concret. On suit agréablement le fil rouge, même si peut être j’aurai préféré des exemples plus complets. Parfois ils sont avec des commentaires « c’est ici qu’on fait l’implémentation » mais c’est aussi aussi la contrainte d’un livre papier, avec une problématique de place et d’absence de couleurs.
À ces paragraphes je rajouterai un lien qu’ils n’ont pas donné : quand est-ce qu’un script est considéré comme trop lent ?
Mesures
L’autre sujet traité est le profilage du code javascript : repérer ce qui est lent. Je regrette que ce soit Date.getMilliseconds() qui soit mis en avant sans mettre en garde contre les imprécisions. Des gens comme Ben et Dion font certainement attention à faire des mesures en boucle avec des temps de l’ordre de la seconde, mais tous n’ont pas leur expérience.
Les temps retournés par les navigateurs ne sont pas précis quand on s’arrête à moins de 100 milli-seconde, du tout. Cela aurait mérité d’être signalé mais je suis peut être trop pointilleux.
Mémoire
À la fin du chapitre on a le droit à un passage sur la gestion de la mémoire. C’est un sujet intéressant, mais qui est traité ici avec peu de concret. À part inciter à faire attention et proposer de détruire les variables ou les noeuds DOM inutiles, il n’y a rien à ramener chez soi.
Il est indiqué qu’ils travaillent dessus, mais du coup ça fait un peu teasing. Le teasing ça passe sur un blog, mais ce n’est pas ce que j’attends d’un livre.
Pourquoi ne pas avoir parlé de réutilisation des variables, des problèmes de fuite de mémoire dans Internet Explorer ou de ceux liés aux gestionnaires d’événements ?
Alors ?
Au final, malgré la question de la mémoire, qui aurait du soit être vraiment traitée soit retirée du chapitre, et le petit détail sur la mesure en milli-secondes, j’ai bien aimé. On suit assez facilement le fil proposé par les auteurs, et on a des vrais informations utiles.
Peut être cependant qu’on aurait pu mettre ce chapitre plus loin dans le livre. La mise en application n’est ni le meilleur retour sur investissement côté performances ni le plus simple à réaliser.