"ha on a des framework qui code tout seul aussi ? non parce que je doute que tes framework change la valeur a l'écran si une valeur de la bdd es dans la page de l'utilisateur et que cette dernière es changer, je veux bien croire que y'a des framework pas mal mais abuse pas sur les fonctionnalités"

Eh bien si en fait, c'est même le principe de Meteor (tu es sûr d'avoir regardé ce que c'était?). Ce framework fonctionne sur ce principe. On envoie les templates compressés au client, celui-ci les génère et les affiche, et là où de la donnée doit être affichée, le serveur sait (via un mécanisme de publication/souscription) quelle portion de la base de données le client doit connaitre. Celle-ci est transmise et conservée localement dans une version locale en JS de MongoDB, à partir de laquelle la page est remplie. Si la donnée change, le serveur indique à tous les clients sensés connaitre à ce moment là la portion de base de donnée modifiée la modification, et chacun re-génère les portions de page qui sont impactées par le changement. Les souscriptions étant définies par l'équivalent d'une requête sur la db, elles peuvent être très précises (pour ne pas mettre à jour le monde entier dès qu'une modif survient). De cette manière, on code la vue pour qu'elle gère tous les cas possibles, les évènements en fonction de clics, et...c'est tout. Le changement d'aspect de la page, le contenu, tout ça, c'est rafraichi et géré par Meteor. Renseigne toi, je ne dis pas que ce framework est simple, mais une fois maitrisé il a des avantages impossibles à reproduire en PHP en terme de temps et facilité de développement (le résultat sera similaire en PHP mais plus difficile à atteindre je pense).

Si je suis passionné, j'pense que osef de ça, mais dans mes études j'ai déjà dev moins (et plus) lourd que ce genre de projet, et déjà ça demandait une conception en béton armé pour pas partir n'importe où. ^^'

Et pour finir, voici quelques benchmarks de JS (Node) coté serveur, versus PHP: http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/

Y'a pas photo, à moins de partir dans des optimisations expérimentales pas encore stables, Node met PHP en P.L.S. à tous les niveaux avec le V8, et PHP le rejoint au mieux avec ces fameuses recherches récentes sur l'opti. La performance décroit encore quand on ajoute un framework par-dessus PHP, mais c'est très probablement la même pour Node (pas montré ici). En perf brutes, PHP est battu par le V8 pour le moment.

Donc nope, Symfony n'est pas préféré pour sa puissance (c'est tellement un boeuf des fois...), mais pour son système de modules très, TRES fourni. Du module pour faire des forums à celui pour faire des blogs ou des envois de mail automatiques, y'a de tout, car il est présent depuis plus longtemps sur le marché. (et tellement osef des choix français, parfois très différents sans raison des choix globaux...c'est un critère ça?)

Sauf qu'il n'existe probablement pas de plugin tout fait pour faire un jeu vidéo web. Donc j'en reste à comparer la facilité d'avoir des templates s'affichant et se mettant à jour en temps réel sans vraiment travailler dessus, avec de très très bonnes perfs, face à une tech pas conçue pour par-dessus laquelle on va ajouter un serveur de websockets. Pour moi, y'a pas photo. On peut y arriver avec les deux, mais je pense que la seconde c'est se faire du mal.

Edit: les perfs de PHP se sont rattrapées depuis ses dernières versions, mais il ne met toujours pas au tapis Node (égalité?), et mon argumentation concernant les facilités apportées par les nouvelles techs JS (ici Meteor en particulier) reste la même. le problème reste le coté bloquant de PHP, qu'on ne retrouve pas chez Node.

-
Edité par Genroa 16 janvier 2017 à 18:49:20

ouais donc l'utilisateur es souscris a des channel comme les websocket donc a la finale sa revient au même

perso quan je vois sa http://docs.meteor.com/api/pubsub.html bha c'est rien de plus que des websocket qu'il utilise aussi si ce n'est pas sa il en ont copier le fonctionnement donc a la final faire un serveur websocket ou passer par sa sa reviens au même le seul avantage que j'y vois sur meteor c'est mongodb sinon rien n'est vraiment fou une fois que ta compris les websockets tu peux faire la même chose que eux et je n'ai jamais dit que node était nul même s'il ne met pas en pls php j'utilise nodejs juste pour mon serveur websocket et sa marche plutôt bien peut être qu'un jour je changerais d'avis mais pour l'instant php et les websocket sa fais ce que je veux avec un rafraîchissement au même moment pour tout le monde par exemple a la fin d'une attaque la vie des joueur et tout sont renvoyer et on regarde coter client si on prend les infos pour nous on si on les ignores puis quand je regarde meteor il faut utiliser un framework js comme blaze angular ou react perso j'ai l'habitude d'utiliser du javascript pur ou je me sert de jquery

