what should be server-side and what should be client-side

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?

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.

drewB wrote:

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

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.

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 Jones

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.