Si tu prends le zip https://github.com/pure/pure/archive/master.zip
Et que tu l'unzip, il y a un répertoire /tutorial
Il y a aussi une page /index.html que tu peux ouvrir avec quelques exemples.
Ça peut paraître bizarre, mais ça laisse alors au browser le travail de charger les pages(avec cache), interpréter le JS et CSS.
Ensuite les noeud DOM du template, un objet javascript et les style CSS sont collectés, et insérés dans la page principale.
Il me semble que de cette manière on profite du parallèlisme qu'offre le browser a charger/interpréter plusieurs resources en même temps.
Alors que par ajax on est limité par javascript à un seul thread.
Il y a un post sur le forum avec un exemple similaire à ce que nous utilisons encore aujourd'hui:
https://groups.google.com/forum/#!msg/P … -5fclrVcoJ
Je relance avec une question :
Il a été évoquée la récupération du HTML statique (et la cache). Comment est-ce que je récupère ce fichier HTML ?
Ma solution : mon serveur retourne un JSON avec data, directives, html statique et id de l'élément à modifier ?
Qu'en pensez-vous ?
PS1 : requète AJAX avec jQuery, PURE pour le rendu.
PS2 : plus précisément, je place le HTML statique dans un élément de la page, puis j'applique PURE sur cet élément avec data et directives.
Dans le cas d'un SELECT/OPTION c'est difficile de faire autrement, si tu veux vraiment un tiret entre val et name.
Par contre dans d'autre cas, tu pourrais effectivement être plus clean, et avoir le tiret dans le template, p.ex:
<span class="val"></span> - <span class="name"></span>
Pour un attribut tu peux utiliser la notation + pour faire une concaténation avec l'existant.
Le template:
<div id="element_id_"></div>
Et la directive:
'div@id+': 'element.id'
Qui donnerait, p.ex:
<div id="element_id_2345"></div>
Un up pour que vous ne vous ennuyiez pas pendant les vacances : d'un point de vue formel, n'est-il pas génant d'avoir des directives du style "#{size.val} - #{size.name}" où d'une part le tiret devrait appartenir au template HTML et où d'autre part on est contraint d'utiliser des "variables" du style "#{xxx}" ?
Là où je veux en venir c'est que le tiret ne devrait pas faire parti des directives mais du template (et donc du code HTML) ? Le template HTML que l'on a est incomplet. De la même façon, j'ai l'impression que si l'on voulait par exemple ajouter un attribut du style name="element_id_XXXX" (où XXXX est un identifiant quelconque, une donnée), il faudrait dans les directives indiquer "element_id_XXXX" qui devrait, de mon point de vue, appartenir au fichier HTML.
Finalement, un template HTML qui fonctionnerait avec du Javascript et DOM serait contraint de ne pouvoir écrire que des attributs entièrement ou des données entre deux balises (setAttribute ou innerHTML).
Directives extraites de l'exemple 10 de PURE :
Sinon promis, dès que j'ai un peu de temps je viens jeter un œil sur les performances de pure.js
Cordialement,
Jc
]]>Dans les deux cas, on peut ensuite appeler le même domaine par un appel AJAX.
Ou appeler un autre domaine par JSONP, et ce aux risques de l'utilisateur.
Le templating javascript n'intervient qu'après, quand le JSON est là.
Peu importe la manière utilisée.
Un autre aspect des choses qui me fait charger la page initiale en PHP, c'est que les techniques utilisées avec pure.js ainsi que la plupart des templates javascript, autorisent (théoriquement ou réellement) nativement l'accès à plusieurs SLD par injection de js dans la page (JSONP,..).
Le risque quand la page initiale et souvent de connection n'est pas générée par le serveur PHP, ce sont les problèmes de sécurité que cela peut poser avec la mise en place de fausses vraies pages sur le client etc... avec un cache désactivé pour le rechargement forcé de la page concernée.
Pour un intranet/extranet pure.js ne me pose pas vraiment de problèmes sur un plan architecture ni sécuritaire, mais sur un accès public authentifié dans un contexte où la page de connexion n'est pas générée par le serveur, je ne suis pas partisan de le préconiser, cela n'engage que moi on est bien d'accord.
Cordialement,
Jc
]]>L'avantage du rendu client est en général:
HTML vide + JSON < HTML Rempli par le server
En Kb qui voyagent et en process serveur.
Le navigateur qui d'habitude n'a pas grand chose à faire qu'attendre la réponse, fait le rendu.
Libérant ton server de ce travail.
Ajoutes à cela la gestion normale de la cache des fichiers statiques: HTML/JS et CSS, comme tu le dis, mais pas avancée.
Ce que tu ne peux pas faire sur des HTML dynamiques venant du sever.
Et tu as une architecture très performante, aussi bien au niveau réseau, usage du server que vitesse de rendu.
Pour info, je suis l'auteur de pure.js, que nous avons écrit pour notre appli SaaS.
Tu peux l'essayer pour te faire une idée de la vitesse. Tout le rendu se fait au client.
Le gros point qui reste en faveur du rendu server, c'est le SEO.
Même si Google permet les hash tags, c'est plus fastidieux.
moijhd, n'hésite pas à me contacter si tu as des questions sur pure.js!
]]>PURE est bien en effet, mais avis personnel pas pour tout. Pour te donner une idée, moi je construis toujours mes environnements en PHP et une fois dans l'environnement, je mets à jour le contenu en Js. Pourquoi? car jusqu'à maintenant dans mes réalisations une des contraintes constantes de mes clients a été que l'application réside côté serveur. La raison en est simple à mon avis. Travailler avec une application qui par exemple serait basée 100% sur PURE implique une "installation" sur le client des fichiers html applicatif, et si c'est pour faire ainsi les entreprises préfèrent encore travailler en mode compilé. Héritage du passé? bref peut être y viendra-t-on bientôt, en attendant cela nécessite une surcharge initiale car il faudrait vérifier dans un tel contexte que les fichiers html utilisés soient bien à jour au niveau version et que la mise à jour se fasse automatiquement lors de la connexion au serveur (login/mdp) du coup, la charge serveur est potentiellement plus importante et peu impacter l'expérience utilisateur selon si l'accès est de type intranet ou extranet/public.
++
EDIT
Note concernant la mise à jour, il faut relativiser car on peut intégrer cette gestion via un contrôle de cache avancé et l'utilisation d'un "manifest". On se rapproche donc étroitement des techniques utilisés sur des applis offline.