Sites "mono-page"

[Argorate]

Comment vous faites en mono-page si y'a une coupure de connexion sur une requête ajax par exemple ? Pour éviter que tout le js qui tourne bien parte en carafe ? ^^

Bah tu affiches que la connexion a été perdue, et tu poll ton serveur pour voir quand elle est revenue et reprendre où tu en étais.

Pour le coup c'est plus sympa qu'un changement de page qui va juste tourner à vide 30 secondes (ou 0 selon le type de déconnexion) puis afficher une page d'erreur indiquant que le site est disponible.

+1

Les callbacks des appels ne sont simplement pas exécutés. A chacun de choisir une façon de le gérer. Par exemple, si on fait un jeu où on se déplace de case en case, on a souvent tendance à commencer le mouvement dès l'envoi de la requête, pour que ça paraisse plus rapide, il faut donc ici faire revenir le personnage à sa place initiale si on a pas de réponse du serveur dans les X secondes.

C'est exactement ce que je fais
Je fais de la prédiction en lançant l'anim du mouvement, et en cas d'erreur, j'ai un callback pour replacer le joueur à sa position. Après si tu perds vraiment la connexion... C'est comme me demander ce qu'il faut faire pour lire dans le noir... bin tu lis pas. Si tu veux jouer sur internet sans internet, bin tu joues pas?!^^


Xenos: recharger la page ça veux dire recréer tout le DOM, recharger tous les CSS (qui n'ont pas changé), recharger tous les scripts (qui n'ont eux non plus pas changé) + éventuellement réinitialisé de nombreux bind sur le dom concernant des events etc. Alors qu'en ne le faisant qu'une fois, c'est bien plus performant... tu gagnes un max de temps sur de l'aspect "technique" dont l'utilisateur n'a que foutre (et n'a même pas conscience d'ailleurs).

Si le réseau est lent et bien là aussi ça aurra des conséquences. Dans les jeux ont parle de lag... Ca veux dire qu'il y aura des lenteurs pour certains actions qui demande des choses au serveurs, c'est vrai. Mais c'est vrai pour n'importe quel jeux en ligne, y comprit pas par navigateur...

Enfin, pour en avoir fait, le XSL/XSLT me parait infiniment plus lourd (rien que dans la syntaxe) que l'envoi simple des données en JSON (qui de surcroit sont de facto transformé en objet JS directement utilisable).

Dans l'absolue, la seule chose qu'un client doit demander au serveur, c'est tout ce qu'il ne sait pas, donc la première fois c'est le JS qui permettra de créer le DOM selon sa navigation, et pour TOUTES les autres fois, il demandera uniquement les variables, les trucs qui changent et où seul le serveur fait autorité.
Soit tu les envois en texte brut avec un syntaxe que tu fais toi même, sois tu sérialises en JSON car c'est fait pour et directement traduisible en JS.
Du coup tu n'as pas besoin de faire travailler le serveur ET le réseau plus que ça...

Quel est l'utilité de faire faire au serveur, puis de le transférer par le réseau( qui passe peut être par la chine) une tel donnée :

Code :

<div id="character">
   <div class="carac">
        <div id="hp">100/100 <span class="icon-hp></span></div>
        <div id="mp">200/200 <span class="icon-mp></span></div>
   </div>
</div>

