Backbone.js, retour d’expérience

L’objectif de ma dernière mission fut de développer une single-page application en JavaScript au dessus d’une API Web Rest.

Inutile de vous dire que je suis bien conscient des inconvénients d’une telle architecture et du tout JavaScript mais force est de constater que de plus en plus d’applications web sont bâties sur ce principe, et pas des moindres. Mais de là à dire que l’amélioration progressive est morte, il y a un pas que je n’ose pas encore franchir.

Le choix n’est pas aisé lorsqu’il s’agit de sélectionner un MV* framework vu la myriade de solutions existantes. TodoMVC propose de vous montrer comment développer une todo list avec les différents frameworks existants. Le seul reproche que je lui fait est de se baser sur un challenge technique faible (une todo list) mais vous aurez tout de même un premier aperçu de la philosophie des frameworks utilisés.

J’ai proposé d’utiliser AngularJS parce que j’en avais une première expérience mais le choix de mon client s’est porté sur Backbone.js.

Apprivoiser Backbone.js

Je voulais vous faire une bonne et brève introduction à Backbone.js mais je n’aurai fait que paraphraser cet article : Backbone, deux ans après.

L’introduction étant faite, je recommande les choses suivantes pour être efficace rapidement et respectueux des bonnes pratiques avec Backbone.js :

• RTFM & Read the Source, Luke
• lire Backbone.js Deconstructed
• lire et suivre les tutos du livre Backbone Fundamentals
• creuser les Backbone.js Resources

Si vous avez beaucoup de temps et que vous voulez savoir comment on construit un framework du type Backbone.js je conseille la lecture de JavaScript Web Applications par Alex MacCaw.

Si vous avez encore du temps et que vous avez une bonne tolérance aux lolcats regardez les présentations de la BackboneConf et notamment Building Reflow qui explique comment ils ont utilsé Backbone pour faire Adobe Edge Reflow.

Gestion des dépendances

JavaScript n’a pas, dans l’état actuel des choses, de mécanisme natif d’import de modules pour gérer les dépendances. Certains frameworks mettent à disposition des palliatifs. Je pense au mécanisme d’injection de dépendances d’AngularJS par exemple. Il n’y a rien de ce type dans Backbone.

Il faudra vous reposer sur un système tiers. Et Require.js est une référence dans ce domaine. De plus r.js, son outil d’optimisation, permet de combiner, de rapetisser et d’uglifier (comme si le code JS n’était pas assez dégueu comme ça) tous les fichiers JavaScript. Cet outil d’optimisation peut être lancé de différentes façon. Via Node.js par exemple :

node r.js -o build.js

Je vous conseille la lecture de cet article pour vous faire une idée de la manière de gérer les dépendances dans un projet Backbone en utilisant RequireJS.

Quelques notes techniques

Backbone.sync est très important. C’est ici que vous allez surcharger ou étendre certaines méthodes pour gérer la protection CSRF, l’authentification etc.

Backbone est basé sur le modèle observateur/observable de Smalltalk. La gestion des évènements est capitale et change la manière dont est architecturé le code.

Contrairement aux applications web côté serveur traditionnelles dans lesquelles on observe souvent une parité entre le nombre de routes et le nombre de vues, on se retrouve avec beaucoup moins de routes dans les applications Backbone. De même il n’est plus nécessaire de gérer le pattern du Post-Redirect-Get.

La gestion actuelle des objets en JavaScript est franchement mal foutue. Backbone fait un usage intensif du pattern d’extension d’Underscore. Certains adoptent par conséquent une philosophie plus orientée mixin :

_.extend(TheView.prototype, ViewMixin);

Attention aux vues zombies ! Si vous attachez une vue à un élément html existant prenez garde de bien détruire tous les événements associées à l’élément du DOM concerné. Ce problème est très répandu et les surcouches comme marionettejs gèrent ce point sans que vous ayez besoin d’y penser. Mais pensez-y quand même si vous faites du Backbone brut de pomme :)

Faites bien attention à la gestion de l’escaping HTML par le moteur de template que vous utiliserez.

La suite au prochain (hypothétique) numéro ;)