Isnt that the reason developers choose libraries like Backbone, Ember, Knockout, et al.? I think most web developers have realized that code spaghetti

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