Tendance développement web en 2013

[Maks]

Une infographie très intéressante : http://img1.lafermeduweb.net/img/usages-...uweb.jpg?1 (je la link elle est très longue).

En résumé :

Chrome est maintenant de loin le browser n°1 en France et dans le monde (si on m'avait dit que ça arriverait un jour !).
IE 6 (0.4%) et IE7 (0.8%) sont morts.
Aussi, jQuery (utilisé par 55% des sites web mondiaux) va supprimer son support de IE6, 7 et 8 à partir de la version 2.0 précipitant surement IE8 vers les 0% en 2014.
Windows 8 et IE10 sont à la ramasse pour le moment. Migration de XP vers 7 (arrêt des MAJ XP en 2014).

2013 année du responsive design ?
2013 année des SPA ? (les auteurs de Rails 4.0 pas nécessairement d'accord http://weblog.rubyonrails.org/2013/2/25/...4-0-beta1/)

[Holy]

SPA ? Késako ?

Sinon rien de très étonnant la-dessus, les lignes des technos ont énormément bougé ces dernières années et le web semble enfin assumer sa nouvelle maturité. Il était plus que temps de passer outre la rétro-compatibilité.

Cela étant dit, je trouve ça plutôt étonnant que Windows 8 se viande, son implémentation est pas fondamentalement différente de W7. A voir avec le temps.

[Maks]

SPA = Single Page Application (via un framework MVC pour Javascript)
(note pour niahoo qui cherchait un acronyme tendance dans le genre RIA, le voici :p)

W8 j'aime pas l'interface métro perso ^^

[niahoo]

Oui bien vu

[Sephi-Chan]

Pour avoir développé des Single Page App très complexes avec Backbone et Marionette, je réalise bien que je ne le ferais peut-être plus : c'est extrêmement coûteux en terme de temps de développement et en prises de tête. Bien que le résultat soit souvent agréable pour l'utilisateur (la performance ressentie est excellente), le gain est assez minime par rapport à une approche plus traditionnelle réalisée efficacement (cf. ce qu'a réussi à faire 37signal avec Basecamp).

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).

À 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).

Je dirais donc que 2013 sera l'année du responsive, mais pas nécessairement des Single Page Apps.

[Maks]

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 ?

(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é ?

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.

À 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 ?

[Sephi-Chan]

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 ?

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).

(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é ?

Tout le templating est fait serveur side et dynamiser avec de l'Ajax malin. Le site est très rapide et réactif.

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.

L'injection de script (et leur concaténation/compilation) peu être assez évoluée, notamment en ce qui concerne les templates client-side.

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.

À 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 ?

C'est pas vraiment une réponse, c'est une solution alternative qui permet — sans rien faire — de rendre leurs pages Web plus réactives et donc plus sympa à utiliser. Ça convient à 90% des développeurs, ça prend 2 minutes à implémenter. Je ne crois pas qu'il y ai de démo en ligne tellement c'est simple.

D'autres outils comme PJAX sont assez similaires (en un peu plus puissant et complexe).


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.

[Maks]

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).

C'est clair que là c'est vraiment un projet imposant. Ca peut vite devenir le bordel dans le code si t'es pas très organisé j'imagine. Dans ce cas Marionette est indispensable car il apporte une structure pour l'application, ce que ne fais pas Backbone seul.

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.

C'est intéressant en effet, j'avais vu les JST dans le screencast BackboneRails, merci du lien A voir si je peux faire la même chose avec l'équivalent pour Node/Express

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 ?

[Sephi-Chan]

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 ?

Et bien, après réflexion, développer Seelies avec Backbone serait sans doute moins complexe que l'application que j'ai évoqué plus tôt dans la mesure où j'aurais beaucoup moins de routes : la page d'accueil, le dashboard du joueur et la page de jeu, éventuellement quelques pages annexes (pas forcément servies par Backbone, d'ailleurs).

Une fois sur la page de jeu, je me fous de l'URL.

[Maks]

Tu as raison c'est le top JST. J'ai trouvé un module ressemblant pour Node : https://github.com/techpines/asset-rack (en plus de Snockets et Connect-Assets pour l'asset pipeline) pour des templates Jade.

{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()