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.
We're talking about static files, right? If you're trying to scale those should be nowhere near your application server. They get served from a CDN and the size is completely irrelevant to technical scaling issues.
Money is easy. It's not part of the difficulty of scaling. 1000x the static traffic means 1000x the bandwidth heading to simple, independent, easy to load balance servers. Difficulty added per user: zero. Cost per user: the same or less.
There are many reasons to want small files, but scaling isn't one of them.
A one time cost in a universe where your app never changes, CDNs cost nothing, and browsers have perfect caches, and everyone ubiquitously uses the localstorage and app-cache html5 apis.
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.
That's a very good question. Depending on the severity of the change, and the popularity of the feature being changed, we'll probably start to explicitly deprecate some things. One (potential) example might be the use of `{silent: true}` to prevent events from being fired.
But that said, the nature of a "breaking change" in Backbone is much less severe than in most open-source libraries. All released versions are published on GitHub, and you can use any version you see fit at any time. In addition, because the codebase is so compact, broken into atomic functions, and thoroughly commented -- it's really easy to patch to suit your own needs, should you find something you need to change without waiting for us to push a new release.
I haven't heard of anyone having a problem yet with a feature that was changed, where one of the above approaches didn't work out.
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.
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.
