

Ember.js Live Collections - wycats
http://awardwinningfjords.com/2011/12/27/emberjs-collections.html

======
moe
_Assuming that Bocoup simply chose Backbone.js for familiarity's sake_

The tone of this post seems a bit dishonest.

There are plenty obvious reasons for not choosing Ember today: It's young,
it's not production-ready, it's undocumented.

In that light I don't think you can reasonably expect anyone who's not a
former SproutCore-user to choose Ember over Backbone today.

Case in point: The docs don't even mention the Em.ArrayController that your
example builds on. How is anyone without prior SproutCore-knowledge supposed
to discover it?

~~~
sbarre
Well, to your point: I wasn't a Sproutcore user before, and I've read lots of
articles on Backbone over the last 3-4 months, and tried to get it working a
few times for my projects, without much luck.

That said, I'm not an expert Javascript developer, so maybe I just didn't
understand it, or try hard enough. The following story is mine, so YMMV.

Then I saw Ember.js and the Handlebars bindings made simple sense to me, so I
cloned the repo, and started playing around with it.

Sure it's not documented but I know how to load the uncompressed source tree
in Textmate and look around. The source code itself is very well commented and
contains inline examples (although some of them are still Sproutcore-centric,
but s/SC/Ember/ and you're mostly good).

I read through the examples, I tinkered, and within a few hours, I had a semi-
working version of my project.

So yeah it's young and undocumented, but if anything the ease with which I was
able to get up and running on it says a lot for its future potential.

------
jashkenas
I was catching a bit of the twitter back-and-forth this afternoon:

<http://bettween.com/ireneros/tdreyno/>

... and was a bit disappointed by the level of discussion.

"Live Collections", such as they are, have nothing to do with Backbone.js and
Ember.js intrinsically -- and indeed, you probably can, and should, implement
it in Backbone exactly as Thomas does in this article.

In other words, if you're looking for anything Backbone or Ember specific,
there's nothing to see here -- both libraries support this idiom (Ajax some
data, check for ids, add if not already present) in precisely the same way.

~~~
tdreyno
I was actually trying my hardest to present it as a technique worth being
aware of rather than specific to one framework or another.

Totally agree. I use both frameworks for work and posted my article because
Rick Waldron asked me too as penance for a bit too much snark on my behalf.

------
daleharvey
I experimented with backbone and ember recently, the integration with
handlebars to do in place updates and the quite comprehensive observer /
bindings mechanisms in ember look powerful and definitely needed for more
complex applications

Backbone seemed to provide everything needed for reasonably simple one page
javascript apps

But both seemed to suffer the same problem, they are quite monolithic,
everything is build around the fact your app is a 'backbone' or an 'ember'
application, they arent just libraries that provide specific functionality.

They both seemed to miss out really basic functionality that I run into all
the time building these type of applications, the example here shows one of
the problems, when I am not looking at the recent tweets, I dont want to be
polling the data source, I havent seen a good example in either of how to
properly setup and tear down views, I came up with something incredibly simple
that helps, I will try and blog about it soon.

Also I find the general tone of the article pretty rude and condescending

~~~
tomdale
_But both seemed to suffer the same problem, they are quite monolithic,
everything is build around the fact your app is a 'backbone' or an 'ember'
application, they arent just libraries that provide specific functionality._

Isn't that the reason developers choose libraries like Backbone, Ember,
Knockout, et al.? I think most web developers have realized that code
spaghetti doesn't scale very well. Part of the reason the iOS ecosystem is so
vibrant is because Cocoa is just as opinionated about architecture as it is
about "specific functionality."

 _They both seemed to miss out really basic functionality that I run into all
the time building these type of applications, the example here shows one of
the problems, when I am not looking at the recent tweets, I dont want to be
polling the data source, I havent seen a good example in either of how to
properly setup and tear down views, I came up with something incredibly simple
that helps, I will try and blog about it soon._

I'd love to read your blog post. In my opinion, it sounds like you might be
approaching the problem from the wrong direction. Views being in charge of
when the server is polled is a layering violation. Instead, I'd have a
controller that is in charge of knowing when a given view is rendered to the
screen. When it is, it tells the model layer to start polling. When it hides
the view, it turns off the polling.

 _Also I find the general tone of the article pretty rude and condescending._

