Ember.js Live Collections | Hacker News Reader

Ember.js Live Collections

awardwinningfjords.com

75 pointswycats21 comments

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?

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.

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.

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.

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

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."

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.

    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 :)

I find Knockout interesting in this respect exactly because it's not monolithic. It exposes some primitives (observables, computed observables, and binding handlers) and you decide how the application is structured. I'm not against a more frameworky approach, but I think it's smart to let the conventions evolve first.

Backbone happens to be a single script, and is monolithic in that sense ... but really, it's just a library that provides "specific functionality".

There are many sites that just use Backbone Models, or just Views, or just the Router, all in isolation. Some use the Models on the server-side ... some use the Views in conjunction with Handlebars.js, or jQuery.tmpl, or Eco, or what have you.

I encourage you to browse the list of example sites -- there's really a huge variety of uses you can observe: http://backbonejs.org/#examples

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)

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

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?

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 :)

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?

it might have been this: https://github.com/bruth/synapse

Docs: http://bruth.github.com/synapse/docs/

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

Source: https://github.com/bruth/synapse/blob/master/src/synapse.cof...

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.

Unfortunately, halayli's quite right here. You can, (and probably should) write the Backbone version of this in precisely the same way that Thomas does in his article.

There's a nice pattern here for checking ids for presence before adding new models, but nothing inherently Ember or Backbone about it.

I've only played with Backbone a little, but I was under the impression that one thing Ember and Knockout offered over Backbone was the built-in automatic binding to perform UI updates, which required a bit of custom code (albeit pretty short) to update the views. Or did I miss something in Backbone?

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?

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.

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

Reply on news.ycombinator.com