Présentation comparée de Backbone JS et Ember JS

Le 15 février dernier s’est tenue une soirée sur les frameworks JavaScript au LyonJS. Romain Philibert a présenté le framework Backbone JS tandis que Damien Mathieu s’est attaqué à Ember JS.

Backbone JS

La première présentation portait donc sur Backbone JS. Pour l’historique, ce framework est né du besoin de son auteur (Jeremy Ashkenas) qui travaille à la réalisation du site DocumentCloud. Romain a donc pris le parti de présenter le framework en regardant l’utilisation qui en était faite dans le site, tout en prévenant que les deux avaient évolué en parallèle et que l’application ne tirait pas forcément partie des dernières fonctionnalités de la librairie.
L’objectif de ce framework est de structurer le développement d’une application web monopage (Single Page Application) en JavaScript, en apportant notamment le concept MVC. Il s’appuie sur la librairie Underscore JS (aussi réalisée par Jeremy Ashkenas) et jQuery. Sans entrer dans le détail et sans prétendre à l’exhaustivité, les principales fonctionnalités de Backbone JS sont:

  • Model & Collections : ils permettent de définir une structure de données, de la connecter avec le serveur à travers des opérations de type fetch et sync, d’avoir une gestion d’évènements sur les modifications.
  • View : elle permet de se rattacher un composant au DOM et d’écouter les évènements graphiques facilement. Étonnamment, le framework n’intègre pas d’outil pour générer les vues à partir de template, mais n’interdit pas l’utilisation d’Handlebars ou autre.
  • Router : il apporte des outils pour gérer la navigation dans une application single page.

Le framework est simple, les concepts peu nombreux, son code source reste parfaitement lisible et compréhensible. On retiendra du parallèle avec DocumentCloud que, contrairement à ce qu’on pourrait y penser, l’application n’est pas forcément un modèle d’utilisation de la librairie. Mais cela prouve que Backbone est assez souple pour qu’on puisse s’en servir à sa guise et que et qu’il s’agit bien d’un framework polyvalent et pas forcément limité aux besoins d’une seule application/personne.
Les slides, la vidéo.

Ember JS

Le second sujet était donc Ember JS. La raison d’être d’Ember JS est à peu près la même, mais son historique est par contre bien différent. Apple a participé au développement d’un framework JavaScript nommé SproutCore pour son site iWork.com. Ember JS est un fork issu de ce framework, il s’appelait d’ailleurs initialement Sproutcore 2.
Ember JS s’appuie, dépend et intègre d’autres librairies telles que Handlebars ou Metamorph, ces principaux composants sont:

  • Model: comme Backbone JS, mais sans aborder les problématiques de synchronisation des données avec le serveur
  • View: elle s’appuie sur la librairie Handlebars pour produire du HTML à partir de templates, et Metamorph pour avoir un véritable système de binding des données dans la page Web. Ainsi, toute modification du modèle impacte la vue de manière transparente.
  • Router: Ember n’inclut rien nativement, il faut ajouter une extension comme Sproutcore Routing.

Bref, ce qui distingue Ember, c’est le binding de données: la « killer feature » qu’apprécient tant les développeurs Flex portée en JavaScript
Les slides.

Conclusion

Backbone est un petit framework qui permet de structurer les développements, tout en restant simple d’utilisation. Ember est fonctionnellement plus riche, mais semble aussi plus complexe.
D’autres comparaisons sur le plan des fonctionnalités: ici ou , ou bien des performances (par J. Ashkenas).

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

%d blogueurs aiment cette page :