Apprendre Ajax et bien choisir ses outils

[niahoo]

C'est plus vraiment à l'ordre du jour pour être honnête

Marionette ou conquest on rails ?

[Sephi-Chan]

Excellente question. Conquest on Rails est toujours d'actualité (même si plus loin dans la liste). Quant à la technologie cliente, je ne sais pas si j'utiliserais Marionette, a priori oui, mais si mes petites expérimentations avec Angular sont porteuses, je changerais peut-être d'avis.

[niahoo]

Je vais tester angular. backbone c'est trop chiant je trouve. J'ai voulu tester emberjs mais rien que le chargement de la librairie lance des erreurs dans la console. J'ai voulu tester dojo mais ça fait double emploi avec jQuery qui est déjà dans mes dépendances. J'ai voulu batman ou spine, mais c'est du coffeescript, etc ...

C'est vraiment pas facile de trouver quelque chose qui fonctionne et dont la doc est disponible. à part backbone, mais c'est vraiment relou à mettre en place ... cette librairie te donne l'impression de tout te taper.

On va voir pour angular.

[archANJS]

Tenez-nous au courant, j'ai également à faire un choix de ce genre, et l'avis/expérience ne serait pas de refus

[niahoo]

Bon je viens de finir le tuto de angular et ça me paraît très bien. En plus, il permet de se passer de ce foutu système AMD tout en apportant les mêmes bénéfices.

Je vais maintenant essayer d'y intégrer mon système de push pour voir si ça tourne bien.

[Holy]

Pour ceux qui voudraient le tester avec Rails, j'ai trouvé ce tutorial plutôt bien foutu et poussé (8 parties) : http://blog.berylliumwork.com/2012/09/tu...rails.html

Je vais faire mes petits essais de mon côté aussi. L'idée des réponses full Json avec la gestion des vues directement au niveau du client, ça me tente bien, surtout vu comment Angular gère le binding.

[Maks]

Si ça peut aider certains à voir plus clair

If we had to order these frameworks on a scale of complexity, learning curve and feature set, from left to right, it might look like:

Source : http://net.tutsplus.com/tutorials/javasc...-web-apps/

[Holy]

C'est bizarre, mais plus j'avance sur Rails plus je me dis que des solutions full-stack comme Meteor sont plus intéressantes. Quand je vois la puissance de la synchro entre clients, c'est juste parfait pour le multi-joueur (gain de productivité et de réactivité énorme !).

J'hallucine de la puissance de Angular et Meteor. Dommage que les technologies (particulièrement Meteor) soient pas plus matures parce que, franchement, c'est du lourd.

Je me pose la question suivante : que peut-on faire avec Rails qu'on ne puisse pas faire avec Meteor ?

[Maks]

J'entends beaucoup parler de Meteor comme solution complète (du client au serveur via Node si j'ai bien suivi ?), tu as testé ?

[Holy]

J'entends beaucoup parler de Meteor comme solution complète (du client au serveur via Node si j'ai bien suivi ?), tu as testé ?

J'ai pas testé, je me renseigne depuis quelques jours et je dois avouer que dans l'idée ça a l'air super puissant et répond à une problématique que nous rencontrons quasiment tous dans la création de jeu vidéo : comment arriver au "temps réel" ?

En fait, la solution complète repose sur NodeJS, avec en plus une mise à jour en temps réel grâce au templating (on a accès à la BDD depuis la console du navigateur !), c'est encore un pas plus loin que Angular qui utilise le templating sur une base locale. Y a moyen de gérer les droits avec différents package heureusement

Dans l'idée ça a l'air génial, mais j'ai quand même un doute : la structure interne des projets Meteor. A l'heure actuelle, le plus basique des projets consiste en 3 fichiers (un fichier html, un fichier css et un fichier js). J'ai du mal à imaginer un gros projet sur Meteor du coup. C'est un poil "trop" simple (surtout comparé à RoR que j'ai testé récemment) au point que c'en est déroutant.

J'ai trouvé un bon article qui décrit les bases de Meteor de façon simple : Learn Meteor Fundamentals