Sites "mono-page"

[Sephi-Chan]

D'accord, Sephi, je croyais que tu parlais de Framework qui vont justement altérer comment régissent les liens. Donc, ok, je redis: pas de soucis pour ajouter des balises DOM à la volée. Maintenant, ma question est: quelles conditions/causes (chez vous) entraînent l'apparition de ces nouvelles balises?

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

Dans un jeu "classique" (hors navigateur), oui, je m'attends à devoir réapprendre les contrôles de chaque jeu, pas de soucis.
En revanche, dans un navigateur, nope, je ne m'attends pas à devoir ré-apprendre la navigation au sein de chaque site. Je suis peut-être extra-terrestre sur le coup, mais bon... En tant qu'utilisateur, cela me gonfle de voir un site réagir à sa sauce aux évènements de navigation (clique/ou autre sur les liens par ex).

Je dirais plutôt que tu es très fermé sur ce qu'on peut faire ou non d'un navigateur. J'ai l'impression que tu ne conçois pas que le site Web n'est qu'un conteneur pour le jeu : le jeu existe dans cette page et vient avec ses propres contrôles, qui sont largement communs avec ceux de la page Web, avec éventuellement quelques différences.

Tu t'acharnes sur ce point de la navigation alors que c'est qu'un tout petit bout de la question : la plupart des jeux n'ont pas besoin de lien ou de navigation, donc au mieux on n'y touche même pas, au pire on se fout de la casser.

Il faut être pragmatique : la doctrine "c'est un navigateur donc tout ce qui s'y passe doit avoir trait à la navigation" n'a pas de raison d'être. 

Je ne vois pas en quoi il serait plus dur d'apprendre à coder grâce à un des framework que tu cites que d'apprendre à utiliser les softs des SDK.

Quand tu développes pour le Web, tu apprends à utiliser Javascript et tu peux t'en resservir partout. Ce n'est pas le cas de chaque technologie de SDK.
Si tu apprends l'API de React, tu pourras t'en reservir sur plein de sites, qu'ils soient des jeux ou non.
Tu pourras même t'en servir pour développer des applications pour mobiles (via React Natives) ! Ce sont des compétences portables.

Je n'arrive pas à comprendre en quoi "faire 0 changement de page web", c'est bien? En quoi "coder des trucs dans mon jeu pour faire le boulot de la couche réseau", c'est bien (que ce soit un FW ou pas)? Si on ne veut transporter que les données, pourquoi pas faire du XML/XSL (qui ne touche pas à la façon de naviguer)? Un lecteur d'écran n'est pas perdu quand du JS altère le DOM? Il n'y a jamais eu de "collision" d'id (deux éléments d'un même ID dans la page)? Comment cela se passe si je clique un lien "hooké" par le JS, et que je perds le réseau? Ou qu'il est lent? Je peux faire "echap" et retrouver l'état de la page avant le clique? Ou cliquer ailleurs?

"Je les pulvérise": je demande à en voir la métrique. Entre compression, headers, cache client, CDN, et rendus progressifs, je ne serai pas aussi catégorique.

Et inversement, en quoi faire recharger la page est bien ? Tu trouves ça joli et immersif une page qui clignote en se rechargeant ?
C'est sympa un canal de discussion qui recharge la page à chaque message que tu envoies ? C'est sympa de recharger la page pour voir les nouveaux messages ?
Tu ne fais pas le boulot de la couche réseau, tu envoies des requêtes (très légères) et tu reçois des réponses (très légères), puis tu réagis en fonction.

(PS: je redis, c'est hyper-basé sur l'opinion, j'en suis conscient, mais en tant qu'utilisateur, je n'aime vraiment pas les sites qui veulent me ré-apprendre à naviguer chez eux)

Je serais curieux de connaître des cas pratiques où ça t'a gêné. Pour le moment, ça ressemble plus à une religion.
Je trouve ça inquiétant et vraiment malsain de renoncer à toute créativité pour un dogme.

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 ? ^^

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.

Sur un site "à rechargement", on tomberait sur la page d'erreur du navigateur et il faudrait faire précédent.