I've been following this thread very closely, and find myself torn. Doing all the HTML generation server-side seems like the easiest way to have a single set of template code that's shared between JS and non-JS paths, reducing complexity of the overall app, and making graceful degradation easier. On the other hand, doing client-side HTML generation (or direct DOM updating) seems like it offers better performance, greatly reduced bandwidth, and a better fit if you want to create a reusable API.
I think there is a third way: using the same template code for both client-side and server side rendering. The basic HTML version would retrieve pages rendered server-side, and the enhanced JS version would retrieve JSON and render the UI with the same templates (presumably with modular templates so the JS version would only have to update the areas with updated content, and not the entire page). The only template systems I know of that have both client and server support are XSLT and Mustache. Are there others? Has anybody set up a system like this? -Esme -- Esme Cowles <escow...@ucsd.edu> "The wages of sin is death but so is the salary of virtue, and at least the evil get to go home early on Fridays." -- Terry Pratchett, Witches Abroad On 12/7/2011, at 9:38 PM, Jonathan Rochkind wrote: >> Also, I've thought of a good reason myself: performance. If I'm adding >> an item to a list, it's a better user experience to update the display >> immediately rather than waiting for the server to send back a 200 OK, >> and handle the error or timeout case specially. > > While in general I tend toward the other the other thing you said, "Does it > make sense to replicate the > server-side functionality on the client?" -- I think what you propose above > is legit. > > MOST people don't write interfaces like that, even in js. That is, an > interface that will update the user interface even before/without receiving > _anything_ back from the server. (But, in the best cases, produce and error > message and/or 'undo' the user interface action iff the server does later get > back with an error/failure message). > > So if you're going to do that, then--- it kind of doesn't matter if the > server sends back HTML or JSON or anything else, the user interface is > updating before/without getting _anything_ from the server. But to the extent > the server's response then serves pretty much only as a > notification-of-failure or whatever, yeah, JSON is the way to go. > > So, yeah, if you're going to go all the way there, that's a pretty cool thing > (if you can make sure the failure conditions are handled acceptably), sure, > go for it.
