I'm not sure exactly how you're counting, but I think the original breaks down to:
* 3 lines of "data"
* 8 lines of boilerplate
* 5 lines of logic
That's less logic to understand, less data to understand, and much less boilerplate to mentally filter out (which does require effort even you're familiar with it.)
A more complex example would probably involve more form controls being submitted to the service and more elements being updated in the response. Neither of these are likely to change the data or boilerplate line count of the original example, and they don't necessarily have to change the logic much either:
data: $('#new-status').serialize() suffices to gather all of the form data in one statement no matter how many controls there are (in a real app your service will probably need most/all of them for validation/context, and a more specific selector can be used to just gather some elements).
When I want to update the display based on my service response, I typically return new markup as one element of my json response. So, my success method is something like $("#status").html(data.markup), once I check data.status to make sure I had a successful response rather than an error. This can be extended to multiple elements by returning a list of id/markup pairs, or going all the way to a jsonp response. Now, this does mean that I'm doing my templating on the server instead of in the browser, but I happen to prefer that because it makes it easier for me to support non-javascript browsers and different templates for different devices. (I try to auto-detect, but also allow the user to override and choose which view they want.)
To be honest I haven't looked very deeply at the example. However, I recently started working on a backbone project and while it's definitely overkill for basic stuff, if your data visualizations and paths become more complex then it definitely helps you make sense of all the stuff going on.
Also, a custom solution is good and might possibly work better and be smaller/more-efficient/etc. However, the one benefit of frameworks that's often overlooked is the fact that other people might work on the same thing.
If I, as developer X work on a project and develop it in backbone then it's likely that developer Y (a backbone developer) can come in and continue working on it. However, if I were to write a custom solution it could take developer Y a while to get into it.
For example, I can picture how complex the Google Analytics dashboard code must be. If google invited me to work on it, I would have to learn whatever it is that they use to do stuff like that. If it used backbone, I would probably pick it up faster. Just an example.
But as code bases get larger, structure becomes really important. I think that's really where backbone comes in. Your points are of-course valid too, just wanted to share :)
You are bringing up a valid point. Doug is saying that I should not use Backbone but instead create my own code structure and organization... but that's the thing. I don't want to reinvent the wheel. I want to use something proven. And yes I have tried structuring a 100% javascript application and I don't like the way it turned out. If someone wants to criticize backbone that is fine, but I want to see an alternative suggested other than 'roll your own.'
The criticism here would probably apply to any other framework in the same space - the alternative way to solve those problems can only be described in guiding principles - otherwise he'd be incurring in the same mistake he is criticizing, by giving you another framework...
A more complex example would probably involve more form controls being submitted to the service and more elements being updated in the response. Neither of these are likely to change the data or boilerplate line count of the original example, and they don't necessarily have to change the logic much either:
data: $('#new-status').serialize() suffices to gather all of the form data in one statement no matter how many controls there are (in a real app your service will probably need most/all of them for validation/context, and a more specific selector can be used to just gather some elements).
When I want to update the display based on my service response, I typically return new markup as one element of my json response. So, my success method is something like $("#status").html(data.markup), once I check data.status to make sure I had a successful response rather than an error. This can be extended to multiple elements by returning a list of id/markup pairs, or going all the way to a jsonp response. Now, this does mean that I'm doing my templating on the server instead of in the browser, but I happen to prefer that because it makes it easier for me to support non-javascript browsers and different templates for different devices. (I try to auto-detect, but also allow the user to override and choose which view they want.)