Very well written tutorial, right up to this part: However, the code has increased from 16 lines to more than 40, so why do I think this is better? Because we

Very well written tutorial, right up to this part: However, the code has increased from 16 lines to more than 40, so why do I think this is better? Because we are now working on a higher level of abstraction. This code is more maintainable, easier to reuse and extend, and easier to test. What I've seen is that Backbone.js helps improve the structure of my JavaScript applications considerably. I don't see any justification for those claims. In my experience, more code means less maintainable, because it's more to understand and provides more opportunities for bugs to creep in. I can look at the original 16 lines and understand immediately what's going on, while the 40 line result doesn't even fit onto my screen all at once, and the application logic is broken up and spread out across a bunch of boilerplate-type code. Regarding reuse and extensibility, I don't see that here either. Sure, you can add more behavior when either element changes, but you could have done that before just as well. For reuse, what's the likely-hood that you're going to need a control like this, which seems to be tightly bound to the application requirements? If you're writing a library or generic control reuse is important, but most of the time most developers are writing custom one-off requirement-specific controls, and reuse just isn't as important as clarity and simplicity. Besides, if you really wanted to reuse the original, you could move it all into a function and pass 'new-status' and 'statuses' as arguments; then any form/textarea/ul triplet can be used as a control. Finally, testability: yes, I'll grant that your final version is more scriptable which makes it easier to write automated tests. However, you've also got a lot more to test, because now your code is subject to bugs in the 1000 lines of Backbone code you've made yourself dependent upon. What if there is some problem in the communication with your service? That's buried in Backbone and you're insulated from it, unlike in the original where $.ajax gives you nearly direct control over all aspects of the communication. The original, being much simpler, is also easier to visually inspect for bugs. Not much can go wrong in 16 lines of tightly integrated code, but once you switch over to inserting bits of behavior into a larger framework that you don't control and probably don't understand, who knows when your code will get executed (or not) and what edge cases might arise? BTW, yes I know jQuery is a much larger and more complex dependency, but both the original and final examples depend on it equally. More importantly, your code calls jQuery rather than jQuery calling your code: your code stays in control. With frameworks like Backbone, your code gives up control to the framework.