> It's certainly true that limited energy motivates the need to minimize
> client processing, but the conclusion that this then means server
> generation of static HTML is not clear.

I'm not sure anyone was drawing that conclusion. It was offered up as factor to consider.
 
> 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. ;-) 

-- Michael

[1]	A dilemma arising from the situation in which multiple 
	individuals, acting independently and rationally consulting 
	their own self-interest, will ultimately deplete a shared 
	limited resource, even when it is clear that it is not in 
	anyone's long-term interest for this to happen.

	http://en.wikipedia.org/wiki/Tragedy_of_the_commons


> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Godmar Back
> Sent: Tuesday, December 06, 2011 12:43 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] jQuery Ajax request to update a PHP variable
> 
> On Tue, Dec 6, 2011 at 11:22 AM, Doran, Michael D <[log in to unmask]> wrote:
> 
> > > You had earlier asked the question whether to do things client or
> server
> > > side - well in this example, the correct answer is to do it client-
> side.
> > > (Yours is a read-only application, where none of the advantages of
> > > server-side processing applies.)
> >
> > One thing to take into consideration when weighing the advantages of
> > server-side vs. client-side processing, is whether the web app is likely
> to
> > be used on mobile devices.  Douglas Crockford, speaking about the fact
> that
> > JavaScript has become the de fact universal runtime, cautions: "Which I
> > think puts even more pressure on getting JavaScript to go fast.
> > Particularly as we're now going into mobile. Moore's Law doesn't apply to
> > batteries. So how much time we're wasting interpreting stuff really
> matters
> > there. The cycles count."[1]  Personally, I don't know enough to know how
> > significant the impact would be.  However, I understand Douglas Crockford
> > knows a little something about JavaScript and JSON.
> >
> >
> It's certainly true that limited energy motivates the need to minimize
> client processing, but the conclusion that this then means server
> generation of static HTML is not clear.
> 
> Current trends certainly go in the opposite direction, look at jQuery
> Mobile.
> 
>  - Godmar