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