librelist archives

« back to archive

Thoughts on javascript graceful degradation for actions

Thoughts on javascript graceful degradation for actions

From:
Rahul Kumar
Date:
2011-03-01 @ 20:49
Hey People,

How do you do graceful degradation for javascript?

Consider vote - upvote/downvote thing which reddit/stackoverflow etc use.
Say I implemented voting  over ajax and it uses POST and csrf tokens. The
server sends a new csrf token as part of response and the client updates
itself for the next request.

Now if javascript is disabled, GET will be triggered. I will have to enable
POST, GET for the controller and conditionals for returning different
response to Ajax and regular calls - for regular calls, just re-render the
page with different csrf token; for js call, send back the csrf token and
related data(if any).

How do you people do that? Do you generally walk the extra mile to ensure
graceful degradation or you let your application break if javascript is
disabled? This sure depends on the application context, but consider this as
a general opinion seeking post.


Rahul

Re: [flask] Thoughts on javascript graceful degradation for actions

From:
Joe J. Szacon
Date:
2011-03-01 @ 21:24
Why would a GET have to be triggered without javascript? You can create your
upvote/downvote as a individual forms with styled <buttons>s that post when
clicked.



On Tue, Mar 1, 2011 at 3:49 PM, Rahul Kumar <rahulsinner@gmail.com> wrote:

> Hey People,
>
> How do you do graceful degradation for javascript?
>
> Consider vote - upvote/downvote thing which reddit/stackoverflow etc use.
> Say I implemented voting  over ajax and it uses POST and csrf tokens. The
> server sends a new csrf token as part of response and the client updates
> itself for the next request.
>
> Now if javascript is disabled, GET will be triggered. I will have to enable
> POST, GET for the controller and conditionals for returning different
> response to Ajax and regular calls - for regular calls, just re-render the
> page with different csrf token; for js call, send back the csrf token and
> related data(if any).
>
> How do you people do that? Do you generally walk the extra mile to ensure
> graceful degradation or you let your application break if javascript is
> disabled? This sure depends on the application context, but consider this as
> a general opinion seeking post.
>
>
> Rahul
>

Re: [flask] Thoughts on javascript graceful degradation for actions

From:
Rahul Kumar
Date:
2011-03-01 @ 21:31
Yes, that's an option. My question is more on the lines of what do you
actually do? Would you have the buttons in a <form method="POST"> or you
won't bother about it?

I am considering not worrying about graceful degradation, since the app I am
doing will mainly be used by mainstream people - mainstream in the sense
they either aren't aware or don't care about security holes javascript
potentially can open.


On Wed, Mar 2, 2011 at 2:54 AM, Joe J. Szacon <jszacon@gmail.com> wrote:

> Why would a GET have to be triggered without javascript? You can create
> your upvote/downvote as a individual forms with styled <buttons>s that post
> when clicked.
>
>
>
> On Tue, Mar 1, 2011 at 3:49 PM, Rahul Kumar <rahulsinner@gmail.com> wrote:
>
>> Hey People,
>>
>> How do you do graceful degradation for javascript?
>>
>> Consider vote - upvote/downvote thing which reddit/stackoverflow etc use.
>> Say I implemented voting  over ajax and it uses POST and csrf tokens. The
>> server sends a new csrf token as part of response and the client updates
>> itself for the next request.
>>
>> Now if javascript is disabled, GET will be triggered. I will have to
>> enable POST, GET for the controller and conditionals for returning different
>> response to Ajax and regular calls - for regular calls, just re-render the
>> page with different csrf token; for js call, send back the csrf token and
>> related data(if any).
>>
>> How do you people do that? Do you generally walk the extra mile to ensure
>> graceful degradation or you let your application break if javascript is
>> disabled? This sure depends on the application context, but consider this as
>> a general opinion seeking post.
>>
>>
>> Rahul
>>
>
>