Citation :(cf. ce qu'a réussi à faire 37signal avec Basecamp).

Citation :Ruby on Rails et son asset pipeline aident beaucoup, et malgré ça c'est pas évident. Je n'ose à peine imaginer ce que ça serait pour quelqu'un moins outillé (soit la majorité des développeurs amateurs).

Citation : À l'inverse, l'alternative qu'ils proposent avec Turbolinks est vraiment génial pour améliorer la navigation de tonnes d'utilisateurs. Pour rappel, Turbolink est un script qui transforme automatiquement tous les liens internes d'une page en liens Ajax : le contenu des pages est récupéré en asynchrone et injecté dans le body (le titre de la page est également modifié si besoin) et l'URL est changé en Javascript (donc l'historique normal fonctionne bien).

(26-02-2013, 09:44 PM)Maks a écrit : Le développement de la SPA a été difficile (par curiosité est-ce que tu peux en dire plus sur les projets réalisés ?) mais est-ce que tu l'imputes réellement à la technologie ou plutôt au framework (Backbone/Marionette) voir à la courbe d'apprentissage. Est-ce que tu penses qu'avec Angular ou Ember tu t'en serais mieux sorti ?

(26-02-2013, 09:44 PM)Maks a écrit :

Citation :(cf. ce qu'a réussi à faire 37signal avec Basecamp).

La dernière fois que j'ai utilisé Basecamp c'était codé avec Backbone, ça a changé ?

(26-02-2013, 09:44 PM)Maks a écrit :

Citation :Ruby on Rails et son asset pipeline aident beaucoup, et malgré ça c'est pas évident. Je n'ose à peine imaginer ce que ça serait pour quelqu'un moins outillé (soit la majorité des développeurs amateurs).

Oui mais ça reste qu'une aide pour l'injection de scripts (si je ne m'abuse). Après ceux qui préfèrent rajouter un module AMD dans tout ça, peut être que ça complique encore les choses en effet.

(26-02-2013, 09:44 PM)Maks a écrit :

Citation : À l'inverse, l'alternative qu'ils proposent avec Turbolinks est vraiment génial pour améliorer la navigation de tonnes d'utilisateurs. Pour rappel, Turbolink est un script qui transforme automatiquement tous les liens internes d'une page en liens Ajax : le contenu des pages est récupéré en asynchrone et injecté dans le body (le titre de la page est également modifié si besoin) et l'URL est changé en Javascript (donc l'historique normal fonctionne bien).

C'est un peu la réponse de Rails aux SAP ^^ En même temps ils n'allait pas se cantonner au rôle d'API JSON pour Backbone.
Il existe déjà un exemple en ligne ?

(26-02-2013, 10:12 PM)Sephi-Chan a écrit : C'était une application type portail social relatif à l'auto/moto, rempli par les utilisateurs et entièrement internationalisé.

L'ensemble du site permettait d'accéder à des galeries (avec disposition en mosaïque éditable en live, cropping (côté client et serveur)), à des listes de pièces de véhicules (très détaillés, avec leur compatibilité, les endroits où on pouvait l'acheter et à quel prix), de services (quelle prestation, où, à quel prix, comparatif avec le coût horaire dans le pays), des petites annonces, etc.

La grosse force était donc que toutes les données techniques étaient internationalisées : si un français disait "le VFR 800 Honda a une puissance de 110 ch", les valeurs étaient converties automatiquement en une valeur normalisée, puis resservie à chaque utilisateur selon ses propres unités (dans les cas des chevaux, on normalisait en kW et on ressortait en chevaux UK/US/EU, mais il y a des unités bien plus compliquées, comme les consommations de carburant).

Et bien sûr, sans jamais recharger de page, avec du deep-linking, donc les pages avaient toute une URL et on devait accéder aux même fonctionnalités en accédant par navigation que par accès direct par l'URL. Tout était très snappy : tu touches, ça bouge instantanément (parfois en te feintant, en te faisant croire que c'était fait alors que c'était en cours).

Bref, c'était vraiment long et difficile à développer/debug. Et les frameworks comme Ember ou Angular sont moins adaptés (selon moi) aux grosses complexités, là où Backbone se débrouille plutôt bien (puisqu'il fournit des outils assez brut sur lesquels ont construit).

Citation :Par exemple, l'assets pipeline te permet de définir des templates (Haml, EJS, Mustache, Handlebars, etc.) qui sont compilées en fonction Javascript avant d'être injectés dans les scripts, ce qui permet de s'en servir pour générer du DOM très facilement (et de manière très efficace).

Cf. Using JST templates with Marionette, que j'ai écrit.

Citation :En tout cas, pour Seelies, je pense partir sur du jQuery basique. L'utilisation de Backbone et Marionette m'a permis de comprendre certaines choses, notamment la puissance des événements personnalisés pour découpler l'application en plein de petits composants indépendants mais capable de communiquer entre eux.

(27-02-2013, 01:40 AM)Maks a écrit :

Citation :En tout cas, pour Seelies, je pense partir sur du jQuery basique. L'utilisation de Backbone et Marionette m'a permis de comprendre certaines choses, notamment la puissance des événements personnalisés pour découpler l'application en plein de petits composants indépendants mais capable de communiquer entre eux.

Tu comptes faire une SAP avec uniquement jQuery ?

{JadeAsset} = require 'asset-rack'



app.configure ->

  app.use new JadeAsset # Templates Jade pré-compilés pour Backbone

    url    : '/backbone/templates.js'

    dirname: __dirname + '/app/assets/javascripts/app/templates'

table

  for model in models

    tr

      td

        b #{model.pseudo}

      td

        i #{$.format.date(model.date, $.format.date.defaultLongDateFormat)}

      td

        | #{model.text}

namespace App:Views:



  class PrivateEvents extends Backbone.View



    render: -> @$el.html Templates.privateEvents models: @collection.toJSON()