 |
 |
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