Backbone vs Ember(smus.com)
smus.com
Backbone vs Ember
http://smus.com/backbone-and-ember
41 comments
I see the difference as something like Django/Sinatra vs Rails. Backbone requires the developer to be more explicit, whereas Ember is more opinionated and performs magic behind the scenes as long as you follow the conventions.
On a practical note, my experience earlier this week suggests Backbone right now is far easier to get your hands dirty with. I was excited to use Ember, but I had a practical time constraint and discovered it's a rough ride right now, so reverted to Backbone for this task. There's really very few examples, unless you want to start diving into older Sproutcore docs and trying to figure out the diffs.
In contrast, Backbone has a wealth of articles and even design patterns and books. Of course, it's an apples-versus-oranges distinction with Ember being so much newer, but an important practical issue for developers to be aware of if they're deciding right now.
On a practical note, my experience earlier this week suggests Backbone right now is far easier to get your hands dirty with. I was excited to use Ember, but I had a practical time constraint and discovered it's a rough ride right now, so reverted to Backbone for this task. There's really very few examples, unless you want to start diving into older Sproutcore docs and trying to figure out the diffs.
In contrast, Backbone has a wealth of articles and even design patterns and books. Of course, it's an apples-versus-oranges distinction with Ember being so much newer, but an important practical issue for developers to be aware of if they're deciding right now.
Ember is definitely an alternative to Backbone, but people should stop conflating Ember with SproutCore: the two frameworks are targeted at completely different types of apps.
FWIW, the SproutCore community has rejected the Ember approach for the kinds of apps SproutCore is meant for: large, desktop-style apps that need to run fast in modern web browsers. The supposed "features" Ember provides, like auto-updating templates, have proven to have such bad performance in existing SproutCore apps that developers have almost universally been ripping them out (this was discovered at the most recent SproutCore User Group last month).
Ember is an alternative to Backbone -- a 600 LOC micro-framework. That should tell you all you need to know about Ember's scope. (SproutCore is well over 20K LOC.)
FWIW, the SproutCore community has rejected the Ember approach for the kinds of apps SproutCore is meant for: large, desktop-style apps that need to run fast in modern web browsers. The supposed "features" Ember provides, like auto-updating templates, have proven to have such bad performance in existing SproutCore apps that developers have almost universally been ripping them out (this was discovered at the most recent SproutCore User Group last month).
Ember is an alternative to Backbone -- a 600 LOC micro-framework. That should tell you all you need to know about Ember's scope. (SproutCore is well over 20K LOC.)
I've been working with Backbone exclusively for the last six months or so, so don't know what other frameworks are doing with nested views. The OP marks this as one of Backbone's shortcomings.
I've been writing my backbone app effectively with nested views, where parent views pass relevant information to child views either through initialization or functions on the child view, while the child view "communicates" with the parent view through events that the PV can bind to.
I kind of like the idea of child views not knowing or caring who created them or why. I do this e.g. with buttons, forms, panels and subpanels, etc.
Is there a good resource for best practices here?
I've been writing my backbone app effectively with nested views, where parent views pass relevant information to child views either through initialization or functions on the child view, while the child view "communicates" with the parent view through events that the PV can bind to.
I kind of like the idea of child views not knowing or caring who created them or why. I do this e.g. with buttons, forms, panels and subpanels, etc.
Is there a good resource for best practices here?
I'll add my voice to those that would like some much better documentation from ember.js. I'm starting to finds some stuff on stack overflow but it has taken a while to find. A few things that would help tremendously when people get started:
-Examples of the built in controls(tab,select,textfield,textarea). There are only like 6 of them but when you find out they exist and are not documented they feel like 600. The sroutcore history amplifies this assumption.
-The fact that sub views(ie textfield) don't bubble but are really easy to implement by extending TextField. See: http://stackoverflow.com/questions/8646238/handling-blur-on-... (PS. Why is this? It seem silly that I can't do {{view Ember.textField change="parentview.change"}} in my views.)
-Examples of the built in controls(tab,select,textfield,textarea). There are only like 6 of them but when you find out they exist and are not documented they feel like 600. The sroutcore history amplifies this assumption.
-The fact that sub views(ie textfield) don't bubble but are really easy to implement by extending TextField. See: http://stackoverflow.com/questions/8646238/handling-blur-on-... (PS. Why is this? It seem silly that I can't do {{view Ember.textField change="parentview.change"}} in my views.)
I 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.
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.
I'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?
Well, I can tell you about SproutCore developer's experiences with Ember's views: they're ripping them out of their apps.
About 10 months ago, Strobe was trumpeting the "Ember" model for views (auto-updating templates, heavy nesting, bindings everywhere) and a lot of SproutCore developers began to use it.
The bloom is definitely off of that rose. At the latest user group meeting three weeks ago, many developers spoke up about having to remove all of their template view code because the performance was absolutely terrible.
At this point, "Ember-style" template views have been relegated to a separate opt-in library, are only being recommend for lightweight read-only data, and the recommendation for developers to use them is being removed from SproutCore's documentation.
About 10 months ago, Strobe was trumpeting the "Ember" model for views (auto-updating templates, heavy nesting, bindings everywhere) and a lot of SproutCore developers began to use it.
The bloom is definitely off of that rose. At the latest user group meeting three weeks ago, many developers spoke up about having to remove all of their template view code because the performance was absolutely terrible.
At this point, "Ember-style" template views have been relegated to a separate opt-in library, are only being recommend for lightweight read-only data, and the recommendation for developers to use them is being removed from SproutCore's documentation.
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).
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).
>modifying a large collection, at the moment, can trigger the entire collection to re-render which can be extremely expensive.
How large is large enough to cause problems?
How large is large enough to cause problems?
It really depends on your environment and the complexity of the rendering tied to your collection. For example, on a fast desktop-class system with a collection that renders one element with 1 property, you can probably have hundreds (or maybe even thousands) of items in the collection before you start to notice slowdowns when the collections update. Working on lower-end and mobile platforms, those numbers change. Similarly, if you rendering is complex, it will take more time as well. All that said, there's really no "magic number"
There are definite workarounds such as setting up paging--but the simple approach of using Ember.js bindings to bind a collection to a template will fall to pieces as that collection grows.
There are definite workarounds such as setting up paging--but the simple approach of using Ember.js bindings to bind a collection to a template will fall to pieces as that collection grows.
We'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.
What do you build your JSON api with? I've been using rails against large javascript applications. It seems like ember.js is a good match against rails (especially with https://github.com/emberjs/data)
Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine.
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.
> 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.
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.
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.
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.
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.
I absolutely agree that comparing actual apps is a very useful point of comparison.
Ember itself is actually relatively new. The fact that Ember inherited some of its runtime semantics from SproutCore might give the mistaken impression that there is shared code. Everything, including Ember's runtime, was rewritten from the ground up for Ember, and it's only with the release of Ember 0.9 that I consider the APIs and codebase stable.
Some companies, like ZenDesk, hopped onboard earlier in 2011, while the codebase and APIs were still undergoing a lot of churn, and helped flesh things out. That said, when taking the scope of Ember into consideration, Ember's adoption curve is behind's Backbone's, so it's not surprising that there are many more impressive Backbone apps in the wild.
We're proud of many of the apps that people are building with Ember today, and as the year progresses, hope to compare favorably to Backbone's impressive list.
Ember itself is actually relatively new. The fact that Ember inherited some of its runtime semantics from SproutCore might give the mistaken impression that there is shared code. Everything, including Ember's runtime, was rewritten from the ground up for Ember, and it's only with the release of Ember 0.9 that I consider the APIs and codebase stable.
Some companies, like ZenDesk, hopped onboard earlier in 2011, while the codebase and APIs were still undergoing a lot of churn, and helped flesh things out. That said, when taking the scope of Ember into consideration, Ember's adoption curve is behind's Backbone's, so it's not surprising that there are many more impressive Backbone apps in the wild.
We're proud of many of the apps that people are building with Ember today, and as the year progresses, hope to compare favorably to Backbone's impressive list.
> ... as the year progresses, hope to compare favorably
> to Backbone's impressive list.
I'm about to crash, but would you mind expanding on what you've written here -- "rewritten from the ground up", and so on -- in relation to earlier posts like this one:
http://blog.sproutcore.com/sproutcore-amber-a-report-by-yehu...
... which describe what I've always understood to be the heart of Ember as an iteration on the core SproutCore internals. Does that blog post no longer describe what ended up happening to Project Amber?
Can't we all just get along...
I've been working with Backbone intensively since V0.1, and though I've very scarcely looked at ember, I've been following the heated discussions on both sides. Personally, I think it's damaging to both your publicizing efforts.
Perhaps what would be more beneficial is a more complex hello world app than the todo list. One that expresses the flexibility of Backbone's minimalism, along with the larger out-of-the-box functionality of Ember. I'm personally in the Backbone camp, but it would be easier to let the user decide what is best for him/her.
I've been working with Backbone intensively since V0.1, and though I've very scarcely looked at ember, I've been following the heated discussions on both sides. Personally, I think it's damaging to both your publicizing efforts.
Perhaps what would be more beneficial is a more complex hello world app than the todo list. One that expresses the flexibility of Backbone's minimalism, along with the larger out-of-the-box functionality of Ember. I'm personally in the Backbone camp, but it would be easier to let the user decide what is best for him/her.
On the contrary, I've found the discourse between Jeremy and Yehuda vigorous, respectful, and edifying. In my opinion, these are the best kinds of technical discussions; they are like a rock tumbler that wears away at our solutions until we're left with shiny best practices--and can move on to the next big problem to solve.
> I've been following the heated discussions on both sides. Personally, I think it's damaging to both your publicizing efforts.
Actually, it probably helps both publicizing efforts. As the Internet-wide debate becomes "Backbone vs Ember," it puts the focus on those two techs and leaves other competitors out of the conversation.
Actually, it probably helps both publicizing efforts. As the Internet-wide debate becomes "Backbone vs Ember," it puts the focus on those two techs and leaves other competitors out of the conversation.
> Backbone by itself is not sufficient for building complex web apps.
IMHO, I consider backbone.js more as a base framework which you need to enhance before starting your project. So, in a way, every complex backbone.js app is more of a <Complete new framework> extending Backbone.js.
A proof of that is mostly the number of available plugins (which is great!!). As a matter of fact, ender could be written on top of backbone.
Yes. A very good clarification, and I would tend to agree
Backbone is like 600 lines apparently. Of course more apps are going to be built using it, it's like including a snippet of code. What I'm interested in is how much more has to be built on top of those 600 lines of boilerplate to make each of those applications.
Correct me if I'm wrong, but... Backbone is great, but it's also just 600 lines of code aimed at addressing the things every single web app needs, right?
A complex web app, pretty much by definition is going to need some features that other web apps aren't going to need, not so? And those features are, according to the stated goals of Backbone, not going to be found in the core, right? (In fact, I seem to recall people asking for features their particular complex web app needed, and being told that stuff didn't belong in Backbone core...)
Boris' seems to be re-stating Backbones' mission statement, which I don't see being a knock on Backbone at all. And I'm really not sure what a list of people using Backbone is meant to prove. Boris is saying that any of those people using Backbone for complex apps will have to extend it a bit - which is one reason Backbone is made to be so easily extendable. Is that wrong?
A complex web app, pretty much by definition is going to need some features that other web apps aren't going to need, not so? And those features are, according to the stated goals of Backbone, not going to be found in the core, right? (In fact, I seem to recall people asking for features their particular complex web app needed, and being told that stuff didn't belong in Backbone core...)
Boris' seems to be re-stating Backbones' mission statement, which I don't see being a knock on Backbone at all. And I'm really not sure what a list of people using Backbone is meant to prove. Boris is saying that any of those people using Backbone for complex apps will have to extend it a bit - which is one reason Backbone is made to be so easily extendable. Is that wrong?
(reposted from blog): I don't see how the claim that "Backbone by itself is not sufficient for building complex web apps" is controversial. There is a clear need to go beyond the functionality provided by Backbone, as evidenced by the popularity of great projects like Tim's Backbone boilerplate and layout-manager.
Just thought I'd throw out SmartClient here:
http://www.smartclient.com/
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.
http://www.smartclient.com/
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.
Hey, Ember.js maintainer here--
Luckily, providing a widget library is, and will always be, outside the scope of Ember.js. While we'd be quite pleased to see someone else develop a widget library on top of Ember, it's not something that we're personally interested in doing.
The goal of Ember.js is to roll up common patterns web developers are using into the framework so that they can write less boilerplate. In fact, part of the reason we renamed SproutCore 2.0 to Ember.js was to emphasize the point that our value proposition is in the architecture, not the library of controls.
As a veteran of the SproutCore project, keeping things lean and focused is my top priority. And, if it helps, we're all extremely allergic to anything that feels "enterprisey." :P
Luckily, providing a widget library is, and will always be, outside the scope of Ember.js. While we'd be quite pleased to see someone else develop a widget library on top of Ember, it's not something that we're personally interested in doing.
The goal of Ember.js is to roll up common patterns web developers are using into the framework so that they can write less boilerplate. In fact, part of the reason we renamed SproutCore 2.0 to Ember.js was to emphasize the point that our value proposition is in the architecture, not the library of controls.
As a veteran of the SproutCore project, keeping things lean and focused is my top priority. And, if it helps, we're all extremely allergic to anything that feels "enterprisey." :P
Boris, I dont know if it happens only to me, but your blog is badly rendered on my Chromium (Linux Mint): many many words are overlapped (like all the paragraph "I like..." under your photo). Everything seems fine in Firefox, I'll try with Chrome on Windows at work.
Edit: Chrome on Windows is ok, maybe there's something wrong on my Linux installation
Edit: Chrome on Windows is ok, maybe there's something wrong on my Linux installation
In my experience, there's very much a need for a controller when writing even
moderately complex apps. You're presented with several options:
1. Write controller code in views
2. Write controller code in models
3. Write controller code in a router
4. Write your own controller infrastructure
If you care about separation of concerns, none of these options are really
acceptable.
Over the past few weeks I've seen a number of Ember evangelists making claims about BB as 'hard to use' or 'suitable for small apps'.
I don't agree.
The fact is that BB is stable and has loads of documentation and live apps. Ember not so much.
I don't agree.
The fact is that BB is stable and has loads of documentation and live apps. Ember not so much.
I love that BB is such a small library. The concise docs at documentcloud plus the source code was all the reference as I needed, even for my first framework-oriented browser app.
I ought to connect with the community more, but so far getting up and running with it (and building a moderately complex app) has been a breeze, as far as Backbone is concerned.
I ought to connect with the community more, but so far getting up and running with it (and building a moderately complex app) has been a breeze, as far as Backbone is concerned.
I have run into this. It’s really frustrating, in Backbone.