Understanding the difference between "Client Side" and "Server Side"
We get so many inane questions that revolve around this subject
that I decided to try and be more helpful by providing a sort of "reference"
document that will enable people who may be confused to read up a bit and save
everybody some time. In fact, its more of a selfish move on our part, since now
if I can get most of the information into this document, then the next time somebody
asks another one of these questions, all we have to do is point them to this
First, the simple explanation:
is what's happening on your computer in your browser. It has nothing to do with
the server, or ASP or ASPX pages, or IIS, or the database, or ANYTHING ELSE.
need the server to help with the functionality of the script. If you can run
it on your computer (without a server being installed) and it works, it's client
side. In fact, when a web page is sitting in your browser after it has been processed
by the server and sent "over the wire", there is absolutely no further
connection with the server whatsoever at this point. NONE! ZERO! NADA, ZIP! The
page in your browser has absolutely NO KNOWLEDGE of the server or what may be
going on there, and conversely, the web server machine that served the page to
your browser hasn't got the slightest idea of who you are or where you are, or
whether you ever even visited the web site at all! The Web is Stateless, my son
-- just like your mind on a Spring Saturday afternoon! May all your methods return,
Server side is when the server is being used to process
something. Script or code that is run on the server does NOT appear on or in
the web page that is sent to your browser -- the web page that your browser receives
is only the RESULT of the script or database code or processing that happened
on the server.
With these two beliefs firmly fixed in our minds
like concrete sticking to the sides of the Grand Coulee Dam, let's take it down
to the next level and get into a few more details. Client side code is usually
saving a file somewhere, or writing to the user's Registry with client - side
script. It ain't gonna happen. Browser vendors have tightened up security restrictions
to the point where unless you are exploiting some security hole that hasn't been
patched, you may as well forget about these types of things. Forget about downloading
files and depositing them on the user's hard drive and having them run. No way,
Now let's say you have a textbox in a web page and you want
to use client side code to make something happen. For example, every time somebody
types another letter in a text field, you want to go out and search your database
and come back and fill a listbox with the closest matches. Can you do this with
client side code?
Client side code triggering Server Side processing
Well, yes and no. Remember the page doesn't have any further connection
with the server that sent it to the browser. However the client side code CAN
cause, for example, a form on the page to activate its submit method, and if
the ACTION atttribute of the form points to a page that will receive the form
posts and generate the return data, it can be done. However too many people continue
to make the fallacious assumption that some client - side event, such as selecting
a listbox item, or the onblur event of leaving the focus from one control is
going to enable them to get server - side code or events to run. What it MAY
do is create a post or "postback" event. This really means we have
made a NEW TRIP to the webserver with some specific information that the SERVER
SIDE code is prepared to react to, and it will regenerate the page and send it
back to the browser. With Smartnavigation and other features, it may appear the
page has not really been reloaded, but 99% of the time, it has.
only exception to the above is when we use COM components from the CLIENT, such
as XMLHTTP, to issue their own GET or POST action to a receiving web page on
the SERVER, which sends back new information. The component receives this without
a page reload, and using DHTML, we can update client-side DOM items in the page.
Another technique is to use hidden IFRAMES to perform similar actions "behind
the scenes" and receive data. However, the data must be requested from the
same domain the page was requested from, or security restrictions will prevent
our access to the data in the IFRAME. Newer implementations of "Remote Scripting",
which was invented by Microsoft about 1998 are using the term "AJAX".
This is just a buzzword for remote scripting or "Script Callbacks"
which are now built into ASP.NET 2.0.
So! The next time you want
to ask a question about an event or how to "do something in a web page"
the very first thing you should be thinking about is whether this is a client
side or a server side event we are dealing with. Happy Coding!
Submission Date: 9/23/2005 3:20:44 PM
Submitted By: Peter
My Home Page: http://www.eggheadcafe.com