Backbone vs Ember
smus.com
Backbone vs Ember
1–10 of 42 posts
Re: Backbone vs Ember
#2I would recommend the JS Jabber from this week over this blog post: https://news.ycombinator.com/item?id=3587689
Jeremy & Yehuda touch on most of the issues in this post and you can hear the points directly from their POV rather than filtered through someone else.
Additionally it's interesting to hear that Jeremy & Yehuda are at odds (philosophically) on several other issues which I think help to round out the ideas behind Backbone, Ember, and other projects both of them are involved in.
Re: Backbone vs Ember
#3I'm particularly interested – if anyone has experience using Ember – about the concerns raised about Ember's performance with large amounts of data and "hairy custom view situations," as borismus puts it. Is Ember actually going to be slow when dealing with large data sets?
Re: Backbone vs Ember
#4We're using both Ember and Backbone here at Square. Backbone has proven useful for small apps (https://squareup.com/retail) while Ember is an effective replacement for Rails when it's backed by a good JSON api.
Re: Backbone vs Ember
#5Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine.
> Backbone by itself is not sufficient for building complex web apps.
SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#application-slider
Backbone.js (1.5 years worth of apps, just plain 'ol open source): http://backbonejs.org/#examples
'nuff said.
Re: Backbone vs Ember
#6Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine. > Backbone by itself is not sufficient for building complex web apps. That bit is particularly galling ... It's one thing to opine about stated philosophy, and another thing to really look at how the rubber hits the road. SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#appli…
Bro come on :(
Ember is a total, ground-up rewrite of some of SproutCore's ideas and you know it. I don't count any SproutCore examples as Ember examples, and saying that Ember is anything other than plain 'ol open source is unfair.
I don't count the time you spent on Backbone at DocumentCloud against Backbone's open source, because it would be ridiculous to do so, and you shouldn't count time spent at Tilde working on Ember (mostly on our free time) against Ember being open source.
Our largest contributor (according to https://github.com/emberjs/ember.js/contributors, Peter Wagenet) has done almost all of his work on his free time, and we have a wide variety of contributors who were never on the payroll of this so-called "major corporate backing".
There's a lot that you validly disagree with about our approach, but trying to attack us for being "not real Open Source" is a low blow.
Re: Backbone vs Ember
#7Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine. > Backbone by itself is not sufficient for building complex web apps. That bit is particularly galling ... It's one thing to opine about stated philosophy, and another thing to really look at how the rubber hits the road. SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#appli…
Bro come on :(
Ember is a total, ground-up rewrite of some of SproutCore's ideas and you know it. I don't count any SproutCore examples as Ember examples, and saying that Ember is anything other than plain 'ol open source is unfair.
I don't count the time you spent on Backbone at DocumentCloud against Backbone's open source, because it would be ridiculous to do so, and you shouldn't count time spent at Tilde working on Ember (mostly on our free time) against Ember being open source.
Our largest contributor (according to https://github.com/emberjs/ember.js/contributors, Peter Wagenet) has done almost all of his work on his free time, and we have a wide variety of contributors who were never on the payroll of this so-called "major corporate backing".
There's a lot that you validly disagree with about our approach, but trying to attack us for being "not real Open Source" is a low blow.
Re: Backbone vs Ember
#8Just thought I'd throw out SmartClient here:
It's an example of what you get when you follow the "framework does everything but the kitchen sink" philosophy to the end and pile on feature after feature. (It's open source, too!) It's great if you need to hack together a "enterprisey" client and don't really care about style or extendability (rare but these requirements happen.)
The databinding support, controls, and the amount of stuff it does out of the box is absolutely incredible for a free open source framework. But, it's ugly as hell, bloated, and if you want to do anything off the beaten path, you're fucked. But it's a remarkable piece of engineering that goes under the radar (similar to OpenLaszlo) but also a cautionary tale for the Ember guys to not take it too far.
Re: Backbone vs Ember
#9Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine. > Backbone by itself is not sufficient for building complex web apps. That bit is particularly galling ... It's one thing to opine about stated philosophy, and another thing to really look at how the rubber hits the road. SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#appli…
Bro come on :( Ember is a total, ground-up rewrite of some of SproutCore's ideas and you know it. I don't count any SproutCore examples as Ember examples, and saying that Ember is anything other than plain 'ol open source is unfair. I don't count the time you spent on Backbone at DocumentCloud against Backbone's open source, because it would be ridiculous to do so, and you shouldn't count time spent at Tilde working…
Apologies -- since the article was treating SproutCore+Ember as a single continuous entity, I was blurring the same line -- and thinking of the Apple and Strobe years... I'll try to keep the blows above the belt ;)
But, I do think that looking at the empirical -- what's been built with 'em, and how -- is one of the most useful points of comparison.
Re: Backbone vs Ember
#10I'm particularly interested – if anyone has experience using Ember – about the concerns raised about Ember's performance with large amounts of data and "hairy custom view situations," as borismus puts it. Is Ember actually going to be slow when dealing with large data sets?
There are some pretty legitimate concerns with Ember and large data sets right now as the treatment of those datasets tends to be fairly naive and linear. There are several people, myself included, who are working on ways to address that problem--but modifying a large collection, at the moment, can trigger the entire collection to re-render which can be extremely expensive.
FWIW, I'm not an expert on Ember.js or Backbone; just someone trying his hand at hacking the Ember.js code to work more effectively with collections (since some of the use cases I have would be impossible using the current methods of bindings and collections).