I'll admit I haven't spent a lot of time investigating/analyzing this particular application -- it's quite possible an all-JS app is the right choice here. 

I was just responding to the suggestion that returning HTML to AJAX was "out of style" and shouldn't be done anymore; with the implication I picked up that (nearly) ALL apps should be almost all JS, use JS templating engines, etc., that this is the "right" "new" way to write web apps.  I think this sends the wrong message to newbies. 

It's true that it is very trendy these days to write all JS apps, which if they function at all without JS do so with a completely seperate codepath (this is NOT "progressive enhancement", although it is a way of ensuring non-JS accessibility).   Yeah, it's trendy, but I think it's frequently (but not always, true)  the wrong choice when it's done.  If you do provide a completely separate codepath for non-JS, this can be harder to maintain than actual progressive enhancement.  And pure JS either way can easily make your app a poor web citizen of the web, harder to screen-scrape or spider, harder to find URLs to link to certain parts of the app, etc.  (eg, http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch ) 

But, sure, maybe in this particular case pure-JS is a good way to go, I haven't spent enough time looking at or thinking about it to have an opinion. Sure, if you've already started down the path of using a JS templating/view-rendering engine, and that's something you/want need to do anyway, you might as well stick to it, I guess.  

I just reacted to the suggestion that doing anything _but_ this is "out of style", or an old bad way of doing things. If writing apps that produce HTML with progressive enhancement is out of style, then I don't want to be fashionable! 
________________________________________
From: Code for Libraries [[log in to unmask]] on behalf of Godmar Back [[log in to unmask]]
Sent: Tuesday, December 06, 2011 9:34 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] jQuery Ajax request to update a PHP variable

On Tue, Dec 6, 2011 at 8:38 AM, Erik Hatcher <[log in to unmask]> wrote:

> I'm with jrock on this one.   But maybe I'm a luddite that didn't get the
> memo either (but I am credited for being one of the instrumental folks in
> the Ajax world, heh - in one or more of the Ajax books out there, us old
> timers called it "remote scripting").
>
>
On the in-jest rhetorical front, I'm wondering if referring to oneself as
oldtimer helps in defending against insinuations that opposing
technological change makes one a defender of the old ;-)

But:


> What I hate hate hate about seeing JSON being returned from a server for
> the browser to generate the view is stuff like:
>
>   string = "<div>" + some_data_from_JSON + "</div>";
>
> That embodies everything that is wrong about Ajax + JSON.
>
>
That's exactly why you use new libraries such as knockout.js, to avoid just
that. Client-side template engines with automatic data-bindings.

Alternatively, AJAX frameworks use JSON and then interpret the returned
objects as code. Take a look at the client/server traffic produced by ZK,
for instance.


> As Jonathan said, the server is already generating dynamic HTML... why
> have it return


It isn't. There is no already generating anything server, it's a new app
Nate is writing. (Unless you count his work of the past two days). The
dynamic HTML he's generating is heavily tailored to his JS. There's
extremely tight coupling, which now exists across multiple files written in
multiple languages. Simply avoidable bad software engineering. That's not
even making the computational cost argument that avoiding template
processing on the server is cheaper. And with respect to Jonathan's
argument of degradation, a degraded version of his app (presumably) would
use <table> - or something like that, it'd look nothing like what's he
showed us yesterday.

Heh - the proof of the pudding is in the eating. Why don't we create 2
versions of Nate's app, one with mixed server/client - like the one he's
completing now, and I create the client-side based one, and then we compare
side by side?  I'll work with Nate on that.

  - Godmar

[ I hope it's ok to snip off the rest of the email trail in my reply. ]