• Créer une classe par page web
  
• Faire hériter chacune de ces classes d'une classe abstraite, 'Stream', qui se comporte comme un document XML
  
• Permettre aux classes filles de remplir ce doc XML de données
  
• Envoyer au client (le navigateur web) le fichier XML de 'Stream', ainsi qu'un lien vers un XSLT
  
• Laisser le navigateur transformer le XML en JSON, HTML ou autre via le XSLT
  

• Le XSLT peut être mis en cache et n'est plus transféré, comme le XML est plus léger que la page HTML, je réduis mon trafic
  
• Si le client fait la transformation, le serveur se tourne les pouces: la charge serveur diminue
  
• Si l'utilisateur est un robot ou un autre site web, celui-ci a plus de faciliter de traiter un XML (qu'il ne transformera pas) qu'un HTML

• Tous les clients web supportent-ils XSLT?
  
• Le résultat du XSLT sera-t-il bien traité par le navigateur (le HTML résultant du XSLT sera-t-il traité comme s'il venait du serveur, ce qui inclus le traitement des balises meta/CSS et script/AJAX)?
  
• Quid des crawlers web? Google va-t-il bien voir le HTML après transformation ou va-t-il coincer sur le XML?

• Complexe n'est pas compliqué:
  un site PHP→XML puis XML+XSLT→HTML puis HTML+CSS→rendu final n'est pas compliqué, chaque étape est un langage, assez simple souvent, indépendant du reste
  
• La maintenance est facilité:
  séparer les mécanismes de jeu (PHP), sémantique (XML), design (XSLT) et graphisme (CSS) est bénéfique pour la maintenance (or, c'est la maintenance qui fait la force d'un projet car c'est à partir de sa sortie que le projet "vit" au grand jour, s'il n'est pas maintenu, c'est un projet mort-né)
  
• Standardisation:
  Générer du HTML est souvent impossible à traiter ensuite par un autre site (si un autre site veut suivre le fil d'actualité de votre site, ou s'il veut connaître les statistiques de votre jeu, il aura beaucoup de mal à le faire si vous n'avez pas un XML pour cela et s'il vous faut faire un HTML pour les visiteurs + un XML pour les développeurs des autres sites, c'est bis repetita non placent)
  
• Alléger la charge de votre serveur:
  Donc, cela réduit vos couts ("blabla on peut bien payer 200€/an pour un serveur dédié plus puissant", oui mais encore faut-il que l'on soit capable d'assumer ces 200€/an, si les coûts augmente, il faut augmenter les revenus générés par le site, ou alors, on joue la philantropie qui est tout sauf viable ou pérenne)
  

• On limite l'utilisation de bande passante ;
  
• On transforme le site en une simple API, plus facile à tester et à maintenir ;
  
• On distribue le travail de rendue pour une meilleur utilisation des ressources des serveurs ;
  

Wikipedia a écrit :...Il s'avère donc impossible de remplacer inc(i) + inc(i) par 2 * inc(i) car la valeur de inc(i) (function inc(i){global i; i++}) diffère à chaque appel. À l'échelle d'un programme important, cela signifie que le remplacement d'une fonction par une autre peut nécessiter des modifications à d'autres endroits du programme, et qu'il peut s'avérer nécessaire de retester l'intégralité du système, car on n'est pas assuré qu'un tel remplacement n'a pas modifié son comportement global. Au fur et à mesure que la complexité du système augmente, le coût d'un changement s'accroît aussi. À l'inverse, la propriété de transparence référentielle permet d'assurer que le remplacement d'une fonction par une autre équivalente ne risque pas de modifier le comportement global du programme. Autrement dit, elles sont mathématiquement égales. Cette propriété facilite la maintenance logicielle. Elle permet aussi d'appliquer de façon automatique des preuves de fonctionnement. Elle a enfin pour autre avantage de sensiblement réduire l'importance de l'ordre d'exécution, celui-ci étant assuré par l'ordre d'appel des fonctions ; un corollaire est que la parallélisation d'un programme fonctionnel peut être réalisée de façon automatique et que les optimisations que peuvent effectuer les compilateurs sont plus faciles à mettre en œuvre.