Sites "mono-page"

[Sephi-Chan]

@Sephi

D'autant que ne pas casser le navigateur est au cœur des frameworks cités.

Comment un framework coté serveur (le même code pour tous) pourrait-il espérer ne pas casser le comportement du navigateur qui dépend à la fois du type de navigateur (opera, firefox et IE n'ont probablement pas les mêmes façons de naviguer), du support de navigation (mobile, PC, tablette, lecteur vocal, liseuse) et des préférences utilisateurs (là, faudra m'expliquer comment elles peuvent être préservées).

Pour rappel: je parle bien des JS qui "hookent" les liens pour faire les choses à leur sauce, pas des JS qui ajoutent des balises dans le DOM (l'exemple de niahoo ne me choque pas: le JS peut ajouter des balises dans le DOM, le soucis n'est pas là: il est plutôt sur "qu'est ce qui a déclenché l'ajout de ces balises,").

Les frameworks que j'ai cité (React, Marionnette et Angular) sont tous client-side. Ils permettent — entre autre — de gérer l'aspect navigation proprement et sans aller à l'encontre des préférences utilisateurs, car ils reposent sur les API du navigateur (pushState). L'URL change quand tu navigues, le site réagit aux événements précédent/suivant, et selon tes préférences si tu ouvres dans un autre onglet, etc. Le développeur n'a rien à hardcoder : il laisse faire le navigateur.

En plus, tu focalises la question sur le seul problème de la navigation, alors que la plupart des jeux n'ont même pas besoin de gérer cet aspect navigation. Le plus souvent, les sites proposent une page de jeu sur laquelle tout se passe.

Pour toi qui joue à Dévotion, tu ne joues que sur une page qui contient plein de choses et qui change dynamiquement selon l'état du jeu. En quoi est-ce une mauvaise utilisation du support navigateur (j'exclue tout ce qu'Argorate voudrait t'empêcher de faire dans TON navigateur : on ne peut pas blâmer l'outil pour quelques développeurs pénibles) ?

Si on se contraint à utiliser un navigateur, il me semble que c'est pour sa fonctionnalité de navigation. Sinon, autant utiliser des SDK étudiés pour développer des jeux hors-navigateur: pour y avoir déjà mis les mains, je peux vous assurer que c'est génialement adapté pour faire un jeu.
Si on ne laisse pas la navigation au navigateur, même si le jeu "tournera partout", il ne sera adapté qu'à 1 seul support. D'où les "je ferai le portage mobile plus tard" qu'on peut lire sur le forum. Si on laisse faire le navigateur, il n'y a pas de portage à faire (seulement un éventuel skin CSS).
Si on fait un Crysis dans le navigateur, okay le téléphone l'affichera, mais je doute que le jeu y soit véritablement "fonctionnel". Si on le dev sur un SDK hors navigateur, on gagne un temps fou et on peut l'adapter aux supports. L'aspect "ça marche partout" du web n'est pas due au fait d'être un site, mais au fait que le navigateur adapte automatiquement le HTML et la navigation au support.


Pour reprendre les termes de Sephi, "disponible partout, sans installation, avec des technologies simples…": les SDK hors navigateurs font pareil (même mieux).
Les jeux peuvent être plug & play (sans installation), Unity peut exporter un jeu vers un tas de supports (Neoaxis est plus limité), et ces SDK sont ultra-simples d'utilisation: on crée le jeu lui-même, sans apprendre/maintenir/gérer des trucs annexes. C'est sur que c'est "beau" de faire un L4D² dans un navigateur, mais niveau industriel, je ne vois pas l'intérêt?!

J'ai quelques questions pour toi :

• Est-ce que les outils deviennent caduques dès lors qu'un autre est adapté à la tâche ?
  
• N'a-t-on pas le droit de détourner l'usage initial d'un outil ?
  
• Pour bien des jeux, le support navigateur convient très bien : pourquoi changer ?
  
• Pourquoi apprendre à utiliser Unity (et la stack technologique qui va avec) quand on peut faire un jeu dans le navigateur avec des technologiques qu'on maîtrise déjà ?
  
• Pourquoi s'embêter à publier des applications sur divers supports (avec les délais de mise à jour) alors qu'un site permet à chacun de venir sur une version toujours à jour ?