Nate,
From what I hear, these are increasingly common questions.
When the main stack is javascript, it just heightens the questions.
With the resurgence of javascript being used server-side with tools
like Node.js, client-side javascript MVC frameworks, and single-page
applications, lots of different folks are coming to different
conclusions about where it makes sense to do certain work. Some of
these client-side frameworks may make it more attractive to do things
client-side depending on your needs. I've also heard about frameworks
which essentially let you run the same javascript code either
server-side or client-side. So this is an interesting time for this
question, since there is so much experimentation being done around it
right now.
I don't know if this helps at all. You recently have more options
available than you had before for solving these kinds of problems.
Jason
On Wed, Dec 7, 2011 at 5:43 PM, Nate Vack <[log in to unmask]> wrote:
> On Wed, Dec 7, 2011 at 4:19 PM, Robert Sanderson <[log in to unmask]> wrote:
>
>> * Separation of concerns...
>>
>> * Lax Security...
>>
>> * Obfuscation...
>
> Let's say I'm planning to first build a completely functional app with
> no javascript at al(*)l, and then use javascript for progressive
> enhancement.
>
> In other words, it's *essential* that I have server-side code that
> solves these problems already. Does it make sense to replicate the
> server-side functionality on the client?
>
> 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.
>
> -n
|