 |
 |
Again, with jrock... I was replying to the general "Ajax requests returning HTML is outdated" theme, not to Nate's actual application. Certainly returning objects as code or data to a component (like, say, SIMILE Timeline) is a reasonable use of data coming back from Ajax requests, and covered in my "it depends" response :) A defender of the old? Only in as much as the old is simpler, cleaner, and leaner than all the new wheels being invented. I'm pragmatic, not dogmatic. Erik On Dec 6, 2011, at 09:34 , Godmar Back wrote: > 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. ]