Avez-vous Ajax JSON ou HTML?

Je dirais que “a” est l’option avec laquelle vous voulez surtout restr.

Il est beaucoup plus facile de conserver des modèles cohérents côté serveur (vous pouvez les réutiliser dans des scénarios non AJAX).

Les modèles côté client ne sont pas très élégants (si vous voulez le faire, je suggère ceci: http://ejohn.org/blog/javascript-micro-templating/ )

En termes de style, j’inclurais une feuille de style réduite lorsque la page se charge, pas lors du chargement du contenu.

Je voudrais aller avec le HTML:

• faire la conversion de json en html ralentira le client (et vous ne saurez rien sur les performances du client de l’utilisateur)
• le faire dans json signifie que vous devez convertir deux fois (de la structure de données de votre serveur vers json, puis de json vers html)
• vous faites probablement le rendu au format HTML déjà sur le serveur, de sorte que vous avez l’infrastructure
• différence de trafic réseau sera négligeable
• vous pouvez utiliser des bibliothèques qui font tout le travail à votre place (par exemple, avec JQuery, un appel ajax renvoyant du code HTML devient simplement jQuery (‘# div’). load (url)).

Personnellement, je renvoie principalement des extraits de code HTML issus d’appels ajax, à moins que je ne doive faire quelque chose avec les données renvoyées par programme. Par exemple:

• Fonctionnalité de saisie semi-automatique. Renvoyez un tableau de données JSON, utilisez javascript pour créer les éléments appropriés.
• Tout ce qui ne demande pas vraiment de données, mais le poste réellement. Le assembly en ligne vient à l’esprit. Je retourne généralement un message d’état au format JSON.

Cela étant dit, j’estime évidemment que les deux options sont valables. Je suis persuadé que les puristes ne seront pas d’accord, mais il est parfois suffisant de renvoyer du texte pur HTML.

J’irais avec Json par défaut. Il s’agit d’un format d’échange de données léger (peu onéreux) et facile à mettre en œuvre. Vous avez juste besoin d’une bonne bibliothèque Object-to-Json pour rendre ‘b’ facile.

La question importante que vous devez vous poser ici est la suivante: quel est votre objective? Le faites vous

• veulent avoir plus de trafic sur le réseau et moins d’utilisation de l’unité centrale de traitement du client
• vouloir avoir plus d’utilisation du processeur client et moins de trafic sur le fil

et dans ce contexte, une autre question est de savoir combien de personnes appellent votre site. Si vous avez des centaines de milliers de visites de pages par jour, vous devriez envisager de réduire le trafic Internet par exemple.

Dans la plupart des cas, vous souhaitez non seulement générer un balisage HTML, mais également envoyer au client des données ordinaires que vous pouvez gérer dans votre ECMA-/Javascript . Par conséquent, JSON devrait être votre premier choix (si vous n’avez pas à traiter avec des blocs de données géants). JSON est un poids plume et peut être analysé extremly rapidement avec javascript .

Je me répète donc, que ce soit pour générer un balisage de rendu complet sur votre serveur et le livrer à un client, ou le laisser faire, dépend de ce que vous envisagez de faire.

Une page statique est ce que vous devinez correctement, statique. Mais cela ne signifie aucune utilisation du processeur pour un client / navigateur. Donc, si vous n’avez pas besoin / ne voulez pas avoir un comportement de page “dynamic”, une page statique vous suffit.

L’approche JSON est attrayante en raison de la séparation logique des données et de la présentation. Si à l’avenir, le style (la présentation) devait changer, ce qui se produirait inévitablement, les données JSON n’auraient pas besoin d’être modifiées, non?