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

Rails
1

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?

2

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]

3

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.

4

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
[email protected]

5

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.

6

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.

7

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.