Le problème quand on ne sait pas de quoi on parle, c'est qu'on a vite fait de dire des bêtises. Je vais essayer de répondre point par point, mais avant je voudrais faire quelques mises au point :
1. Comme déjà dit, agar.io est un jeu multijoueurs en temps réel dans le navigateur, et non pas une librairie javascript.
2. React est une librairie qui permet de définir des vues en javascript. Il n'y a pas de notion de modèle, de controlleur ou autre ; seulement des données reçues rendues sous forme de HTML.
3. Flux est un pattern architectural définissant les échanges d'informations au sein d'une application javascript s'exécutant dans le navigateur ; et non pas une librairie.
Ceci étant dit …
Comme déjà dit, avec Phoenix (et tout bon framework qui se respecte) tu peux à tout moment changer de système de push pour un autre de ton choix, même une solution maison. Comme avec symfony tu peux virer twig pour mettre blade, smarty, ou une solution personnelle. Si la norme HTML propose un système de push à base de balises HTML dans le futur (ça serait bizarre mais bon), c'est pareil, je ne vois pas ce qu'il m'empêcherait de m'en servir.
Mais bien sûr. Donc déjà quand on se lance dans un projet c'est toujours utile de connaître les technos. Pour ma part ça va, et pour les gens qui ne seraient pas à l'aise avec push : lancez-vous. C'est vraiment pas compliqué. Sauf si vous voulez implémenter Expert Comptable Simulator 2016. Ensuite, je ne comprends pas l'intérêt de perdre mon temps à afficher l'état courant du jeu sous forme statique. OK, je peux le faire, ça me prend 5 minutes. Si vraiment ça te fait plaisir je peux l'implémenter, le commiter, puis foutre ça à la corbeille. Mais à quoi bon ?
Désolé mais tes arguments ne sont pas cohérents. Tu peux développer un jeu de façon très modulaire, en n'implémentant que ce dont tu te sers déjà, en utilisant un framework comme Angular ou React. Tu peux très bien implémenter une première version de Déclaration D'Impôts Championship 2 avec un stock illimité pour tes notes de frais, et ajouter un stock limité dans une version suivante. Et pour faire ça, tu peux choisir d'afficher tout ça avec Twig, React, XSL ou ce que tu veux. Je ne vois pas le rapport.
J'ai pas compris. Tu as du code qui génère à la fois les données et du HTML ? Non, tu dis qu tu utilises des vues XSL et que ton serveur renvoie des données XML. Mon serveur envoie des données JSON et React génère du HTML avec ces données. À chaque fois qu'il reçoit des données, il régénère le HTML qui va bien. L'archi est assez fine, chaque composant de l'interface reçoit ses propres données et s'occupe de son bout de HTML.
Quand je dis qu'il faut le coupler à Flux c'est que justement React est une librairie qui ne s'occupe que des vues. Donc en terme de séparation des rôles on tient quelque chose de bien. Et je peux les remplacer par Ractive, Handlebars ou autre si j'en ai envie parce que justement ce ne sont que des vues et il existe pleins de choix pour faire ça. Flux propose de choisir des composants pour les vues, les input du joueur et les objets chargés de garder l'état du jeu en mémoire. C'est justement une architecture qui propose de découpler tout ça et que chaque composant s'occupe tranquilement de sa partie en définissant une API pour communiquer avec les autres composants.
Du coup je ne sais pas ce que tu entends par "cascadés" mais s'il y a bien un défaut qu'on peut reprocher à l'écosystème javascript c'est bien le trop plein de solutions et non pas le couplage trop important de celles-ci.
Voilà, désolé de mon ton pas super gentil, mais à la lecture de ton post cet aprèm où je ne pouvais pas répondre, puis à la lecture de ton article qui dit qu'en gros il ne faut pas penser le code à l'avance mais l'adapter (et au passage que les test unitaires sont inutiles tant qu'il n'y a pas de bugs …) je trouve que ça promeut trop les jeux-formulaires par dessus lesquels on va rajouter une couche de JS après coup parce qu'on a envie que ça soit dynamique. C'est ce qu'on faisait il y a dix ans et c'est pas terrible. Les jeux-formulaires aussi d'ailleurs, c'est pas terrible et c'est daté.
« Surtout n'utilise pas de framework. C'est sale. Code tout toi même. »
Le meilleur code qui soit, c'est "pas de code". Si tu dois écrire du code, c'est que tu dois résoudre un problème. Si du code existe déjà pour résoudre ce problème, et qu'il te semble de qualité, utilises-le, et code ce pourquoi il n'y à pas encore de solution (le moteur de ton jeu).
1. Comme déjà dit, agar.io est un jeu multijoueurs en temps réel dans le navigateur, et non pas une librairie javascript.
2. React est une librairie qui permet de définir des vues en javascript. Il n'y a pas de notion de modèle, de controlleur ou autre ; seulement des données reçues rendues sous forme de HTML.
3. Flux est un pattern architectural définissant les échanges d'informations au sein d'une application javascript s'exécutant dans le navigateur ; et non pas une librairie.
Ceci étant dit …
Citation :Oui, donc si tu t'es jeté sur un système tout-intégré-tout-en-un, tu fais comment pour maintenant implémenter ces pushs (qui sont du JS plutôt que de l'HTML)?
Comme déjà dit, avec Phoenix (et tout bon framework qui se respecte) tu peux à tout moment changer de système de push pour un autre de ton choix, même une solution maison. Comme avec symfony tu peux virer twig pour mettre blade, smarty, ou une solution personnelle. Si la norme HTML propose un système de push à base de balises HTML dans le futur (ça serait bizarre mais bon), c'est pareil, je ne vois pas ce qu'il m'empêcherait de m'en servir.
Citation :Si tu veux faire un Agar-like, je pense qu'il vaut mieux dev ton jeu statique d'abord, pour ensuite ajouter une couche de dynamique par dessus, plutôt que d'essayer de se lancer dans du dynamique du premier coup, surtout si tu ne connais pas les technos.
Mais bien sûr. Donc déjà quand on se lance dans un projet c'est toujours utile de connaître les technos. Pour ma part ça va, et pour les gens qui ne seraient pas à l'aise avec push : lancez-vous. C'est vraiment pas compliqué. Sauf si vous voulez implémenter Expert Comptable Simulator 2016. Ensuite, je ne comprends pas l'intérêt de perdre mon temps à afficher l'état courant du jeu sous forme statique. OK, je peux le faire, ça me prend 5 minutes. Si vraiment ça te fait plaisir je peux l'implémenter, le commiter, puis foutre ça à la corbeille. Mais à quoi bon ?
Citation :Dis autrement, mieux vaut dev des petites features une à une (qui collent accessoirement aux standards) plutôt que de vouloir faire un jeu "d'un bloc", même si tu "sais déjà" la liste des prochaines petites features: faut pas dev les petites features de maintenant en prévision des petites features à venir.
Désolé mais tes arguments ne sont pas cohérents. Tu peux développer un jeu de façon très modulaire, en n'implémentant que ce dont tu te sers déjà, en utilisant un framework comme Angular ou React. Tu peux très bien implémenter une première version de Déclaration D'Impôts Championship 2 avec un stock illimité pour tes notes de frais, et ajouter un stock limité dans une version suivante. Et pour faire ça, tu peux choisir d'afficher tout ça avec Twig, React, XSL ou ce que tu veux. Je ne vois pas le rapport.
Citation :Du coup, on verra vite le problème "le code HTML est généré par une seule classe", et on devra affiner l'archi pour séparer le pattern HTML et les data (initialement statiques, maintenant dynamiques).
J'ai pas compris. Tu as du code qui génère à la fois les données et du HTML ? Non, tu dis qu tu utilises des vues XSL et que ton serveur renvoie des données XML. Mon serveur envoie des données JSON et React génère du HTML avec ces données. À chaque fois qu'il reçoit des données, il régénère le HTML qui va bien. L'archi est assez fine, chaque composant de l'interface reçoit ses propres données et s'occupe de son bout de HTML.
Citation :Et quand tu dis:
Citation : Mais il faut le coupler à Flux ou autre système pour avoir un truc complet bien sûr.
J'en comprends "mes technos sont cascadés et je ne pourrais pas en intégrer de nouvelles plus tard". Ce qui m'a fait déboucher sur "séparer les rôles est peut-être difficile au début, mais on y gagne énormément sur la maintenance".
Quand je dis qu'il faut le coupler à Flux c'est que justement React est une librairie qui ne s'occupe que des vues. Donc en terme de séparation des rôles on tient quelque chose de bien. Et je peux les remplacer par Ractive, Handlebars ou autre si j'en ai envie parce que justement ce ne sont que des vues et il existe pleins de choix pour faire ça. Flux propose de choisir des composants pour les vues, les input du joueur et les objets chargés de garder l'état du jeu en mémoire. C'est justement une architecture qui propose de découpler tout ça et que chaque composant s'occupe tranquilement de sa partie en définissant une API pour communiquer avec les autres composants.
Du coup je ne sais pas ce que tu entends par "cascadés" mais s'il y a bien un défaut qu'on peut reprocher à l'écosystème javascript c'est bien le trop plein de solutions et non pas le couplage trop important de celles-ci.
Voilà, désolé de mon ton pas super gentil, mais à la lecture de ton post cet aprèm où je ne pouvais pas répondre, puis à la lecture de ton article qui dit qu'en gros il ne faut pas penser le code à l'avance mais l'adapter (et au passage que les test unitaires sont inutiles tant qu'il n'y a pas de bugs …) je trouve que ça promeut trop les jeux-formulaires par dessus lesquels on va rajouter une couche de JS après coup parce qu'on a envie que ça soit dynamique. C'est ce qu'on faisait il y a dix ans et c'est pas terrible. Les jeux-formulaires aussi d'ailleurs, c'est pas terrible et c'est daté.
Citation :Et également sur le fait qu'un framework (peu importe si c'est une masse de code dans laquelle on englobe son code métier ou des modules autonomes) n'a aucun intérêt tant que n'as pas un problème à résoudre dans ton projet.
« Surtout n'utilise pas de framework. C'est sale. Code tout toi même. »
Le meilleur code qui soit, c'est "pas de code". Si tu dois écrire du code, c'est que tu dois résoudre un problème. Si du code existe déjà pour résoudre ce problème, et qu'il te semble de qualité, utilises-le, et code ce pourquoi il n'y à pas encore de solution (le moteur de ton jeu).