Rendu coté client ou coté serveur ?

Salut à tous :)

Depuis un bon moment maintenant et avec l'avancé conséquente des navigateurs récent, j'utilise de plus en plus le rendu de mes scripts coté client

Une liste chargé dynamiquement sera créée dans une boucle coté client et non plus coté serveur, exemple :

Serveur :

Code:

---

1 2 3 4 5

<?php for($i = 0, $l = count($elements); $i < $l ; $i++){ echo '<li>'.$elements[$i].'<li>'; } ?>

---

et coté front plusieurs méthode existe , mais je m'oriente sur des moteurs de templating ( undescore, mustache etc ... )

J'en viens donc a ma question, au niveau "bonnes pratiques" et performance quel est selon vous le plus important ?

- Enlever une charge au serveur
- Réduire le poid des échanges
- Séparer totalement les couches ( mvc ) ( ici l'exemple n'était pas propre mais bon ;) )

Pour le moteur de template, le plus efficace est d'utiliser microtemplating de jhon resig.
Et sinon je ne vois pas en quoi la génération du HTML coté front viendrait alléger le serveur, car dans tous les cas tu serais obligé de fournir la data dans un format ou un autre, et donc il y aurait déjà une génération faite de ce coté là.

Citation:

---

Et sinon je ne vois pas en quoi la génération du HTML coté front viendrait alléger le serveur, car dans tous les cas tu serais obligé de fournir la data dans un format ou un autre, et donc il y aurait déjà une génération faite de ce coté là.

---

j'aurais du completer :

retour serveur en mode templating :

Code:

---

1 2 3

{ membres : [{name:"jhon",lastName:"do"},{name:"jhon",lastName:"do"},{name:"jhon",lastName:"do"}] }

---

en mode rendu coté serveur :

Code:

---

1 2 3 4

<li><span class="masuperbeclasse">jhon</span></li> <li><span class="masuperbeclasse">jhon</span></li> <li><span class="masuperbeclasse">jhon</span></li>

---

ceci est un exemple de base mais on se rend vite compte que le poid du retour peut vite prendre de l'ampleur avec des mises en forme conséquentes.

de plus

Citation:

---

le plus efficace est d'utiliser microtemplating de jhon resig.

---

sur quoi t'appuies tu pour dire cela ??

Perso, j'aurai plus tendance à le faire coté PHP même si ça implique d'envoyer une page plus grosse car la génération/modification du dom peut s'avérer fastidieuse pour le navigateur, alors que charger un gros bloc de code html est rapide (et rapide à générer pour le serveur).


Par contre, je ne sais pas si c'est en rapport direct avec le sujet, mais parfois quand j'ai peu de PHP et que mon code html est en dur (non généré par du php) je préfère le mettre à jour plus tard à l'aide de javascript plutôt que d'y incruster du code php par-ci par là :

exemple :

au lieu de faire :

Code:

---

1 2 3

<div><?php echo $user['name']; ?></div> ... <div><?php echo $user['email']; ?></div>

---

je préfère parfois :

Code:

---

1 2 3

<div class="data_user_name"></div> ... <div class="data_user_email"></div>

---

et dans mon fichier javascript je regroupe toutes les données php à un seul endroit :

Code:

---

1 2 3

var user = <?php echo json_encode($user); ?>; $('.data_user_name').text(user.name); $('.data_user_email').text(user.email);

---

Même si ça va à l'encontre de mon premier argument de modifier le DOM aussi peu que possible coté client (bien qu'ici ce n'est que des node text).

Citation:

---

Envoyé par le_chomeur

j'aurais du completer :
sur quoi t'appuies tu pour dire cela ??

---

Mon statut d'expert JS ?
Plus sérieusement, as tu analysé micro templating ?
http://ejohn.org/blog/javascript-micro-templating/
C'est tout simple, écrit en super light, et les templates ne sont pas trop durs à comprendre. Dans un besoin d'efficacité, je pense qu'il a sa place.

sinon le système de template de underscore JS est pas mal non plus, il est basé sur la philosophie du précédent mais offre plus de possibilités.

Il ne faut pas oublier que le serveur est là pour générer du contenu et le JS est là pour améliorer l'expérience utilisateur.

Et il ne faut pas oublier non plus que le HTML ça se compresse, donc quand tu as activé le mod gzip sur ton serveur, ta page ne pèse presque plus rien

Code:

---

1 2 3

Plus sérieusement, as tu analysé micro templating ? http://ejohn.org/blog/javascript-micro-templating/

---

ou d'ou mon choix de m'orienter plutôt sur underscore , puis au final , vers mustache qui est vraiment plus agréable a utiliser ( plus de condition dans le code par exemple :) )

une fois le poid du contenu mis de coté comme argument , il reste encore le traitement fonctionnel du rendu , qui selon moi une fois déporté coté client peut vraiment soulager le serveur ...

