Ember.js ou Backbone.js pour backend Restful

Contrairement à l’opinion populaire, Ember.js n’est pas une «approche plus lourde» de Backbone.js. Ce sont différents types d’outils qui ciblent des produits finis totalement différents. Les applications d’Ember sont celles où l’utilisateur gardera l’application ouverte pendant de longues périodes, peut-être toute la journée, et les interactions avec les vues de l’application ou les données sous-jacentes déclenchent des changements profonds dans la hiérarchie des vues. Ember est plus grand que Backbone, mais grâce à Expires , Cache-Control cela ne concerne que le premier chargement. Au bout de deux jours d’utilisation quotidienne, 30k supplémentaires seront éclipsés par les transferts de données, plus rapidement si votre contenu implique des images.

Le backbone est idéal pour les applications avec un petit nombre d’états où la hiérarchie des vues rest relativement plate et où l’utilisateur a tendance à accéder à l’application rarement ou pour des périodes plus courtes. Le code de Backbone rest court et sympathique car il suppose que les données sauvegardées dans le DOM seront jetées et que les deux éléments seront collectés: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 La taille réduite de Backbone le rend également plus adapté aux interactions brèves.

Les applications que les utilisateurs écrivent dans les deux environnements reflètent ces utilisations: les applications Ember.js incluent le tableau de bord Web de Square , Zendesk (au moins l’interface agent / ticketing) et le planificateur de Groupon : toutes les applications dans lesquelles l’utilisateur travaille toute la journée.

Les applications Backbone se concentrent davantage sur les interactions brèves ou occasionnelles, qui ne sont souvent que de petites sections d’une page statique plus grande: airbnb , Khan Academy , la carte et les listes de Foursquare .

Vous pouvez utiliser Backbone pour créer les types d’applications cibles (par exemple Rdio ) en augmentant la quantité de code d’application dont vous êtes responsable pour éviter les problèmes tels que les memory leaks ou les événements zombie (je ne recommande pas personnellement cette approche). ou b) en ajoutant des bibliothèques tierces telles que backbone.marionette ou Coccyx – il y a beaucoup de ces bibliothèques qui essayent toutes de fournir une fonctionnalité similaire et vous finirez probablement par assembler votre propre framework personnalisé si vous aviez juste utilisé Ember.

En fin de compte, la question de «qui utiliser» a deux réponses.

Premièrement, “Qu’est-ce que je devrais utiliser, généralement, dans ma carrière”: Les deux, tout comme vous finirez par apprendre tous les outils spécifiques au travail que vous voudrez faire à l’avenir. Vous ne demanderiez jamais “Backbone ou D3?” “Backbone or Ember” est une question tout aussi stupide.

Deuxièmement, “Que dois-je utiliser, en particulier, sur mon prochain projet”: dépend du projet. Les deux communiqueront avec un serveur Rails avec la même facilité. Si votre prochain projet implique un mélange de pages générées par le serveur avec des “îlots de richesse” fournis par JavaScript, utilisez Backbone. Si votre prochain projet pousse toutes les interactions dans l’environnement du navigateur, utilisez Ember.

Pour donner une réponse brève et simplifiée: pour un backend RESTful, vous devez pour le moment utiliser Backbone.

Pour donner une réponse plus complexe: cela dépend vraiment de ce que vous faites. Comme d’autres l’ont dit, Ember est conçu pour différentes choses et fera appel à des personnes différentes. Ma réponse courte est basée sur votre inclusion de l’exigence RESTful.

À l’heure actuelle, Ember-Data (qui semble être le mécanisme de persistance par défaut au sein d’Ember) est loin d’être prêt pour la production. Cela signifie qu’il comporte un certain nombre de bogues et que, de manière cruciale, il ne prend pas en charge les URI nesteds (/ posts / 2 / comments / 4556 par exemple). Si REST est votre exigence, vous devrez alors contourner ce problème pour le moment si vous choisissez Ember (c.-à-d. Vous devrez soit le pirater, attendre, implémenter quelque chose comme Ember-Data à partir de rien, ou ne pas utiliser URIs -RESTful). Ember-Data ne fait pas ssortingctement partie d’Ember, c’est donc tout à fait possible.

Les principales différences entre les deux, hormis la taille, sont essentiellement les suivantes:

Ember essaie de faire autant que possible pour vous afin de ne pas avoir à écrire autant de code. Il est très hiérarchique et, si votre application est également très hiérarchisée, elle conviendra probablement. Parce que cela fait beaucoup pour vous, il peut être difficile de savoir d’où proviennent les bogues et pourquoi un comportement inattendu se produit (il y a beaucoup de «magie»). Si vous avez une application qui s’intègre naturellement dans le type d’application qu’Ember s’attend à ce que vous construisiez, cela ne sera probablement pas un problème.

Backbone essaie de faire le moins possible pour vous permettre de raisonner sur ce qui se passe et de créer une architecture adaptée à votre application (plutôt que de créer une application adaptée à l’architecture du framework que vous utilisez). Il est beaucoup plus facile de commencer, mais si vous ne faites pas attention, vous pouvez vous retrouver rapidement avec un désordre. Il ne fait pas de choses comme des propriétés calculées, des événements de déliaison automatique, etc. et vous les laisse, vous devrez donc implémenter beaucoup de choses (ou au moins choisir des bibliothèques qui le font pour vous), bien que ce soit plutôt le point entier.

Mise à jour : Il semble que, récemment, Ember supporte maintenant les URI nesteds, donc je suppose que la question se pose de savoir combien de magie vous aimez et si Ember convient parfaitement à votre application.

Je pense que votre question sera bientôt bloquée 🙂 Il y a quelques controverses entre les deux frameworks.

En gros, Backbone ne fait pas beaucoup de choses, et c’est pourquoi je l’aime beaucoup: vous devrez coder beaucoup, mais vous coderez au bon endroit. Ember fait beaucoup de choses, alors vous feriez mieux de regarder ce qu’il fait.

La discussion sur les serveurs est l’une des rares choses que Backbone fait, et elle fait un excellent travail avec elle. Je commencerais donc par Backbone, puis essayerais Ember si vous n’êtes pas totalement satisfait.

Vous pouvez également écouter ce podcast où Jeremy Ashkenas, créateur de Backbone, et Yehuda Katz, membre d’Ember, ont eu une bonne discussion