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