Ember.js ou Backbone.js pour un backend reposant [fermé]


98

Je sais déjà que ember.js est une approche plus lourde que backbone.js. J'ai lu beaucoup d'articles sur les deux.

Je me demande quel framework fonctionne le plus facilement comme frontend pour un backend de rails restants. Pour backbone.js, j'ai vu différentes approches pour appeler un backend de repos. Pour braise, il semble que je doive inclure d'autres bibliothèques comme «data» ou «resources». Pourquoi y a-t-il deux bibliothèques pour cela?

Alors, quel est le meilleur choix? Il n'y a pas beaucoup d'exemples pour connecter le frontend au backend. Quel est un bon exemple de travail pour un appel de repos backend à ceci:

URI: ../restapi/topics OBTENIR les informations d'identification d'authentification: format admin / secrect: json


3
Je dois aimer une question qui n'est "pas constructive" mais la réponse utile et bien pensée a quand même obtenu plus de 240 votes positifs.
Andrew

Réponses:


257

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 finaux totalement différents. Le point idéal d'Ember, ce sont les applications dans lesquelles l'utilisateur maintiendra 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 de profonds changements dans la hiérarchie des vues. Ember est plus grand que Backbone, mais grâce à cela Expires, Cache-Controlcela n'a d'importance que sur la première charge. Après deux jours d'utilisation quotidienne, ces 30k supplémentaires seront éclipsés par les transferts de données, plus tôt si votre contenu implique des images.

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

Les applications que les gens écrivent dans les deux cadres reflètent ces utilisations: les applications Ember.js incluent le tableau de bord Web de Square , Zendesk (au moins l'interface agent / billetterie) et le planificateur de Groupon : toutes les applications dans lesquelles un utilisateur peut passer toute la journée à travailler.

Les applications de base se concentrent davantage sur des 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 ciblées par Ember (par exemple Rdio ) en a) augmentant la quantité de code d'application dont vous êtes responsable pour éviter des problèmes tels que des fuites de mémoire ou des événements zombies (je ne recommande personnellement pas cette approche) ou b) en ajoutant des bibliothèques tierces comme backbone.marionette ou Coccyx - il y a beaucoup de ces bibliothèques qui essaient toutes de fournir des fonctionnalités similaires qui se chevauchent et vous finirez probablement par assembler votre propre cadre personnalisé qui est plus grand et nécessite plus de code de colle que si vous venez d'utiliser Ember.

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

Premièrement, «Que dois-je utiliser, en général, dans ma carrière»: les deux, tout comme vous finirez par apprendre 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": Cela 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.


4
Excellente réponse, Trek. Je voulais juste commenter ici Expireset Cache-Controlaider beaucoup moins que les gens ne le pensent - en particulier en termes d'appareils mobiles qui les ignorent souvent. Je me souviens qu'une version d'iOS les a complètement ignorés (mais écoute toujours le manifeste du cache HTML5). De plus, ces valeurs d'en-tête n'aideront pas lors de la première visite d'un utilisateur, qui est généralement la plus critique pour décider si l'utilisateur restera et utilisera votre application. Dire toute cette différence de fichier de 30 Ko ne me semble pas si grave. Est-ce que c'est une différence brute ou minifiée et gzippée de 30k?
Mauvis Ledford

11
Si vous regardez des applications réelles qui sont du style qu'Ember est destiné à aider à créer, vous constaterez qu'il n'y a pas d'échappatoire à ces kbs embêtants. Soit ils proviennent d'Ember et le code de votre application est plus petit, soit ils proviennent de plugins de base, soit ils proviennent de code que vous écrivez vous-même. Wunderlist , que vous penseriez être de "simples" horloges à environ 300 ko de transfert. J'imagine qu'il serait de taille similaire avec Ember, peut-être plus petit - n'ayant jamais écrit une copie exacte de Wunderlist, je ne peux pas dire avec une certitude à 100%.
Trek Glowacki

1
Je suis d'accord, mon application backbone la plus populaire horloges à 178 ko + modèles compressés et minifiés. Juste en soulignant comment nous ne devrions pas nous fier à la mise en cache du navigateur.
Mauvis Ledford

2
Trek, vous maîtrisez parfaitement votre analyse de l'utilisation de Backbone dans les applications avec des modèles d'utilisation étendus et une gestion d'état complexe. J'ai vécu l'expérience de la conversion d'une ancienne application en Backbone et j'ai dû faire exactement ce que vous avez énuméré. Nous devions intégrer Marionette et écrire beaucoup de code de glue pour des choses comme le filtrage avant / après route, l'atténuation des fuites de mémoire et une meilleure gestion des événements.
Mike Clymer

