drewB wrote: > I have been thinking lately about what should be executed client-side > vs. server-side and was curious what others thoughts are. [...]
There are of course no fixed rules, and a lot depends on usage profile, so take my comments with that in mind. > *Server-side heavy solution* > > You could implement this mostly server-side with some javascript to > expand info, add and delete items, etc. When the user added an item, > you could use AJAX to build the new block server-side and just add it > to the page when returned. In most cases, this is the way I would do it. It means that the client doesn't have to load lots of data at once, and it makes the site more usable for clients without JavaScript. > > *Client-side heavy solution* > > Server-side you could generate a simple javascript variable with the > page's data (perhaps in JSON) and then generate all the page's content > with javascript client-side (you would of course still do all the > layout server-side). This is actually much easier than it might > seem. Prototype has some nice DOM editing that is very clean. > > *My Thoughts* > > Lately, I am leaning toward the Client-side heavy solution for the > following reasons (feel free to argue with me): Argue I will. I can imagine that this might be appropriate in some cases, but I think it would generally be a bad idea. > > - I make up that the server can handle more users because less work is > done there. (can someone verify or refute this?) Maybe, but I doubt that it will be a big issue in most cases. Expecting a lot of client-side processing, however, will be more of an issue, and will fail if JS is not enabled on the client side. > - Cleaner delineation for presentation layer because all the main > content is present with javascript. If I want to change the way > things look, I just go to one place. If it is done server-side, I go > one place for initial presentation (server-side) and another for on- > page dynamic presentation (which has to be javascript). Unless I grossly misunderstand, this should not really be an issue if you use Ajax and CSS properly. > - Possibly better user experience because there is no delay between > adding an item and it showing up on their screen (don't have to wait > for AJAX call to return). However, there would be a delay when the > page first loads while javascript creates the content (I use a "page > loading . . ." message that disappears typically in less than 1 > second). Yeah, and some browsers don't seem to respond that well to heavy JS content. > I could for certain sites, that a delay when someone adds a > new item might be preferable to when the page just loads. I'm not sure about that. > > What are your thoughts? See above. I'm a Web oldtimer -- for the first several years I used the Web, it was on a greenscreen box -- and while I think JavaScript and Ajax, properly used, can do wonders for Web apps, I think there has come to be what I'd consider to be an excessive reliance on them. Sometimes complex Ajax with a lot of client-side processing really is the best way to present an effective UI, but I think people rush to it these days without really considering the disadvantages. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
