4 ms·

It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change.

by rxcfc 14y ago

It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change. However, I've known multiple developers who started with Backbone and then found that it wasn't able to meet their needs and then switched to Ember. Zendesk is one such example. The goals of Ember are actually very different from Backbone. Furthermore, living on the bleeding edge with others is better than living on your own bleeding edge by yourself with a ton of code that you rolled on your own.

lobster_johnson 14y ago
Oh, sure. Changing libraries/frameworks in order to satisfy one's requirements -- or for quality reasons, or for any other good reasn -- is completely justified. It's the habit of chasing whatever is today's new hot thing that I dislike, and similarly, the habit of dismissing yesterday's favourite as being old hat. As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs. What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down. Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.
- rxcfc 14y ago
  This talk I gave last year describes some of the problems that Ember attempts to address that libraries like Backbone don't: http://vimeo.com/49434697 http://vimeo.com/49434697
  - lobster_johnson 14y ago
    Thanks. I don't have time to watch the talk right now, but skimming through it, it sounds like a view layer like you describe could perceivably be bolted on top of Backbone, at least if one added support for attribute-level bindings?
deleted 14y ago
[deleted]

by rxcfc 14y ago

lobster_johnson 14y ago

Oh, sure. Changing libraries/frameworks in order to satisfy one's requirements -- or for quality reasons, or for any other good reasn -- is completely justified. It's the habit of chasing whatever is today's new hot thing that I dislike, and similarly, the habit of dismissing yesterday's favourite as being old hat. As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs. What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down. Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.

rxcfc 14y ago
This talk I gave last year describes some of the problems that Ember attempts to address that libraries like Backbone don't: http://vimeo.com/49434697 http://vimeo.com/49434697
- lobster_johnson 14y ago
  Thanks. I don't have time to watch the talk right now, but skimming through it, it sounds like a view layer like you describe could perceivably be bolted on top of Backbone, at least if one added support for attribute-level bindings?

deleted 14y ago

[deleted]