Guh. 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.
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.
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.
> ... as the year progresses, hope to compare favorably
> to Backbone's impressive list.
I'm very much looking forward to seeing them. The more different takes on JS-heavy apps the better.
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:
... 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?
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.
> Backbone by itself is not sufficient for building complex web apps.
What he meant was that for any complex web apps built on backbone.js, you have to build a layer on top of it or use additional plugins. You won't build complex applications as is.
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.
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?
(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.
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.