 |
 |
On 12/8/2011 9:27 AM, Bill Dueber wrote: > To these I would add: > > * Reuse. The call you're making may be providing data that would be useful > in other contexts as well. If you're generating application-specific html, > that can't happen. Well, if the other contexts are Javascript, and your HTML is nice semantically structured with good classes and ID's.... it actually ends up being just about as easy getting the data out of HTML with JQuery selectors as it would be with JSON. This is kind of the direction of HTML5 microdata/schema.org --- realizing that properly structured semantic HTML can be pretty damn machine readable, so if you do that you can get human HTML and machine readability with only one representation, instead of having to maintain multiple representations. (In some of the scenarios we're talking about, there are potentially THREE representations to maintain -- server-side generated HTML, server-side generated JSON, AND js to turn the JSON into HTML). But yeah, there are always lots of trade-offs. This particular question I think ends up depending on a lot on what choices you've made for the REST of your software stack. Each choice at each level has different trade-offs, but the most important thing is probably to reduce the 'impedence' of making inconsistent choices in different places. That is -- if you're heavy into client-side JS app framework rendering of HTML already, then sure you've made your choice, stick to it.