Rails - Aug 2009 - 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?

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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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.

On Aug 20, 4:13 pm, drewB
<dbats...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
>
> *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?

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.

-- 
Mike Cugley
mcugley-e7pH8IvhmmnQzY9nttDBhA@public.gmane.org

> 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

On Aug 20, 11:13 am, drewB
<dbats...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
>
> *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?

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.