Hacker News Reader

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.

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

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

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.