Those in that situation should probably start by optimizing the whole "frequently loaded" part... by not frequently loading it. Then they would realize this shaving of a few hundred bytes here and there is, indeed, micro-optimization.
No, it doesn't. Size of application can correlate strongly with complexity and thus number of queries to the server, but there is nothing that dictates a 1.44MB+ HTML5 application ever even touches a server.
The suggested options, if I comprehend you properly, are A) Stick with the version you originally programmed against and B) Analyze the overall diff between versions if upgrading.
New features/improvements provide an incentive to not choose Option A. With regard to Option B: Although Backbone may be compact and easy to comprehend, the code calling it is much larger. Analyzing Backbone's changes and factoring in all code that calls it is a difficult and error prone process - laregly due to the dynamic nature of the language and lack of tooling for refactoring.
Two changes that bit us from 0.9.2->0.9.10 were model.set no longer accepting a model and, instead, requiring model.attributes (not a big deal, as it threw an exception and was immediately noticeable). The second issue, with collection.fetch, was a silent failure (I forget the exact issue, but the solution was providing two options, perhaps reset/update/add). Neither of these were documented in the changelogs.
It's not so much an issue of patching these breaking changes as it is knowing about them. Perhaps the ultimate issue here is our lack of adequate testing.
One of my co-workers comes from a strong server side MVC background; dealing with Backbone has confused him greatly as to the terminology and separation of concerns.
The break-through explanation I gave him is that Backbone views are DOM elements that are code-backed and adhere to OOP principles. They have constructors, properties, methods, etc. Ultimately, though, they are DOM elements. They can derive their content from templates, but they're still just code-backed DOM elements.
They sometimes behave as smart elements.. and sometimes they behave as controllers. Sometimes, depending on necessity, views get rendered and added to the DOM without templates at all (thus the nicety of tagName and attributes). Sometimes views necessitate a template because the result of the view is less dynamic, or merely appends more dynamic views and places them within placeholders in the template.
Point being.. They're not called controllers because they aren't controllers. They can behave as controllers, but... they're still not strictly controllers. The templates aren't called views because, although the UI is a result of the templates, they aren't always the sole source of the UI.
Backbone indeed lacks clear naming conventions if we are to stuff it in to an existing paradigm, but I have no need to do that - and I don't think you should try it either.
JQuery Mobile is horrible for mobile applications, IMO.
The intrinsic stylesheet, with its rounded corners, box shadows and text shadows results in extremely poor rendering performance in mobile browsers. This can be rectified with work, but it demonstrates to me that their contributors are not at all concerned with performance. Its markup is node heavy (a single LI turns in to 5 elements). Considerations are made for desktop browsers, yet it is proselytized as a mobile framework.
Developing with it is cumbersome; the selectors you thought would work do not, because your element has been munged and wrapped with numerous other elements. Triggering "create" more than once sometimes wraps elements a second time because some widgets don't check their classes properly to know they've already been marked up. The only way to know the widget has been created is either checking for known classes or attempting to access one of its methods in a try/catch.
Some widgets respond to "refresh" - some don't. Some parts of widgets respond to it, some don't. This makes partial view updates almost, or completely, impossible. I have been slowly replacing JQM's functionality with backbone views and it is working much, much better.
If you use jQuery Mobile in your mobile application, I advise you do so with an exit strategy in mind.