À l’instar de l’exemple de maintenance de base de données, le nouveau client e-mail de Yahoo permet aux utilisateurs, grâce aux touches flèches, de naviguer de ligne à ligne dans la liste de messages. Quand la ligne suivante est mise en évidence, le contenu du message associé s’affiche dans le cadre contenu. La performance est bonne grâce à un concept de préextraction et de mise en cache employé par Yahoo, qui stocke le contenu du message localement dans le navigateur, peut-être en utilisant des matrices JavaScript.

Quand des utilisateurs de e-mail atteignent un message qui n’est pas mis en cache localement, une page de chargement apparaît et la performance descend à un niveau comparable à celui des modèles page par page traditionnels. Quand les utilisateurs e-mail de Yahoo maintiennent une touche flèche enfoncée, l’écran de chargement apparaît quelques instants après, mais le client e-mail détecte bien sûr les événements de clavier répétitifs et les ignore plutôt que d’envoyer des requêtes répétitives au serveur. La morale de l’histoire est que les caractéristiques de performance de votre architecture serveur pourraient bien vous convaincre d’appliquer davantage de code côté client que vous ne le souhaiteriez. Les mécanismes de préextraction et de mise en cache prédictifs sont des idées intéressantes que vous pouvez appliquer côté client ou serveur. Et elles donnent de bons résultats avec un contenu statique comme des messages de courriel. Mais que se passe-t-il dans le cas d’une application chargée de visualiser et de maintenir des bulletins météo ou des horaires de vols d’avions qui changent fréquemment ?

Pour toutes ces raisons, je préfère les interfaces ILE natives dont les performances sont exceptionnelles et qui garantissent que les données affichées sur le client sont au même niveau d’actualisation que sur le serveur.