 |
 |
> 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