(et encore je suis light, si on a un vrai design, le nombre d'élement du DOM peut vite monter bien plus que mon exemple)

là ou un hash de donnée suffit : { hp: 100, hpmax: 100, mp: 200, mpmax:200 } ?

C'est juste débile dans l'absolue^^
Les seules données utilises sont celle que l'on a pas. La construction du dom peut etre factorisé par le JS de sorte de rendre bcp plus simple et rapide les échanges client-serveur. Mais bon, on dira que ça c'est ma religion à moi^^

Du coup, moi je ferais, pour reprendre l'exemple ci-dessus, un template JS: (plus le DOM qu'il comporte est gros, plus c'est justifié selon moi)

Code :

<div id="character">
   <div class="carac">
        <div id="hp"><%= @hp %>/<%= @hpmax %> <span class="icon-hp></span></div>
        <div id="mp"><%= @mp %>/<%= @mpmax %> <span class="icon-mp></span></div>
   </div>
</div>

et je l'appel en JS :

Code :

$.get 'ma/super/requete', (data)->
   app.JST 'path/to/template', data

et voilà (je fais du coffeescript)...

Ce qui me permet, en cas de baisse de PV, de demander un hash au serveur de type : { hp: 42 } après une action quelconque, et de pouvoir rafrech le template sans reload la page (on peut même optimiser en ne modifiant que l'endroit du DOM avec le nombre d'HP bien sur).


PS:
pour ce qui est de prouver la rapidité, amuse toi à naviguer :
https://fr.yahoo.com/ => click sur actualités par exemple
http://jepolitique.fr/ => click sur débats par exemple
Il n'y a même pas besoin d'utiliser firebug pour regarder le temps de chargement, la différence est tel que tu peux la ressentir de "visu"...

[Xenos]

Bah tu affiches que la connexion a été perdue, et tu poll ton serveur pour voir quand elle est revenue et reprendre où tu en étais.

Pour le coup c'est plus sympa qu'un changement de page qui va juste tourner à vide 30 secondes (ou 0 selon le type de déconnexion) puis afficher une page d'erreur indiquant que le site est disponible.

Perso, je trouve que c'est justement du ressort du navigateur de faire cela, l'avantage étant la possibilité de fournir une version en cache (ou d'avoir un plugin navigateur bloquant les liens quand on a perdu la connexion: cela revient à ce que ce site web fait, sauf que c'est auto-porté sur tous les sites car dans le navigateur et non dans chaque site).

Les nouvelles balises peuvent arriver par exemple quand j'ouvre un panneau de jeu.

Du coup, pour moi, là, on est dans de la navigation. Et je préfère avoir la possibilité d'ouvrir ce panneau de jeu dans un autre onglet (histoire de bénéficier du multi-écran par exemple).

tu ne conçois pas que le site Web n'est qu'un conteneur pour le jeu

C'est tout à fait cela.
Et d'accord, L'Omniscient l'a plutôt bien formulé: ok, vous aimez bien l'idée de perdre de vue le fait d'être dans un navigateur. Perso, j'aime bien le garder. Cela peut venir du fait qu'avec plusieurs écrans, le navigateur est à gauche et non au centre (les jeux usuels sont au centre en revanche).


@Argorate:
si tu veux vraiment réduire l'impact réseau, il me semble bien plus efficace de faire un jeu hors-navigateur qui enregistrera les choses en dur sur le disque plutôt que de risquer leur re-téléchargement régulier, genre en cas de F5. Si tu configures proprement les choses (headers de cache et d'expiration), ton serveur ne sera même pas recontacté pour récupérer les CSS. Le même procédé s'applique si tu passes par un XSL comme patron de page. Ainsi qu'aux JS (et autres ressources genre PNG) Leur re-téléchargement peut être forcé en changeant l'URL (type ?v=2.0).

Les lags d'un jeu pas-par-navigateur me semble quand même nettement plus faibles (connexion persistante & protocole adapté). Si quelqu'un a une métrique là-dessus, je suis preneur.

Je ne dis pas le contraire: XSL est "verbeux" (cela reste quand même pas si dément que cela). Mais cela se compresse. L'avantage est de séparer ce template XSL du reste du site.

donc la première fois c'est le JS qui permettra de créer le DOM selon sa navigation

Ben justement: pour moi, cela se trouve déjà dans le navigateur ça.

Soit tu les envois en texte brut avec un syntaxe que tu fais toi même, sois tu sérialises en JSON car c'est fait pour et directement traduisible en JS.

