Existe-t-il un raisonnement solide pour expliquer pourquoi les sites ne devraient pas être développés avec une fonctionnalité ajax qui charge les principales parties de chaque partie (en supposant que des éléments comme l'en-tête, la navigation, etc. restent les mêmes)?

Ce serait sûrement moins gourmand en ressources, car le serveur n'aurait pas à diffuser le contenu qui apparaît sur chaque page, ce qui profiterait à la fois à l'hôte et à l'utilisateur final.

Répondez à la question en prenant en considération:

• Le comportement javascript des sites se dégrade gracieusement dans chaque cas

• Pour ma question, je parle de nouveaux sites où ce comportement pourrait être mis en œuvre plutôt à partir du début, donc cela ne coûte techniquement pas d'argent - nous ne retournons pas à un produit fini pour le mettre en œuvre.

Si le contenu peut être atteint sans JavaScript activé, votre question n'a aucun sens. Ce n'est pas "entièrement Ajaxifié" si vous pouvez accéder au contenu par d'autres moyens. Vraiment, ce que vous demandez, c'est "est-il correct d'améliorer l'expérience de mon utilisateur via Ajax?". La réponse est évidemment "oui".

Éditer

À l'époque où Google est sorti avec sa proposition Ajax explorable, elle a été considérée comme une très mauvaise idée . Fait pour une lecture intéressante.

Tout d'abord

Les avantages

• AJAX peut vous permettre d'utiliser une page "de base" commune et de simplement charger les zones de contenu, ce qui peut réduire le temps de chargement pour les utilisateurs, car une grande partie de la page est déjà chargée.
• Peut permettre un régal pour les yeux comme la décoloration de la zone de contenu.

Les inconvénients

• Ne joue pas bien si la page est téléchargée.
• Peut jouer avec des appareils pour personnes handicapées.
• Les téléspectateurs dont javascript est désactivé ne pourront pas du tout utiliser le contenu à moins qu'une version non javascript soit également utilisée.
• Beaucoup plus de travail (faut-il vraiment le dire?).

Maintenant pour votre question

En supposant que votre site se dégrade gracieusement pour ceux qui ne disposent pas de Javascript, le résultat dépend de la façon dont cela se fait. Par exemple, si vous affichez un lien vers une version non javascript à l'improviste, c'est un inconvénient pour ces téléspectateurs d'avoir à cliquer sur un autre lien. D'un autre côté, s'il existe une "page principale" noscriptive qui utiliserait des liens traditionnels, qui fonctionne mieux pour la plupart des utilisateurs, mais qui ne prend toujours pas en charge ceux qui utilisent des appareils pour personnes handicapées, des cas où l'utilisateur vient pour une "page" spécifique d'un lien, etc.

Dans l'ensemble, dans le monde de la connexion Web de plus en plus rapide, cela ne justifie pas vraiment de couper une petite quantité de fichiers (nous présumerons que tout le Javascript lui-même, le CSS et les images peuvent et seront mis en cache, laissant juste la page "de base" elle-même pour économiser des octets) pour les inconvénients qu'elle peut donner, à savoir la difficulté supplémentaire (bien que ce ne soit pas toujours un problème est bon) et le manque de support qu'elle peut apporter à certains utilisateurs.

Dans l'ensemble, je dirais que cela dépend de vous, cela fonctionnerait probablement assez bien, et pour la grande majorité des utilisateurs, ils verront probablement le site comme prévu, mais personnellement, je dirais que non dérange, car cela ne vaut pas la peine pour une telle amélioration marginale de la taille du fichier.

Consultez http://gawker.com/ - ce site se charge presque complètement après coup. Ils utilisent "hashbangs" ( http://mydomain.com/#!some_section) pour déterminer quelle page de contenu doit être chargée, la navigation principale reste statique.

Consultez http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ pour un court tutoriel sur le concept utilisé par Gawker.

Il y a des avantages et des inconvénients, vous devez prendre en compte les moteurs de recherche (voir http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), les personnes avec Javascript désactivé et faire beaucoup de tests.

Cela dit, le plus gros argument contre eux est probablement que lorsqu'un utilisateur attend le chargement d'une page, puis doit attendre plus de chargement, il peut être impatient. À mon avis, la meilleure pratique consiste à charger le site principal, la navigation et le contenu principal en un seul passage (sur demande) et à enregistrer l'AJAX pour les faux frais non essentiels. Cela fonctionne avec l'idée d' amélioration progressive et mélange le meilleur des deux approches.

Parce que ce n'est probablement pas nécessaire.
Le chargement de documents HTML de base est simple et fonctionne. La présentation d'Ajax ajoute une toute autre couche de processus pour les navigateurs, le code et la maintenance du Javascript, des trucs d'arrière-plan, des URL de hashbang étranges, etc. Parfois, cela peut être justifié, parfois non. Cela pourrait vous faire économiser des ressources de serveur (peut-être), mais cela suffira-t-il pour compenser l'entretien? Vous devez évaluer ce par projet.

Par exemple, lorsque Twitter a obtenu sa dernière refonte, ils ont adopté l'approche selon laquelle ce n'était pas seulement un site Web (page), mais une application, et le tout est fortement basé sur Ajax, même si la plupart de ce qu'il fait pourrait être traité avec des demandes de page régulières. L'un des plus gros problèmes, qui se produit encore aujourd'hui bien que beaucoup moins, est d'arriver là-bas et d'être accueilli avec une page blanche parce que quelque chose dans l'Ajax a échoué.

Dans la pratique, il faut beaucoup de travail pour produire un site Web «entièrement AJAX», en particulier pour les principaux sites Web qui sont très compliqués. Certains sites Web qui tentent cela sont Google et Facebook, mais même ils ne le font pas parfaitement.

Les problèmes courants sont la navigation (c'est-à-dire en avant et en arrière) et les signets, mais il existe de nombreux autres bogues que beaucoup de développeurs préfèrent ne pas avoir à traiter. Et cela signifie essentiellement créer deux versions du site Web pour être compatible avec les utilisateurs Javascript et non javascript (et les correctifs pour tous les navigateurs avec un mauvais support AJAX).

Oui, cela devrait l'être, mais ce devrait être l'inverse.

Les parties communes de la page doivent être envoyées via HTTP. Ensuite, un petit contrôle ajax (ou même mieux Websockets) charge le contenu dynamique de manière asynchrone.

Bien sûr, vous devez d'abord détecter si javascript est activé (par cookie) et utiliser cette méthode uniquement si elle est activée.

Vous avez donc besoin de l'itinéraire HTTP complet normal, puis d'un itinéraire Websockets. Cela nécessite la duplication de code sauf si vous utilisez un outil comme node.js

La plupart des gens "pensent" que cela ne vaut tout simplement pas l'effort supplémentaire. Et parfois ce n'est pas le cas.

En passant, beaucoup de gens ajaxment les pages de manière incorrecte. Ils décident en fait que vous n'avez pas besoin d'une version non javascript et que vous avez besoin de toutes ces étranges URL de hachage et de boutons avant / arrière cassés. Faire ajax correctement nécessite un historique HTML5 (IE9 ne l'a pas). Il nécessite également que le développeur complète les versions de votre site Web.

Puisque vous avez déclaré que cela se dégraderait gracieusement pour les visiteurs avec Javascript désactivé, je ne peux voir que deux problèmes réels (et un problème possible) qui pourraient survenir.

Mauvais pour l'accessibilité

Les lecteurs d'écran et autres technologies d'assistance sont souvent découragés par les changements dynamiques du DOM. Ils traitent et lisent la page de manière linéaire, et la modification du contenu de la page après son chargement peut ne pas être correctement gérée.

Il y a peut-être des techniques pour contourner cela, mais je ne l'ai pas trop étudié.

Complexité accrue

La maintenance de ce type de site peut être délicate. Par exemple: si vous avez créé une nouvelle mise en page et modifié l'ID de la zone de contenu que vous remplaciez par vos liens AJAX, cela pourrait briser votre schéma de navigation d'une manière assez déconcertante.

Ce type de comportement AJAX compliquerait également toute analyse de trafic que vous pourriez faire; Google Analytics n'enregistrerait pas correctement ces charges AJAX sans un appel manuel à pageTracker._trackPageview('this_page');.

Ajouter plus de complexité au fonctionnement de votre page relève également la barre pour les nouveaux développeurs; toute personne travaillant sur le site devrait probablement être informée de la manière dont ce comportement affecte le chargement des pages.

Possible: chargement de page plus lent lors de la première visite

Selon la façon dont vous structurez les choses, cette page récupérant le code AJAX ne pourra démarrer qu'après le chargement complet du document. Donc, seulement après que votre visiteur a téléchargé la page entière, puis le Javascript (s'il s'agissait d'un fichier externe), et son navigateur l'a rendu et récupéré le contenu via AJAX, verrait-il le contenu de la page.

Chaque lien suivant cliqué serait plus rapide, mais la récupération de la première page visitée par un utilisateur prendrait en fait plus de temps qu'une version statique.

La raison pour laquelle j'ai étiqueté cela comme un problème possible est que vous pouvez toujours envoyer la première page statiquement (car vous aurez déjà la version statique comme solution de rechange), puis utiliser AJAX pour les liens suivants.

Pour ce que ça vaut, cela ne me semble pas une idée terrible - en particulier pour les utilisations sensibles à la bande passante comme les pages mobiles. Vous devrez cependant peser soigneusement les inconvénients pour vous assurer que cela en valait la peine dans votre cas.

Avoir des éléments ajax sur une page est très bien quand vous avez une petite base d'utilisateurs, mais quand vous avez plus de trafic; vous souhaitez utiliser une approche plus statique pour réduire l'abus de ressources.

Par exemple: supposons que 200 personnes essaient d'accéder à une page par seconde. Vous avez environ 7 requêtes de base de données pour vos appels ajax; c'est-à-dire 1400 appels de base de données par seconde, ce qui peut enliser un site Web.

Un site Web qui doit être conçu pour un trafic plus élevé doit avoir des pages statiques tournées vers l'extérieur, pour un contenu pouvant être affiché de manière statique. Ceci est réalisé en utilisant un script côté serveur qui s'exécute chaque seconde pour reconstruire la page statique, qui est récupérée pour l'utilisateur final, et ainsi vous avez réduit votre charge de 1400 appels de base de données par seconde à 7.

Il s'agit d'une approche SOA pour la création de sites Web.