Google Ajax Librairies : une bonne idée ?
mercredi 28 mai 2008 - 4 commentaires
Google vient donc d'annoncer la possibilité de servir 5 librairies javascripts depuis ses serveurs.
L’idée d’avoir un dépôt central est plutôt intéressante. Pour avoir un cache relativement partagé entre les sites, être sûr de la configuration HTTP au poil, bénéficier du CDN de Google. Après, il faut aussi voir que l'accès à votre site sera conditionné par la disponibilité de ses serveurs. Mais il semble que ce soit la tendance... (Amazon S3)
Par contre, Google propose de s'occuper de charger la dernière version à travers son API Javascript. C’est une très très mauvaise idée que d‘avoir la version la plus récente de la libraire. Il faut toujours tester ses applis avant de mettre la nouvelle version d’une librairie en production. À la rigueur pour les versions mineures, et encore.
Après, cela va certainement défavoriser les librairies non sélectionnées. Des librairies comme Base2, Mochikit ou YUI ne sont pas listée par exemple.
Enfin, Google a annoncé vouloir travailler avec les éditeurs de navigateurs pour intégrer certaines librairies directement dans le navigateur. Si jamais cela se réalise, ça va être marrant pour les versions et encore plus discriminant pour les librairies non incluses. Les développeurs choisiraient non pas la librarie la plus légère ou la plus performante mais la plus souvent intégrée dans les navigateurs.
Google ferait mieux de travailler avec les éditeurs pour améliorer le support des standards et l’implémentation des prochains standards. Car un code en C, C++ ou autre sera toujours plus performant que sa version Javascript.
En résumé : idée peut-être intéressante dans l’état actuel d'implémentation des standards mais attention à la discrimination et surtout, continuer à améliorer le support des standards.
Commentaires
Tout à fait d'accord avec ton analyse sur le chargement des bibliothèques.
Par contre, utilisant jQuery régulièrement, je ne manquerais pas dorénavant de l'appeler via cette url :
http://ajax.googleapis.com/ajax/lib...
J'espère que cette pratique se généralisera.
C'était un des gros avantages de YUI. Cependant j'ai appris à le mitiger avec le temps. C'est une très bonne chose pour YUI, qui est utilisé pour une multitude de sites Yahoo!, et un utilisateur d'un site Yahoo! a toutes les chances de se retrouver à court terme sur un autre site Yahoo!.
Pour les autres j'ai peur que la probabilité d'avoir un cache frais quand on se retrouve sur un second site qui utilise la même version de la même bibliothèque .. soit assez faible. Peut être même trop faible pour que la requête DNS supplémentaire se révèle positive en moyenne. C'est une histoire de masse critique mais j'ai peur que la masse critique soit dur à atteindre vu qu'il y aura une URL par version.
Sinon, sur les points négatifs à côtés :
- Les "loaders" ne m'ont jamais convaincus, du fait qu'ils nécessitent un aller-retour supplémentaire pour charger le loader.
- Je suis assez concerné par le fait que du coup les bibliothèques concernées sont dépendantes de Google, pour mettre à jour les URLS centralisées mais aussi pour le bon vouloir de continuer à diffuser ces fichiers. On pourrait même arriver à l'idée qu'une bibliothèque s'interdit de mettre une fonctionnalité déplaisante à google pour éviter d'être bannie. Dans l'idéal il faudrait que chaque bibliothèque contrôle son propre espace centralisé sur son propre domaine (quitte à ce que Google fournisse l'hébergement derrière). Au pire il faudrait au moins une déclaration d'intention de Google sur combien de temps ces URLs seront fonctionnelles, et un engagement sur un suivi des version minimum.
En ce qui concerne les versions :
"The second parameter of google.load is the version of the API, modeled after the versioning system originally used by the Google Maps API."
Comme le dit Éric, l'intérêt d'un loader est douteux. Il retarde le téléchargement de la librairie, mais ça fait toujours ça de plus à télécharger au final.