je vois pas le coter bloquant de php justement les websocket on été créer pour faire des échange de donnée en temps réel d'ou son nom "web"socket a la place de faire du long-pooling en ajax qui était plus lourd sa fais aucun rechargement de page aucune requête dans la bdd inutile pour recharger des données par exemple a chaque interaction je passe par l'ajax donc j’exécute php qui depuis la version 7 es assez rapide pour l'instant j'ai implémenter que l'attaque et quand je regarde les requête ajax des vols c'est presque instantané pour l'utilisateur donc on peut dire que rien que ajax et php sa marche plutôt bien,

les websocket je m'en sert surtout pour alléger les requette en bdd si une valeur change je la récupère et l'envoi après c'est coter client que la personne regarde s'il prend l'info pour lui c'est exactement ce que fais meteor mais a la place de tout envoyer il se sert de channel ce qui es possible aussi avec les websockets a la final j'exploite le pc du client pour faire moin de chose coter serveur évidement je suis pas idiot je vais pas faire une fonction en websockets ou tout le monde recevra les résultat avec des donnée sensible les seul chose que j'envoi en websocket c'est ce que le joueur a besoin de voir s'il ce passe une action autour de lui je pense pas que la difference entre meteor et php7 ajax + websocket n'est pas visible a l'oeil nu 

-
Edité par stevenhervy1 16 janvier 2017 à 23:01:00

C'est beau de faire des parallèles en tombant sur un mot identique...tu es bien sûr d'avoir lu la doc?

Le mécanisme de publication/souscription est un pattern qui n'a rien de limité aux websockets, et ce n'est pas la première technologie qui l'implémente (https://fr.wikipedia.org/wiki/Publish-subscribe) . Il n'y a pas de copie. D'ailleurs, leurs utilisations n'ont rien à voir au sein du framework.

Le coté bloquant de PHP provient de son code, pas de la couche de Node que tu appliques par-dessus bien évidemment... C'est de ça dont je parlais.

Vu que tu n'as pas fouillé pour comprendre plus précisément (après tout la doc est assez fournie, t'étais pas obligé de te forcer ), j'vais faire un parallèle entre le déroulement avec PHP + websockets (+ Twig par exemple) et Meteor (+ Blaze) :

PHP:

