21–30 of 42 posts
I don't agree.
The fact is that BB is stable and has loads of documentation and live apps. Ember not so much.
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?
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 Back…
How large is large enough to cause problems?
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. SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#appli…
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?
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
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.
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.
Earlier quoted context omitted.
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 Back…
>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?
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. SproutCore/Ember (5 years worth of apps, major corporate backing): http://sproutcore.com/#appli…
> 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 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.
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?