I definitely don't think one pattern is going to cover every possible scenario.  And I agree that we shouldn't be dogmatically telling people that one practice is always good and another is always bad.  

But in my experience, writing code to do the same task in two different places (in two different languages) is going to lead to headaches.  So when supporting non-JS clients is required, I'm very skeptical of using an approach where the non-JS fallback is basically developing a separate tool to do the same job.

This might lead to using different approaches for different parts of an app.  Maybe the search and browse functionality uses server-generated HTML for maximum compatibility and robot support.  But the tagging and editor functionality uses a more RIA approach to improve experience and efficiency, at the cost of having to either exclude non-JS clients or implement separate tools for them.

-Esme
--
Esme Cowles <[log in to unmask]>

"I don't need to be forgiven." -- The Who, Baba O'Reilly

On 12/8/2011, at 12:11 PM, Godmar Back wrote:

> On Thu, Dec 8, 2011 at 11:14 AM, BRIAN TINGLE
> <[log in to unmask]> wrote:
>> returning JSONP is the the cool hipster way to go (well, not hipster cool anymore, but the hipsters were doing it before it went mainstream), but I'm not convinced it is inherently a problem to return HTML for use in "AJAX" type development in a non--ironic-retro way.
> 
> Let me give you an example for why returning HTML is a difficult
> approach, to say the least, when it comes to rich AJAX applications. I
> had in my argument referred to a trend, connected to increasing
> richness and interactivity in AJAX applications being developed today.
> 
> Say you have an <input> text component in your app. When its value
> changes, a number of other components need to be updated. For
> instance, a label (which is a <span>), and a button. In addition, it
> may be the case that new elements appear on the page when that's the
> case. For example, in our edition builder app, a user may change the
> name of a proxy (as in EZProxy.) We need to update the title, we need
> to update the label on the button where it can be removed, and we need
> to update the status message when the configuration was last changed.
> The response looks somewhat like this:
> 
> {"rs":[
>  ["setAttr",["dP1Qvi","value","Off-Campus"]]
>  ["setAttr",["dP1Q9m0","label","Delete Proxy Off-Campus"]],
>  ["setAttr",["dP1Qy7","content","12:01:03 PM Dec 8, 2011 edition <a
> target=\"_new\"
> href=\"http:\/\/libx.org\/editions\/libxtestedition.php?edition=1C7B69E1.1\">1C7B69E1
> rev 1<\/a> successfully saved. Click <a target=\"_new\"
> href=\"http:\/\/libx.org\/editions\/libxtestedition.php?edition=1C7B69E1.1\">here<\/a>
> to try out this configuration."]],
> ],"rid":11}
> 
> (simplified here.)
> 
> Coding this as a single HTML response is impossible. First of, it
> would mean finding a common anchestor element that could be replaced,
> which would result in a huge transfer. Obviously, you don't want
> multiple AJAX requests. So you'd come up with your own encoding of all
> updates to be done on the client. You could do that using multiple
> HTML fragments, and defining your own response format around them.
> Older frameworks have done that, but have since realized that it's
> better to simply return JSON-encoded instructions to the client what
> to update.
> 
> If we tell newbies (no offense meant by that term) that AJAX means
> "send a request and then insert a chunk of HTML in your DOM," we're
> short-changing their view of the type of Rich Internet Application
> (RIA) AJAX today is equated with.
> 
> - Godmar