de plus séparer l'html de la récupération des datas , apporte pas mal de lisibilité au code php/html/js.

je ne me fais pas pro du templating js hein, je cherche de vrais arguments pour réfuter ( ou pas ) ce que j'en pense :)

Dans le cadre d'applications web, j'ai testé et expérimenté quelques solutions.
A l'époque on ne savait pas si on restait sur un serveur 4D (nos applications étaient développées dessus) ou si on recommençait tout sur un autre serveur (genre Apache/PHP).

Comme il fallait quand même avancer un minimum, on est parti sur un dialogue XML en Ajax. La vue lorsqu'elle se chargeait faisait plusieurs requêtes Ajax et le serveur répondait de l'XML qui était analysé par jQuery et transformé en HTML par des méthodes développées pour. Comme ça potentiellement, si on devait changer de serveur, toute la partie interface serait restée (plus ou moins) fonctionnelle du moment que le serveur répondait les mêmes XML. C'était pas mal mais on est pas allé jusqu'en production.

Ensuite j'ai découvert la transformation XSLT (mieux vaut tard que jamais ^^) et je l'ai essayé aussi bien coté serveur que coté client. Finalement j'en fais coté serveur : on a un moteur qui génère des données en XML et qui est appelé à la fois par une application web pour qui ces données sont transformées en HTML et par des web services qui prennent l'XML tel quel.

Je ne sais pas si je fais beaucoup avancer le schmilblick, mais des fois que ça intéresse quelqu'un ... :)

Citation:

---

Envoyé par le_chomeur

Salut à tous :)
...
J'en viens donc a ma question, au niveau "bonnes pratiques" et performance quel est selon vous le plus important ?

- Enlever une charge au serveur
- Réduire le poid des échanges
- Séparer totalement les couches ( mvc ) ( ici l'exemple n'était pas propre mais bon ;) )

---

pour moi trois
pour le premier c'est pertinent si tu travaille full ajax tu n'envois la déco de la page qu'une fois et les données à chaque besoin. du coup pour les envois de données la charge est faible

pour le second c'est pertinent toujours si tu est en full ajax mais en plus si tu choisit un format d'échange léger JSON par exemple

pour le troisième c'est là aussi pertinent mais à condition de bien séparer le chose ce n'est pas parce que tu choix ce mode que les chose se séparent seules. donc veiller à ne produire que du HTML et du javascript statique et ne produire dynamiquement que des data. tu peux alors avoir des couches bien séparées. il faut voir l'appli comme un client/server le client est lancé par une page html statique et son code JS implémente MVC donc dans le js on ne mélange pas le code pour généré l'interface, celui qui traite les évènements et celui qui accède au données ou services. côté serveur c'est pareil le serveur est là pour fournir des services au client et des données. l'interface de service c'est à dire la façon dont le client accès au serveur est une partie qui ne traite que l'échange. une archi MVC est là aussi tout a fait de circonstances. la seule chose c'est que la "vue" je dirait plutôt pour rester fidèle au design pattern la "présentation" formate les données pour les fournir au client (elle les présente au client) bref un echo json_encode($reponse)

enfin j'ajouterait un autre point
la décorrélation entre le client est le serveur.

si tu définis bien le dialogue alors il est possible de développer les deux partie plus ou moins indépendamment. souvent je fais la partie js et pour les accès au services/données je mets des urls vers des fichier statiques createUser.json il contiennent en statique une "réponse" à l'invocation du service. d'un autre côté la partie serveur est développé indépendamment avec des bouchons qui appellent les services. ensuite je vérifie que les deux on respecté le contrat de service et j’assemble les deux. il suffit pour cela de mettre les url dynamique dans le client.

j'ai par deux fois développé une première version d'appli en faisant un serveur en php et au final c'est java qui a été retenu pour la généralisation. en respectant le contrat de service il n'y a rien eut à changer dans la partie client.

sur une autre application js/php ou j'ai procédé de la sorte un accès externe à l’entreprise sur une parties des services de l'appi a été demandé après coup. le frontal d'accès externe écrit en java c'est vu adjoindre un module qui d'un côté exposait des web service Soap et de l'autre accédait au serveur php en utilisant la même interface que le js. rien n'a été changé ni dans le serveur php ni dans le client js.

je conçois donc mes applications sous la forme client/serveur ou le client est une page html statique avec des js statiques qui accède à un serveur qui fourni des services applicatifs. pour moi le serveur n'est pas là pour donner accès au donnée mais pour assurer le traitement métier.

A+JYT

On se rejoint Sekaijin sur le fait que tout ceci a un intérêt important sur une application TRES orienté ajax ( one page application par exemple ).

Ce qui me conforte dans l'idée que d'utiliser le server php pour la partie métier et renvoyer les data json , en utilisant des tpl créer en html/js ( exemple mustache) et effectuer le rendu coté client est un gain en terme de maintenabilité, lisibilité et performance !