Amélioration progressive pour javascript?

Question

La plupart des gens parlent de l'amélioration progressive en ce moment comme le fait de servir les navigateurs avec javascript (version améliorée), et les navigateurs sans javascript (version simple).

Mais il existe une telle différence de performance javascript entre les navigateurs qu'il peut être utile d'appliquer ce terme pour prendre en charge le choix entre les fonctionnalités basées sur javascript entre les navigateurs.

Dans une application Web complexe avec de nombreuses fonctionnalités (et animations) non absolument essentielles, est-il utile de commencer à penser à les boucler par exemple, ces ensembles de fonctionnalités devraient fonctionner dans tous les navigateurs, et ces fonctionnalités uniquement dans Chrome et Safari, et ceux-ci dans Firefox et Chrome et Safari et Opera, et ainsi de suite, car l'activation de certaines fonctionnalités dans certains navigateurs serait trop lent.

Parfois, j'ai l'impression que l'expérience utilisateur s'améliorerait si elles n'avaient pas accès à certaines fonctionnalités non essentielles. Par exemple, interdisant aux utilisateurs d'IE de redimensionner certains panneaux que les utilisateurs de Chrome pourraient redimensionner.

Answer 1

Cela ressemble à un cauchemar de maintenance.

Je me rends compte qu'il y a des applications web où il n'est pas logique d'avoir une version html. Cela dit, si c'est possible je commencerais par construire une version html de chaque page d'abord, puis utiliser JavaScript pour améliorer l'expérience utilisateur.

IE est moins performant que Safari, Chrome et FF quand il s'agit de JS - mais avez-vous vraiment développé une page qui est inutilisable dans IE avec JS allumé? Je ne l'ai tout simplement pas vu - dans la nature je pense que les différentes implémentations de JS sont assez rapides.

Answer 2

Deux problèmes avec les navigateurs ces jours-ci:

1. vitesse. Mon expérience a été que IE 7 fonctionne bien, juste beaucoup plus lent que le reste. Ma solution est de donner des mises à jour de progression de l'interface utilisateur plus fréquentes aux utilisateurs. Depuis la mise à jour de l'interface utilisateur prend du temps, je minimise les mises à jour sur les navigateurs plus rapides. Par exemple sur IE je mets à jour l'écran avec plus de feedback après avoir traité 50 autres évènements. Pour les autres navigateurs, après avoir traité 200 événements.

2. Manque de fonctionnalité. Par exemple la toile. Mais c'est une grosse dépense pour construire plusieurs sites. Et testez-les aussi. Donc, je dépense mon budget sur une version pour tous les navigateurs de bureau actuels. Et faire des sites supplémentaires pour mobile iPhone d'esp.

HTH,

Larry

Answer 3

Ce que je fais est d'écrire un fichier javascript de base qui a la fonctionnalité commune, allant au plus petit dénominateur (javascript 1.5). J'ai alors d'autres fichiers pour les versions plus récentes de javascript, et ceux-ci vont remplacer les fonctions dans mes objets javascript, de sorte que je puisse progressivement ajouter plus de support. Si je veux utiliser la balise canvas, alors je peux ajouter cela dans un fichier différent, puisque IE et Firefox/Opera/Safari diffèrent dans la façon dont ils créent l'élément canvas.

Ce n'est pas un plaisir pour la maintenance, mais si je veux utiliser les nouvelles fonctionnalités html/javascript, cela semble être le meilleur modèle.

Answer 4

Je ne l'ai pas fait moi-même, mais je vois que cela fait beaucoup de sens si votre budget le permet (et vous ne pouvez pas contrôler le choix du navigateur de votre utilisateur)

A la fin de la journée , Les utilisateurs d'IE peuvent utiliser un navigateur lent, mais ils sont toujours vos utilisateurs. Donc, si vous voulez donner à tous vos utilisateurs la meilleure expérience utilisateur possible, il peut être utile de passer du temps à donner aux utilisateurs d'IE une version différente de l'application pour leur donner un niveau de performance supérieur.

Une application rapide pour 99% de vos utilisateurs est sans aucun doute meilleure qu'une application rapide pour seulement 30% de vos utilisateurs. La seule question est de savoir ce qui est le plus important - l'expérience utilisateur ou le temps de développement (et compte tenu du fait que dans quelques années, l'utilisateur moyen utilisera des navigateurs plus rapides sur des ordinateurs plus rapides). Cependant, d'après mon expérience, vous serez souvent surpris par la partie du code qui est lente et la partie du code qui est rapide. En outre, Lombardi Blueprint a une approche très intéressante, bien que probablement impraticable en dehors de GWT. Ils ont des algorithmes de mise en page écrits en Java, écrits de telle sorte qu'ils peuvent être exécutés à la fois du côté client (via GWT) et du côté serveur (via un jvm standard). Par conséquent, en fonction des performances comparées de votre navigateur, ils peuvent basculer dynamiquement entre la mise en page côté client (pour les navigateurs rapides) et la mise en page côté serveur (pour les navigateurs plus lents).

Answer 5

Je suis d'accord avec Andy. Fournir une version différente d'une application à différents navigateurs est un problème de maintenance potentiel sur la route. J'ai toujours trouvé qu'il était préférable de fournir une version d'application qui fonctionne dans tous les navigateurs. Par exemple, j'essaie d'éviter les renifleurs de navigateur. L'application n'est peut-être pas la plus cool, mais elle fonctionne pour tout le monde et est plus facile à maintenir.

Ce genre de choses est maintenant plus facile avec toutes les bonnes bibliothèques Javascript qui résument certaines des différences du navigateur. En outre, vous pouvez faire beaucoup de choses dans les anciens navigateurs. C'est juste fait "différemment";)

Answer 6

Donc disons que vous construisez une application de taille décente. Vous avez le gogo de renifleurs de navigateur pour déterminer quelles fonctionnalités seront activées et lesquelles seront désactivées. Vous avez flairé Opera 9.x, et maintenant (aujourd'hui en fait) Opera 10 sort. Vous devez aller mettre à jour chaque renifleur sur chaque page. Et puis un autre navigateur sort bientôt ... et un autre. Vous allez passer tout votre temps à déterminer les navigateurs que vous supportez et les fonctions à prendre en charge.

J'utilise plusieurs navigateurs en un jour. Donc, quand je vais sur votre site, je vais voir trois interfaces différentes. Je serai confus, puisque les caractéristiques que je m'attendais à être là, ou les comportements que je m'attendais ne seront pas là. Finalement, je serai frustré et ne retournerai jamais sur votre site.

De plus, il y a plus de rapidité avec JavaScript qu'un simple navigateur. J'ai toujours un vieux Pentium exécutant Firefox 3.5. Parfois, il peut être douloureusement lent.

Answer 7

Je pense que la réponse est que vous devez catégoriser votre code en catégories de vitesse, et pas seulement classer dans les capacités du navigateur. En d'autres termes, donnez à votre site des niveaux de fonctionnalités, le premier niveau est html basique, le deuxième niveau est l'amélioration de l'ergonomie javascript, le troisième niveau est l'animation javascript eye candy.

Ensuite, faites une combinaison de permettre à vos utilisateurs de descendre un niveau quand ils le veulent, "Cliquez pour désactiver les animations!", "Cliquez pour activer les animations!« « Cliquez pour voir en html de base », et le choix par défaut à certaines catégories de vitesse en fonction de navigateur pour des raisons de vitesse (par exemple si IE7 semble montrer des problèmes de vitesse avec les animations complètes sur, faire défaut à la seconde » javascript amélioration de la facilité d'utilisation