9
"Vous ne demanderiez jamais à Backbone ou D3" - bien sûr, mais je peux facilement imaginer un projet où j'utiliserais D3 en conjonction avec Backbone. Il est probablement beaucoup plus difficile d'imaginer un projet où Backbone et Ember sont utilisés ensemble sur une seule page. Donc, je trouve la question "Backbone ou Ember" assez juste. Voici un autre article que j'ai trouvé assez instructif, car il compare les deux frameworks plus profondément: net.tutsplus.com/tutorials/javascript-ajax/…
Shiprack

26

Pour donner une réponse brève et simplifiée: pour un backend RESTful, pour le moment, vous devez 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 plaira à un groupe de personnes différent. Ma réponse courte est basée sur votre inclusion de l'exigence RESTful.

Pour le moment, Ember-Data (qui semble être le mécanisme de persistance par défaut dans Ember) est loin d'être prêt pour la production. Cela signifie qu'il a pas mal de bogues et, surtout, ne prend pas en charge les URI imbriqués (/ posts / 2 / comments / 4556 par exemple). Si REST est votre exigence, vous devrez contourner ce problème pour le moment si vous choisissez Ember (c'est-à-dire que vous devrez soit le pirater, attendre, implémenter vous-même quelque chose comme Ember-Data à partir de zéro, ou ne pas utiliser URI très RESTful). Ember-Data ne fait pas strictement partie d'Ember, c'est donc tout à fait possible.

Les principales différences entre les deux, mis à part la taille, sont essentiellement:

Ember essaie de faire autant que possible pour vous, afin que vous n'ayez pas à écrire autant de code. Elle est très hiérarchique et, si votre application est également très hiérarchique, elle conviendra probablement bien. Parce que cela fait beaucoup pour vous, il peut être difficile de comprendre d'où viennent les bogues et d'expliquer 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 afin que vous puissiez raisonner sur ce qui se passe et créer une architecture adaptée à votre application (plutôt que de créer une application qui correspond à l'architecture du framework que vous utilisez). C'est beaucoup plus facile de commencer mais, à moins que vous ne soyez prudent, vous pouvez vous retrouver avec un désordre très rapidement. Il ne fait pas de choses comme les propriétés calculées, les événements de dissociation automatique, etc. et les laisse à vous, vous devrez donc implémenter beaucoup de choses vous-même (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 prend désormais en charge les URI imbriqués, donc je suppose que la question se résume à combien de magie vous aimez et si Ember convient, d'un point de vue architectural, à votre application.


5
"surtout, ne prend pas en charge les URI imbriqués (/ posts / 2 / comments / 4556 par exemple)" Voici le commit pertinent d'il y a quelques semaines: github.com/emberjs/data/commit/… . Il sait qu'il peut être difficile de suivre un cadre de pré-publication en évolution rapide, mais nous devons toujours viser la précision lorsque nous parlons avec l'autorité et donnons des conseils!
Trek Glowacki

Cool merci. Mis à jour ma réponse. Je suppose que cela a été introduit dans la grande fusion des relations la semaine dernière. J'ai jeté un coup d'œil et lu les modifications répertoriées, mais je n'ai trouvé aucune mention d'URL et les problèmes que je suivais étaient toujours ouverts lorsque je les ai vérifiés. Merci d'avoir signalé le commit - il peut être difficile à localiser sans déjà connaître son existence.
bengillies

Il s'agit en effet de la récente fusion de la branche amélioration des relations. Nous avons lentement suivi les anciens problèmes et les avons résolus cette semaine.
Trek Glowacki

3

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

En gros, Backbone ne fait pas beaucoup de choses, et c'est pourquoi je l'adore: 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 avec le serveur est l'une des rares choses que Backbone fait, et elle fait un excellent travail avec elle. Je commencerais donc par Backbone, puis j'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 une belle discussion


2
Je vous remercie. Que pouvez-vous dire sur les extensions rets de braise. Mieux utiliser les données ou les ressources? Pouvez-vous donner un exemple simple d'appel api de repos?
Robin Wieruch

1
La réponse courte est que les bibliothèques varient tout le temps et je ne peux pas vous donner de réponse basée sur mon expérience précédente (je l'ai fait moi-même pour évaluation). Je pense que cet article vous en dira plus que je ne peux: stackoverflow.com/questions/8623091/ember-js-rest-api
Nicolas Zozol

1
J'ai déjà vu ce post. C'est pourquoi j'ai demandé :)
Robin Wieruch

2
@NicolasZozol quel podcast? lien ?
deepak

3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas de retour en février. C'est avant qu'il ne devienne plus clair que ces cadres n'existaient pas vraiment dans des arènes qui se chevauchent. Vous pouvez entendre Yehuda et Jeremy se parler, sans vraiment faire de comparaisons.
Trek Glowacki
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.