Soit tu les envoies en XML que le navigateur interprétera nativement avec le XSL gardé en cache (mais je m'éloigne)

Pour ta comparaison avec Yahoo, faut pas déconner ^^
Yahoo regorge d'images dans tous les sens: normal que le temps de chargement soit long. Une vraie comparaison comparerait le même si avec les deux structure.

---

Tiens, cool, je vais pouvoir lancer une autre question: si votre site est fait en JS qui récupère des données JSON, les traite et les fous dans le DOM, comment faites-vous pour permettre aux joueurs de "skinner" le jeu? Ok, ils peuvent changer la présentation CSS, mais comment feriez-vous pour le permettre de vraiment skinner le jeu, et de changer

Code :

<div id="character">
   <div class="carac">
        <div id="hp">100/100 <span class="icon-hp></span></div>
        <div id="mp">200/200 <span class="icon-mp></span></div>
   </div>
</div>

en

Code :

<meter min="0" max="100" value="100"/>
<meter min="0" max="200" value="200"/>

?
perso, j'aime bien l'idée de me laisser la possibilité de séparer le "skin" du jeu, et de permettre aux joueurs de faire le leur, de le partager et d'utiliser ceux des autres (un peu comme Ogame le faisait... POINT GODWIN DU JEU WEB !)

[Argorate]

tu es de mauvaise foi :p
prend http://jepolitique.fr/parties?order_by=name y a plus d'image, et compare à jeuweb lui même si tu veux (y a pas d'image, va sur l'index, rentre dans un forum, tu verras comme c'est lent en comparaison, ou même ton blog, ou n'importe quel site qui n'utilise pas turbolink...).

Et justement les images ne sont pas reload non plus quand tu recharge pas la page, c'est pour ça que c'est super rapide sur mon site même avec des images
Sinon pour l'histoire du header, je parlais pas de reDL, mais de reappliqué le css et le js au chargement de la page, cela prend du temps pour rien puisqu'il n'a pas changé.

si tu veux vraiment réduire l'impact réseau, il me semble bien plus efficace de faire un jeu hors-navigateur qui enregistrera les choses en dur sur le disque plutôt que de risquer leur re-téléchargement régulier, genre en cas de F5.

c'est exactement ce que je fais ! Le cache qui contient le JS est comme les données installé d'un .exe, il est sur le disque et y reste, ne change qu'en cas de changement de version, (comme pour un .exe).


Pour finir, on ne va pas rerentrer dans le débat, mais pour moi un joueur n'a pas le droit de modifier l'interface (ni quoi que ce soit d'ailleurs) du jeu...
S'il le fait, de nombreuses triches pourraient surgir et rendraient le jeu frustrant pour les joueurs honnête.

Exemple simple:

si tu modifies l'interface pour ajouter un bouton qui déclenche une magie qui était à l'origine dans 3 sous-menus, et bien tu auras un avantage sur qq'un qui n'a pas ce bouton.
Hors la définition même de fair play, c'est qu'un jeu soit à posteriori équitable, ça veux dire que le jeu doit présenter les même chances si ce n'est ce qui vient du joueur, qui fera la différence (et qu'on appel vulgairement le "skill").
Si tu mets un bouton comme je le disais, le jeu n'est plus fair play donc c'est de la triche, donc c'est mal, donc il faut l’empêcher et le réprimander par tous les moyens possible. (évidemment je parle d'un jeu par nav. pas d'un site lambda).

[L'Omniscient]

si votre site est fait en JS qui récupère des données JSON, les traite et les fous dans le DOM, comment faites-vous pour permettre aux joueurs de "skinner" le jeu?

Pour modifier tout le design ?
Alors, je sais pas si j'ai tout bien suivi de ce qu'a dit Argorate, mais pour ma part les tables SQL sont générées en tableaux PHP puis en tableaux JSON que je lis via le JS. Donc, dans mon cas, toutes les modifications de design seraient inscrites dans les données SQL du joueur et seraient simplement chargées... Si c'est des éléments unique, on met la variable PHP dans le JavaScript, si c'est un design entier... Je ne l'ai jamais fais, mais à première vue je dirais simplement que les infos seraient stockées dans un fichier JS contenant les différents design et les fonctions qui les appellent... (C'est ce que je fais pour des ajustement de design, mais pas pour des modifications d'images). Enfin, perso, pour modifier un design entier, j'opterais plutôt pour un menu option sur la page de connexion de mon jeu, ou quelque chose du genre, du coup le design serait généré simplement à l'actualisation de la page lors de la connexion au jeu. Je ne vois pas trop le soucis en fait, mis à part que tu veux mettre à mort la monopage dans un combat acharné :p

EDIT : AH ok, j'ai compris la question avec la réponse d'Argorate. Pour ça je passerais effectivement par une interface d'option séparée du jeu monopage.

[Ter Rowan]

ca me fait penser à une discussion que j'avais eu au bureau avec un défenseur du "paradigme de la page web" sauf que ce paradigme était des années 1980 et dans un objectif où le web était dédié à la lecture de contenu (avec un peu de formulaire)


maintenant on a html 5 qui permet de la vidéo (donc des sliders, incompatible avec le paradigme de la page web : bouton = action = rechargement de page, m'étonnerait bien que le slider video provoque le rechargement de la page)

on est un peu ici sur la même discussion (le point ci dessous m'a fait pensé au paradigme) :

@Argorate:

si tu veux vraiment réduire l'impact réseau, il me semble bien plus efficace de faire un jeu hors-navigateur qui enregistrera les choses en dur sur le disque plutôt que de risquer leur re-téléchargement régulier, genre en cas de F5. Si tu configures proprement les choses (headers de cache et d'expiration), ton serveur ne sera même pas recontacté pour récupérer les CSS. Le même procédé s'applique si tu passes par un XSL comme patron de page. Ainsi qu'aux JS (et autres ressources genre PNG) Leur re-téléchargement peut être forcé en changeant l'URL (type ?v=2.0).

ben justement avec le html 5 on a accès via des instructions js à un conteneur de données local
quel est l'abruti qui a mis en place cette option ?

bref ce qui était vrai il y a 30 20 10 5 ans n'est pas forcément vrai aujourd'hui et ce qui est vrai aujourd'hui sera peut être faux demain

[Xenos]

Et justement les images ne sont pas reload non plus quand tu recharge pas la page, c'est pour ça que c'est super rapide sur mon site même avec des images

Ca, c'est pas pertinent: j'obtiens pareil ou mieux avec un header cache & expires

reappliqué le css et le js au chargement de la page

Ca en revanche, c'est pertinent. Mais je me demande si la réapplication du CSS à une page entière est vraiment plus lente que l'altération du DOM (qui entraine peut-être la réapplication générale du CSS à tout le document).

il est sur le disque et y reste

Ca, je ne saurai être aussi catégorique, puisque c'est du ressort du navigateur (qui n'hésite pas à faire de la place si le cache est plein par exemple). Après, tu obtiens pareil là aussi que tu sois en monopage ou en multipage (genre XML/XSL). Je serai curieux d'avoir une métrique de la quantité de données réellement économisées en transférant uniquement du JSON face à du HTML & face à du XML.

Pour l'argument de la triche, même si tu fais le jeu en JS, t'auras le même problème.

Je n'en fais pas tant une chasse aux sorcières (même si cela peut en avoir l'apparence) qu'une tentative de comprendre pourquoi il semble si "attirant" de vouloir faire du monopage et de se servir du navigateur juste comme d'un moyen de diffusion du jeu.

"Conteneur de données local" = localStorage? Pour y mettre des fichiers en cache? Ou je n'ai pas compris le cas d'application? O.o

ce qui était vrai il y a 30 20 10 5 ans n'est pas forcément vrai aujourd'hui et ce qui est vrai aujourd'hui sera peut être faux demain

Ca, je suis d'accord aussi, et du coup, j'ai un peu l'impression de voir dans cette vague de JS/Framework le même engouement qu'il y avait à l'époque des sites full-flash (qui étaient monopage... lol, ok, troll).

---

PS @Argorate
En regardant le pannel Réseau de firebug, je vois qu'en fait tu DL la totalité de la page à afficher? Et tu écrases la page courante avec ce nouveau document? Ou peut-être juste une partie? Dans tous les cas, niveau réseau, tu n'y gagnes pas.

---

PSS:
Je pensais pouvoir me convaincre de l'intérêt de TurboLink, mais après avoir pris les mesures des temps de chargement (pour la page proposée et celles "à coté", c'est à dire "Nom/Adhérents/Date"), je ne suis vraiment pas convaincu: avec ou sans TurboLink, les temps de chargement de la page sont identiques.
D'ailleurs, cela m'a permis de noter que Firefox ne fait pas une "page blanche" entre deux pages chargées: il conserve la page précédente le temps que la suivante soit chargée, donc je n'ai pas d'effet de "clignotement avec une page blanche" lors de ce petit test.

[Argorate]

bien sur, jepolitique a des vus fait par le serveur en mode "classique", il n'est pas client-side comme le sera TMI
Ne confonds pas la lib Turbolink avec ce que je disais sur les templates JS, c'est deux composants différents (qui peuvent être associé)

Pour la triche, je n'ai pas dit que le JS règle le problème, je répondais a ta "nouvelle question".