# What should be server-side and what should be client-side **URL:** \ **Category:** Rails\ **Created:** [August 20, 2009, 5:48pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085 "2009-08-20T17:48:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 20, 2009, 5:48pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/1 "2009-08-20T17:48:26Z")
I have been thinking lately about what should be executed client-side vs. server-side and was curious what others thoughts are. Let’s take the following example. A user has selected X pieces of furniture. On a single page, they are shown a list of the furniture items with specific info about each piece (name, dimensions, manufacturer, list of parts etc). Much of this info wouldn’t be shown by default but is expandable. The user can delete furniture items or add new ones. When they add a new one it is immediately added to the page without reloading. _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. _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): - I make up that the server can handle more users because less work is done there. (can someone verify or refute this?) - 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). - 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). I could for certain sites, that a delay when someone adds a new item might be preferable to when the page just loads. What are your thoughts? ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 20, 2009, 11:01pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/2 "2009-08-20T23:01:20Z")
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](http://www.marnen.org) removed\_email\_address@domain.invalid ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 21, 2009, 12:24pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/3 "2009-08-21T12:24:10Z")
If you thinks about accebility, you must choose both ways. A lot of AJAX to improve user experiencie, but backed by server-side alternatives in order to allow users without Javascript and with special browsers or navigation methods. You will improve the discapacited user experience too. ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 21, 2009, 5:13pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/4 "2009-08-21T17:13:59Z")
drewB wrote: > To me, the balance between Server-side and Client-side comes down to how much of the information you have available on your site is actually going to be used in any one session. If most of the data is going to be used, then you’re as well downloading it once (Client-side). If most of the data is _not_ going to be used, only download that which you actually need (Server-side). In other words, for your furniture site, if you have 20 different types of furniture, and the user is likely to look at all or most of them, then client side. However, if you have ten thousand types of furniture, and the user is only likely to select twenty or so to look at, then server side - otherwise they will be downloading huge swathes of information that they won’t actually need. – Mike Cugley removed\_email\_address@domain.invalid ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 21, 2009, 5:33pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/5 "2009-08-21T17:33:18Z")
> To me, the balance between Server-side and Client-side comes down to how > much of the information you have available on your site is actually > going to be used in any one session. > > If most of the data is going to be used, then you’re as well downloading > it once (Client-side). > > If most of the data is _not_ going to be used, only download that which > you actually need (Server-side). Agreed, this is very important. Don’t send data that probably isn’t going to be used. You can always make AJAX calls to retrieve data that you don’t have already, making it look like it was already there. That also makes it alot easier to handle non-javascript browsers using the same controller and views. So, list your furniture names and, for example, make them expandable. If expanded, a piece of data is retrieved from the server. This is a fast request. If javascript is not enabled, you can easily reload the page with the piece of furniture you want expanded. Otherwise you would, for example, be sending hidden information about every piece of furniture along with every non-AJAX request, which is definitely -not- going to be used. ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 21, 2009, 6:20pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/6 "2009-08-21T18:20:08Z")
There are two issues I can see with the client-side solution: - what does Google see when you do that? Perhaps not an issue if you’re doing a closed app, but it could be a big issue on a public site. - what about IE users? Keep in mind, a lot of users are on IE6 and 7, which are roughly 10x slower with Javascript than the browsers most devs use. That loading screen that goes away in a second could be a 10 or 12 second wait for some users… –Matt J. ---
**Author:** ![drewB](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@drewB](https://www.ruby-forum.com/u/drewB)\ **Post date:** [August 21, 2009, 6:40pm UTC](https://www.ruby-forum.com/t/what-should-be-server-side-and-what-should-be-client-side/174085/7 "2009-08-21T18:40:03Z")
Interesting thoughts all around. I agree if making your site accessible to clients without javascript is important than you definitely should go with the server-side solution. The type of site I had in mind when starting the conversation would be pretty useless if someone didn’t have javascript due to its nature (even if I went to the trouble to make it accessible). Think of google spreadsheets without javascript. I also agree that AJAX is the way to go when serving up data that won’t likely be used in the session. “Public” pages also would need to be server-side for SEO (like Matt mentions). I am thinking of pages presented to a user after they log in. Matt - great point about older browsers. I usually think in terms of compatibility not speed.