• l'utilisateur arrive sur le site, il reçoit une page (détail plus loin).
• l'utilisateur clique sur un lien
• le navigateur demande la page au serveur
• le serveur fait ses opérations via le contrôleur
• le serveur fait ses requêtes en base de données
• entre autre à partir des résultats, il génère une page à partir des templates Twig
• le serveur retourne une page HTML+CSS avec du JS dedans pour se connecter au serveur de websocket
• une fois la page reçue, le client se connecte aux websockets et souscrit à des émissions de messages
• lorsque ces messages sont envoyés et réceptionnés par le client, du code écrit sur mesure met à jour la page (on part donc du principe que les modifications ne sont pas énormes, refabriquer un pan de page c'pas facile)

Si j'ai fait une erreur, n'hésite pas à me corriger.

Meteor:

• l'utilisateur arrive sur le site, il reçoit en compressé le code client JS ET les templates compressés. Le navigateur génère la page à partir des templates et l'affiche (détail plus loin).
• l'utilisateur clique sur un lien
• le navigateur via son routeur+contrôleurs intégré (récupéré à la première connexion) détermine sans demander au serveur la page demandée, génère le template et l'affiche
• en parallèle, le navigateur indique au serveur via un système de souscription de quelles plages de la base de données il va avoir besoin pour remplir la vue générée par le template (le mécanisme de pub/sub est là pour simplifier la syntaxe mais c'est littéralement un ensemble de requêtes en base dont on demande le résultat). Exemple pour afficher une liste de commentaires, on va souscrire à une requête renvoyant cette exacte liste.
• la donnée de base de donnée arrive (via un autre port) et est répliquée dans une base de données locale en JS dans le navigateur
• le template est rempli avec la donnée (re-généré puisque la donnée a changé)
• une fois la page arrivée, il n'y a plus d'échange avec le serveur, sauf si des portions souscrites de la base de donnée changent
• à un moment, une portion de base souscrite change (histoire de voir le même genre de changement qu'avec la solution PHP). Le serveur indique aux clients qui ont souscrit quelle portion a changé et leur envoie la modification (websockets, généralement très, très rapide).
• la donnée en base a donc changé : le navigateur détermine quelles portions du template doivent changer et les re-génère. La vue est modifiée. Il n'y a pas de code écrit par le développeur : c'est automatique.

Voilà voilà. Qu'est-ce que j'en retiens:

• le changement d'une page à l'autre donne une sensation d'instantanéité car les templates sont reçus en amont et générés coté client (rapide, pas de transmission par le réseau)
• si on modifie quelque chose coté client, la sensation d'instantanéité est la même, car c'est d'abord la base de données locale qui change, puis on informe le serveur, puis il confirme ou interdit le changement (rollback). On est sur un algo optimiste qui n'attend donc pas de réponse du serveur pour s'exécuter
• les requêtes de base de donnée sont exécutées sur une base de données locale, ça va donc très vite : toujours pas de transmission par le réseau à moins d'un changement (merci MongoDB)
• la mise en cache locale accélère encore le processus concernant la génération de vue et la base de données locale
• si une donnée change, la re-génération des portions de la vue qui changent est faite automatiquement sans code supplémentaire de la part du développeur
• les templates étant donnés au client et générés de son coté, la génération automatique peut se permettre de détecter qu'une boucle dans le template est impactée par le changement (un nouveau commentaire a été posté par exemple), et re-généré cette portion, quelle que soit sa complexité

Pour revenir au mécanisme de pub/sub, on ne sousrit pas à un """simple""" message transmis par websocket; on indique à Meteor de quelle portion de la base on a besoin, à part le "je publie sous ce nom un truc/je souscris à un truc", les deux n'ont rien à voir.

Voilà voilà, j'espère que ça t'a aidé à mieux comprendre la différence qu'il y a entre les deux, et pourquoi avec une même connexion la sensation de fluidité et de rapidité d'un site peut être très différente selon la technologie. Ca n'en fait pas une technologie magique, mais elle facilite grandement la conception d'interfaces avec rafraichissement en temps réel, car le coté full-client hormis la donnée change pas mal la donne.

Un dernier point qui peut éventuellement (à chacun de voir) être très utile avec cette techno JS (mais elle n'est pas la seule) : comme contrairement à PHP il n'y a que des technologies "client" d'employées, une application développée avec peut automatiquement être build et déployée comme applications IOS et Android. Certains jeux par navigateur vont jusqu'à proposer une version en application mobile de leur jeu, ça peut être intéressant.

(ça part en H.S. ... x) j'espère que Haoxi va pouvoir se renseigner un peu partout avant de repartir à fond dans son projet)

-
Edité par Genroa 17 janvier 2017 à 11:26:16

c'est vrai que si tu veux exporter en application après c'est une superbe feature mais je reste partager sur l'utilisation de meteore pour 3 raison après dit moi si je me trompe mais on es obliger d'utiliser un framework js du type angular js ou les 2 autres proposer déjà ceci es un frein pour moi je n'ai pas encore décider de passer a ces framework même s'il on l'air cool j'en ai pas encore ressentit le besoin d'y passer.

La 2 eme raison es que si j'utilisait meteor je serais rendu a faire encore plus de requête (j'y reviens après).

Et la 3 eme raison es plus personnel comme tu l'a dit meteor es surement plus appropriée pour gérer des vue plus rapidement personnellement j'ai fais en sorte que le joueur soit toujours sur la même page avec quelque div qui sont cacher de base pour faire apparaître certain élément qui sont gros avec un show() et en modifiant les donnée dedans grâce a ajax lors de l'apparition de ces div.

C'est sur que par contre je vais pas changer toute la structure de la page j'ai fais en sorte de porter mon design sur une seul et unique page lorsque que l'on joue le controller es alors appeler une fois au chargement de la page et c'est tout les infos sont charger a la connexion et jusqu’à la était maintenu par ajax pour changer certaine donnée quand le joueur fais une action, et les résultats apparaissent instantanément rien qu'avec la requête ajax le seul problème es que l'on ne peut pas savoir si des données ont changer s'il ne fais pas d'action a part en fesant du long-pooling qui es assez lourd et ne donneras pas forcement les donnée au bon moment.

C'est uniquement pour cette raison que j'utilise les websocket de une sa me fais faire moin de requête mais en plus grâce a sa si un joueur es connecter et que la donnée doit être changer dans sa vue elle es changer instantanément c'est la que j'en reviens a faire moin de requête car avec meteor non seulement tu modifie les donnée dans la bdd mais juste après tu doit lire la donnée pour l'envoyer a ceux qui y sont souscris alors que par exemple moi je me sert de ma classe je change la valeur en bdd vu que on sait quel valeur on a mis dans la bdd on renvoi la valeur une fois changer en bdd en websocket sans relire la bdd car ce que j'envoi c'est ce que j'ai envoyer dans ma requete update en fait rien que l'utilisation de php et ajax es rapide le but de ajax c'est de ne pas changer de page ou de ne pas recharger la page et la depuis que j'ai le serveur websocket je peux encore alléger les appel a des fonctions ajax

par exemple si j'utilisait meteor pour faire une attaque je serais rendu a faire les même requêtes pour instancier les personnages et les faire combattre sauf qu’après il va allez la relire pour l'envoyer alors que la je la modifie et je l'envoi instantanément sans la relire dans la base et en php rien ne m'enpeche d'utiliser mongoDb et d'avoir les même performances que meteor tant que je ne doit pas générer une page entière(ce n'est pas le cas pour le moment j'utilise mysql)

après pour ce qui es du chargement des pages plus rapide j'ai entendu parler du protocole http2 il y a pas longtemps qui marche sur tout sauf opera mini (http://caniuse.com/#search=http2) donc a la finale y'a moyen de rafraichir des pages plus vites en php aussi après je n'ai pas tester donc n'ai pas pu comparer mais peux être que sa s'équivaut maintenant au temps de chargement d'une page meteor

donc a la finale on peut obtenir les même performance avec les 2 sans trop ce casser la tête non plus et pour ce qui es de l'export mobile le responsive es aussi efficaces

personnellement quitte a faire un site avec un serveur en javascript je serais plus du coter de nodejs + mongoDb plutot que meteor car a la final le mieux c'est quoi c'est de faire une requete pour chaque variable qu'il faut envoyer une fois modifier alors que tu aurais juste a renvoyer la valeur du update avec un websocket sa ne ferais que un petit peu de code en plus 

pour en revenir a php pour obtenir une bonne rapidité je fais ainsi :

• l'utilisateur arrive sur le site, il reçoit une page (détail plus loin).
• l'utilisateur ce connecte
• le serveur fait ses opérations via le contrôleur
• le serveur fait ses requêtes en base de données
• entre autre à partir des résultats, il génère une page html+css avec du js avec les infos de départ
• le serveur retourne une page HTML+CSS avec du JS dedans pour se connecter au serveur de websocket
• une fois la page reçue, le client se connecte aux websockets et souscrit à des émissions de messages
• lorsque ces messages sont envoyés et réceptionnés par le client, du code écrit sur mesure met à jour la page (on part donc du principe que les modifications ne sont pas énorme, mais on peut toujours faire une div cacher qui prend le dessus sur toutes les autre et s'en servir comme une autre page en le fesant apparaitre ou disparraitre au besoin)

en fait tout sa pour dire que on peut obtenir les même resultat avec meteor que avec php + js(client) et tout sa dans les même performance tout dépend de ce que tu as besoin de faire mais a chaque problème a sa solution surtout que rien ne t’empêche de faire une grande page html avec des éléments cacher dont tu te sert comme autre page pour améliorer le chargement quand tu l'ouvre tu met les donnée récupérer en ajax si tu as besoin car a la final le html de la page sera charger que une fois 

et pour en revenir au sujet principal la date du post le dernier commit et les sources j'ai compris que le projet était mal partit pour voir le jour

-
Edité par stevenhervy1 17 janvier 2017 à 14:19:50

Salut,

J'ai suivi attentivement votre débat entre vos deux techniques. C'est très intéressant et c'est la que je me dis que le choix du langage, du framework ou encore de la méthode de codage, peut plaire comme déplaire. Il n'y à pas a pas de bon ou mauvais choix. Chaque personne à sa façon de coder. C'est là où ça devient plus compliqué pour le projet.

stevenhervy1 a écrit:

et pour en revenir au sujet principal la date du post le dernier commit et les sources j'ai compris que le projet était mal partit pour voir le jour

Tu as plus ou moins raison le projet est mal partie. Déjà il repart de 0 en terme de codage. Il faut que je réfléchisse si le jeu doit être codé en procédural même si ça risque d'être interminablement long et peu productif, en POO ou garder symfony même si ça ne correspond pas forcement à ma cible.

Je vais probablement mettre le projet en suspend le temps de trouver une réponse à cette question

bha pour moi vu que le public de dev que tu vise minimum es :

aux codeurs qui ont déjà une bonne connaissance des langages suivants : Html/CSS ; PHP/SQL. Les tutos proposés seront qu’en accord avec le jeu, on apprendra pas comment ecrire du texte, utiliser un formulaire ou autre…

je pense que tu peux déjà partir minimum sur de la poo des personnes qui savent comment coder en procédural seront apte a comprendre les objets avec un tuto faut juste expliquer les différents procéder si tu veux j'ai déjà une base de personnages de coter avec quelque fonction comme attaquer ou voler moi je serais partant pour filer quelque fonctions supplémentaire a ton projet seul problème c'est que je travail déjà sur un jeu donc je ne peux pas créer la base de ton jeu entièrement, mais y apporter des fonctions supplémentaire de temps en temps pourquoi pas

ou en est le projet ?

Pour le moment à l'abandon pourquoi ?