 |
 |
On Tue, Dec 6, 2011 at 3:40 PM, Doran, Michael D <[log in to unmask]> wrote: > > > Current trends certainly go in the opposite direction, look at jQuery > > Mobile. > > I agree that jQuery Mobile is very popular now. However, that in no way > negates the caution. One could consider it as a "tragedy of the commons" > in which a user's iPhone battery is the shared resource. Why should I as a > developer (rationally consulting my own self-interest) conserve battery > power that doesn't belong to me, just so some other developer's app can use > that resource? I'm just playing the devil's advocate here. ;-) > > You're taking it as given that the use of JavaScript on a mobile device is significantly less energy-efficient than an approach that would exercise only the HTML parsing path. Be careful here, intuition can be misleading. Devices cannot send HTML to their displays. It takes energy to parse it, and energy to render it. Time is roughly proportional to energy. Where do you think most time/energy is spent in? (page-provided) JavaScript execution, HTML parsing, or page layout/rendering? Based on the information I have available to me (I'd appreciate pointers to other studies), JS execution does not dominate - it ranks last behind Page layout and rendering [1], even for sites that are JS heavy, such as webmail sites. Interestingly, a large part of that is evaluating CSS selectors. On a related note, let me point out that there are many ways to change the DOM on the client. Client-side templating frameworks such as knockout.js or jQuery tmpl produce HTML (which then must be parsed), but modern AJAX frameworks such as ZK don't produce any HTML at all, skipping parsing altogether. I meant to add another reason why at this point teaching newbies an AJAX style that relies on HTML-returning entry points is a really bad idea, and that is the move from read-only applications (like Nate's) to applications that actually update state on the server. In this case, multiple parts of the client page (perhaps a label here, a link there) need to be updated. Expressing this in HTML is cumbersome, to say the least. (As an aside, I note that AJAX frameworks such as ZK, which pursued the HTML approach in their first iterations, have moved away from it. Compare the client/server traffic on a ZK 3.x application to the one in a ZK 5. app to see this.) For those interested in how to use one of possible client-side approaches I'm suggesting, I prototyped Nate's application using only client-side templating: http://libx.lib.vt.edu/services/popsubjects/cs/ It uses knockout.js's data binding facilities as well as (due to qTip 1.0's design) the jQuery tmpl engine. Read the (small, self-contained) source to learn about the server-side entry points. (I should point out that in this case, the need for the book cover ISBNs to be retrieved remotely is somewhat contrived; they should probably be sent along with the page in the first place.) A side effect of this JSON-oriented design is that it results in 2 nice JSON-P web services that can be embedded/used in other pages/applications. - Godmar [1] http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/login.pdf