Anthony Ricaud

À propos Archives RSS

Mot-clé - web

Fil des billets

mercredi 28 mai 2008

Google Ajax Librairies : une bonne idée ?

Par Anthony Ricaud le mercredi 28 mai 2008, 09:41 - Informatique

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.

4 commentaires

vendredi 25 janvier 2008

Please, don't hurt the web, des solutions

Par Anthony Ricaud le vendredi 25 janvier 2008, 21:15 - Informatique

Le web continue à se remuer après l'annonce de Microsoft. Anne van Kesteren explique d'ailleurs très clairement le problème que ces modes causent. Certains prépare des solutions de boycott, d'autres cherchent une solution alternative pour coller aux besoins de l'équipe IE tout en favorisant les standards. La solution de David Baron est ma préférée. Comme je le disais, la principale inquiétude de Microsoft tourne autour des Intranet. Laissons donc le reste du web bénéficier d'un vrai rendu standard. Les administrateurs des réseaux d'entreprises choisiraient quels sites doivent être vus avec un autre moteur que celui de base. Ce n'est pas aussi bien que des modes de rendus très proches qui évoluent ensemble mais on ne peut demander à Microsoft de recommencer le travail sur IE8 depuis le début.

Je suis d'ailleurs tombé sur le meilleur résumé possible de toutes ces discussions.

jeudi 24 janvier 2008

Please, don't hurt the web

Par Anthony Ricaud le jeudi 24 janvier 2008, 01:20 - Informatique

IE-LockEt bien il fallait bien ça pour sortir ce blog de sa torpeur : Compatibility and IE8. Je ne ferais pas l'inventaire de toutes les réactions (on peut trouver assez de liens sur le QA Blog du W3C, mais ça fuse de partout. Que ce soit chez Mozilla, Webkit, Opera ou chez les développeurs web. Il y a bien quelques satisfaits tout de même.

On nous explique que ce nouveau mode de choix du rendu a été inventé par pragmatisme. Lorsque l'on était en mode "standard", on utilisait des hacks pour corriger les bugs de IE6. À l'arrivée de IE7, cette technique ne fonctionne plus puisque les hacks de contournement ont été corrigés mais pas les bugs en question. L'équipe de IE s'était dit que les améliorations n'étant disponibles qu'en mode "standard", le web ne serait pas cassé. C'est là que vient le pragmatisme : "faut pas refaire pareil !".

Les pages sont conçues à un moment précis, pour une version précise du moteur de chaque navigateur. Et bien inventons un moyen de fixer ces pages définitivement. Ça part donc sur une bonne intention, pleine de bon sens.

Là où le bon sens déraille, c'est que cela implique que chaque version d'IE devra intégrer toutes les versions précédentes jusqu'à IE6. Est-ce pragmatique, réalisable ? Bien sûr que non. Il y aura toujours des différences de rendu au fur et à mesure, pour s'adapter à une nouvelle version du système d'exploitation, des changements matériels, etc.

Bon, admettons que ce soit possible (oui, faîtes un effort). Je mets donc un tag pour bloquer à IE8. Mais quel IE8 ? Celui de la sortie ou celui un an plus tard avec les corrections de sécurité ? Ça pose encore plein de problèmes comme les frames et iframes mélangeant des pages ne souhaitant pas le même mode de rendu. Ou encore la question des copier/coller pour "widget".

Ce principe de choix du moteur rappelle aussi les très belles heures du web "Conçu pour Internet Explorer en 800x600". Ressortez tous vos gifs animés !

Évidemment, j'espère que Microsoft reviendra sur sa décision. On voit clairement que cette décision a été prise pour les Intranet qui restent encore la quasi chasse gardée de Microsoft vu l'inertie (tout à fait naturelle) des entreprises. Cette décision n'est pas néfaste pour les pages déjà existantes mais pour les prochaines à venir. Le slogan "Don't break the web" regarde en arrière, jamais en avant.

Au fait, comment fait IE8 pour passer le test Acid2 ?

PS : Merci à Sunny pour son logo

Update : Des solutions ?