03-09-2015, 10:44 PM
Dans le cas d'un jeu TR, mon approche consisterai à dire:
• Je fais le jeu statique, et le joueur fait "F5" tout le temps pour voir bouger
• Je deploy (expérience utilisateur pauvre, c'est du beta)
• Je crée un composant qui se charge de faire le push coté serveur et qui le récupère coté client
• Je deploy cette feature
• Dans 5 ans, quand HTML6 débarque avec une notion de push intégré, je crée un autre composant qui utilise HTML6 pour ce push
• Je deploy ce nouveau truc
• Je vire l'ancien
Je pars du principe qu'on ne sait pas à quoi ressemblera le web dans 10 ans car le web d'aujourd'hui était dur à imaginer il y a 10 ans. Du coup, je préfère me baser sur ce genre d'approche incrémentale, avec des composants isolés qui s'appuient sur les normes internationales, plutôt qu'un tout-en-un qui pourrait avoir le même débouché que Microsoft Silverlight (c'était le bash du jour!). C'est rentable à court-terme ("prêt à l'emploi"), pas à long terme: quand sortiras le prochain serveur de push (ou de télépathie) trop bien, tu vas faire comment?
Bref, le soucis pour moi des solutions "tout intégrés", c'est qu'on se retrouve ligoté à un bundle de technos sans pouvoir en sortir (et on prend le risque de rater les nouveautés du futur). Chacun fait ce qu'il veut après... quoiqu'il en soit, la meilleure techno est celle que l'on maitrise et qui est étudiée pour faire ce dont on a besoin.
• Je fais le jeu statique, et le joueur fait "F5" tout le temps pour voir bouger
• Je deploy (expérience utilisateur pauvre, c'est du beta)
• Je crée un composant qui se charge de faire le push coté serveur et qui le récupère coté client
• Je deploy cette feature
• Dans 5 ans, quand HTML6 débarque avec une notion de push intégré, je crée un autre composant qui utilise HTML6 pour ce push
• Je deploy ce nouveau truc
• Je vire l'ancien
Je pars du principe qu'on ne sait pas à quoi ressemblera le web dans 10 ans car le web d'aujourd'hui était dur à imaginer il y a 10 ans. Du coup, je préfère me baser sur ce genre d'approche incrémentale, avec des composants isolés qui s'appuient sur les normes internationales, plutôt qu'un tout-en-un qui pourrait avoir le même débouché que Microsoft Silverlight (c'était le bash du jour!). C'est rentable à court-terme ("prêt à l'emploi"), pas à long terme: quand sortiras le prochain serveur de push (ou de télépathie) trop bien, tu vas faire comment?
Bref, le soucis pour moi des solutions "tout intégrés", c'est qu'on se retrouve ligoté à un bundle de technos sans pouvoir en sortir (et on prend le risque de rater les nouveautés du futur). Chacun fait ce qu'il veut après... quoiqu'il en soit, la meilleure techno est celle que l'on maitrise et qui est étudiée pour faire ce dont on a besoin.