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