Thomas is an incredibly nice guy and has experience with many different MVC
frameworks. I'm sorry the post came off this way to you, but it didn't to me.
Personally, I think Backbone is an incredibly important part of the ecosystem
and am very glad it exists. I think Thomas feels the same way too.

~~~
daleharvey

        Isnt that the reason developers choose libraries like 
        Backbone, Ember, Knockout, et al.? I think most web
        developers have realized that code spaghetti doesn't
        scale very well. Part of the reason the iOS ecosystem 
        is so vibrant is because Cocoa is just as opinionated
        about architecture as it is about specific 
        functionality.'
    

Thats true, and there are definite advantages to building things in that
style, but I am surprised that the more popular of these libraries are all
built in this style, There are also distinct advantages of having loosely
coupled flexible libraries such as jQuery, which is the library for
interfacing with the dom, loosely coupled well integrated components dont
necessarily mean spaghetti code

    
    
        I'd love to read your blog post. In my opinion, it 
        sounds like you might be approaching the problem from 
        the wrong direction. Views being in charge of when the 
        server is polled is a layering violation. Instead, I'd 
        have a controller that is in charge of knowing when a
        given view is rendered to the screen. When it is, it
        tells the model layer to start polling. When it hides 
        the view, it turns off the polling.
    

Sure but the problem doesnt go away when you move it up to the controller, I
havent seen these libraries provide state which determines which controller is
currently active. Of course you can code it yourself, but there are lots of
little cases and functionality which imo libraries could do a better job of
abstracting away. I will write the post asap, I mostly just need a name for my
little micro library :)

------
jurre
This article is using a polling technique, I suggest everyone check out
Pusher[1] or the open source equivalent Slanger[2] that use websockets to
allow you to push these updates from your server.

[1] <http://www.pusher.com/> [2] <https://github.com/stevegraham/slanger>

(ps: not affiliated with either of those, they're just awesome pieces of
technology that I see as the future of the web)

------
halayli
Nothing is this article demonstrates a feature that doesn't exist in
backbone.js. In fact, backbone.js feels much cleaner.

~~~
tomdale
The point of Ember.js is to reduce the amount of boilerplate a developer needs
to write to perform common tasks. I think Thomas did a good job of explaining
how you can accomplish the same thing in Ember.js with fewer lines of code
(and remember–less code, fewer bugs!)

I'm curious: what about the Backbone version feels "cleaner" to you?

~~~
halayli
My point was that the sample code didn't show Ember's strong features like
computed properties and auto binding. The backbone version will be more or
less the same size for this kind of demo.

as for the cleaner part, I didn't like the fact that I need to call _super().

On the other hand I really like .property and .observe in Ember.js :)

~~~
drivebyacct2
That's been my armchair analysis of this. I was set to go on vacation, but it
looks like I may scrap that and write a new frontend for our application and
I'm trying to narrow it down between Ember and Backbone. I'd found something
yesterday that would give you the KO style observables in a light standalone
library, though the name escapes me now. Maybe it+Backbone.js is the most
versatile?

~~~
ryankshaw
it might have been this: <https://github.com/bruth/synapse>

~~~
oscilloscope
Docs: <http://bruth.github.com/synapse/docs/>

Demo: <http://jsfiddle.net/bruth/bufeK/>

Source:
[https://github.com/bruth/synapse/blob/master/src/synapse.cof...](https://github.com/bruth/synapse/blob/master/src/synapse.coffee)

Synapse is an elegant API for data binding. Subjects and observers clarify
many issues for data-flow interfaces.

The boilerplate in Backbone shrinks significantly when expressed with
CoffeeScript. Synapse's source is expressive, well-documented and only ~200
lines.

------
nopal
The author mentions Facebook, but from my observations, it seems as if
Facebook is much more real-time.

Does anyone know how Facebook is doing their live-updating? Are they using
polling a la Ember.js, or are they doing something along the lines of Web
Sockets/long polling?

~~~
jurre
I _think_ they're using polling for everything but the chat. I base this
solely on how Facebook behaves, theres usually some delay in the updates and
such and I believe a lot of things require mouse movement.

------
gojomo
Would be neat to mix this with an animated list-insert/resort, like David
DeSandro's 'Isotope'.

