Client-Side Scripting vs.

Server-Side Scripting

Client sides
Client-side scripting offers an easy way to provide additional functionality and flexibility to your
project. HTML is very limited, it's main purpose is to display and format content. It allows little
or no interaction with the visitors of your site.
Scripting technologies like JavaScript, JScript, VBScript and others are used on many sites to
add extra functionality to a web site. Ranging from simple mouse over image effects,
animation, form field validation to complex dynamic menu systems, these scripts enhance the
functionality and user experience.
Server sides
The use of server-side scripting is often less visible to users. It is mostly used for content
management, where the site's content is stored in a database, and presented to the user on
request. Server-side technologies like PHP, ASP, JSP, Perl and many others have nearly become
a requirement for successful web sites today.
Like client-side scripting, server-side scripting also enhances the functionality of your site.
Forums, polls, guest books, searches and many other uses of this technology allow for far
more interaction with your visitors than with HTML alone. And server-side scripting can be
very useful in site maintenance. By creating a content management system (or “CMS”) you
can provide yourself and your colleagues with an easy and efficient way to update your site.
Differences
The main difference between client and server-side scripting lies in the place and way it is
executed. Client side scripts are downloaded by the browser, interpreted by the browser, and
executed by the browser, depending on the memory, CPU speed and in when dealing with
animation, even the video card in use on your visitors' computer. Server-side scripts run on
the server and depend on the memory and CPU speed of the server. This difference is of vital
importance when making a choice between client and server-side scripting solutions for your
project.
Server-side scripting has to be supported by the server you will host your site from. While
most decent web hosting companies support at least one server-side scripting language, many
free web hosts may not. If your project requires server-side scripting, or if you are thinking of
taking your first steps into this world, make sure your new or current host has support for it.
Client-side scripting relies on the browser and computer in use by the person visiting your web
site. While this frees you of the costs of renting or running a proper server, it may increase
project development time and costs to deal with the variety of browsers and hardware
available to users. As more and more devices like PDA's, phones, gaming consoles, fridges and
whatnot provide users with ways to browse the World Wide Web this becomes increasingly
important.
Common Pitfalls
The most common mistake made is to rely or depend on only client side scripting. Because of
the dependency of client-side scripting on the users software (browsers, plug-ins, etc) and
hardware (when using complex animation or calculations), doing so can generate annoying
error messages, complicate or even completely disable users from viewing pages on your web
site. When using client-side scripting identifying your audience becomes very important.
Although I can not discuss any problem that may arise when choosing the wrong technology, I
will discuss a few common mistakes which can, unfortunately, be found on many web sites.
Scripted Links
JavaScript is often used in menu, on buttons and on other elements to create links to other
pages and sites. While these menus and buttons may look great, save space in your layout
and even enhance your site, a user visiting your site with an old browser or a browser with no
JavaScript support will be totally lost. Another issue, often overlooked, is the fact that web
robots used by many search engines also do not follow links that rely on JavaScript. This may
prevent your site from being indexed properly. The solution to this problem is to provide an
alternative way to navigate your site which does not rely on JavaScript, or to create a menu
that uses a combination of HTML and JavaScript to ensure compatibility.
Pop-up Windows
Scripted pop-up windows have the same problem as scripted links. If no alternative is
provided, users without the proper browsers or web robots will not be able to continue their
visit. Web sites that open a pop-up window for design reasons can become totally inaccessible
this way. There is an easy way around this, which I have discussed in my “Smart Windows”
article.
“mailto:” forms
Although the “mailto:” form issue may not be a scripting problem, it does suffer from the
same problems discussed in this article. The “mailto:” method relies on the visitors' e-mail
software. If a visitor has no e-mail software installed (libraries, universities, train stations,
airports, etc), has an incompatible e-mail client or has incorrect settings for his program, you
will not receive the message the visitor is trying to send to you. For a personal site this may
not be such an issue, but when your web site gets any more serious than that, user feedback
becomes very important. Think of how someone having trouble with your site or product must
feel about your services if he can't contact you, or gets an error message after spending half
an hour describing the problem he is having. A server-side solution is definitely the correct
choice here.
Scripted Forms
Another issue with forms is that for some reason JavaScript is used to submit the form. On
most web sites with this issue, the submit buttons have been replaced by links, the form uses
a field validation script that relies on JavaScript to submit the form or the submit button has
been omitted because it did not fit the design of the site. Any user with no or disabled
JavaScript support will not be able to use this form at all. Some of these examples can be
fixed by using server-side scripting, others cannot be fixed without returning to rely on HTML.
Security Considerations
When using server-side scripting, it is very important to keep an eye on the security
implications your script may have. Never trust any input provided by users, and always
validate the data they provide. Even some simple page template systems can create serious
security issues when your script allows users to display any file on your server in the template.
Because client-side scripts will run on the users machine, the security problems are less
dangerous for you. Browsers have security restrictions build into the browser to protect the
users computer from any harm. Do not rely on client-side scripting alone for input validation.
A malicious user can download the file, change or disable your script and with that the security
it provided.
It can pay off to use both technologies in some cases too. With form field validation, you can
use JavaScript to check the data entered by the user before it is send to the server by the
form. When done right, you can provide the user with clear messages on what needs to be
changed. Because the data is checked before it is send to the server, you reduce load on the
server. When all form fields pass the JavaScript validation, it is send to the server, and checked
again by server-side scripting before the data is stored or processed. This way you take full
advantage of both technologies.
Bottom Line
As I mentioned at the start of this article, it will not provide ready made solutions to any
problems you may have. I do hope I have made you more aware of issues that may arise
when using both of these technologies.
When working on your project, always try to make sure you keep the basic functionality intact.
You can use client-side scripting to enhance your site, but don't do it at the cost disabling or
crippling your site for visitors with different browsers or no scripting support.
If something you want to add to your project can both be done with client and server-side
scripting, it's best to use server-side solutions. You can, in most cases, use a combination
between the two to do what you want and with that, keep the site's functionality intact.
Client side scripting and server side scripting generally accomplish two very
different tasks. Each has different advantages and disadvantages. To summarize:

Client-side scripting is generally a light-weight, less full-featured language. You don't have
the ability to write files, access databases or other sophisticated application development
necessities. This is primarily for security reasons, since these scripts run on the client-side and
the client would not wish to allow the scripts access to resources on the local machine. That
being said, it can be useful at times to push some computing off on the client, although
generally, this should only be display logic. You don't want anything critical or anything secure
to be dealt with on the client, because generally the user will have access to these scripts to
view and modify.

Server-side scripting, as the name implies runs on the server machine and then the results
of that scripting, generally HTML are sent out to the client. Server-side scripting and
development languages have a broader feature set, including database access. These are
more appropriate when you have complex interaction with the server such as session
management and interaction with server-side resources or objects. In some cases, like JSP, it
isn't even really a scripting language. A JSP page compiles to a full Java servlet, so unlike any
client-side script, it does not need to be parsed and interpreted every time. Server-side
scripting allows you to do very sophisticated display logic while not requiring the client to have
a high-end machine.

Often a full application will have both components. Server-side scripting for the main display
logic and client-side scripting for the dressing, like roll-over buttons or pop-up menus.

--------------------------------------------------------------------------
Server-Side vs. Client-Side Scripting
--------------------------------------------------------------------------------
When you create a dynamic html page the code that makes the changes to the web page must
be run in one of two places. It can be client-side code executed by the user's web browser, or
it can be server-side code executed by the server. There are advantages and disadvantages to
using one over the other, and a well-planned mix of the two can have a dramatic effect on
your web page.

The advantages of server-side scripting are many. Because all of the server side code is
executed before the HTML is sent to the browser, your code is hidden. Server-side code is also
the only choice if you want to access files and directories on the local machine. Server-side
code is also browser independent. Because the HTML code returned by the server is simple
HTML, you do not have to worry about the version of browser the client is using. The
disadvantage to server-side scripting is that the server must use valuable resources to parse
each page it sends out. This could slow down your web site.

Client-side scripting can be very useful. The major advantage is that each web browser uses
its own resources to execute the code found on the web page. This eases the burden on the
server. The disadvantages are that you can not prevent the user from seeing your code and
that you can not use client-side code to access local files, directories, or databases.

By designing your web site to take advantage of the strengths and weaknesses of both client-
side and server-side scripting, you can protect your code and get maximum performance.

------------------------------------------------------
Occurring on the server side of a client-server system. For example, on the World Wide Web,
CGI scripts are server-side applications because they run on the Web server. In contrast,
JavaScript scripts are client-side because they are executed by your browser (the client). Java
applets can be either server-side or client-side depending on which computer (the server or
the client) executes them.

----------------------------------------------------------
To explain the difference between server-side en client-side analytics, I first need to explain
the difference between server-side and client-side scripting..

Client-side scripting means all calculations are done by the computer of the visitor. Most of the
time the script is interpreted by their internet browser (Javascript) or a specific browser plugin
(Flash actionscript).
Server-side scripting means all calculations are done by the server your website is hosted on.
The script is interpreted by the supported language parser, like PHP or ASP.
What can be detected?
Many factors like security issues have led to restrictions in both server- and client-side
possibilities. Javascript isn’t even made to be able to communicate back to a webserver, but
certain tricks have led to client-side webanalytics and Ajax. Therefore some types or
information are only available in Javascript and some information can only be retrieved by
PHP. The following table shows information available in both types and the main restrictions.

Client Server
Browser properties Server/site/page properties
Page element properties Connection properties
Change possible on any interaction Change requires reload
Read-only access to external files Many communication possibilities
Entire script source visible Script source hidden for visitor
Restrictions based on browser Restricted by server settings
security-and support settings.
Client support required All requests are counted

Client-side summary
Languages like Javascript can detect what browser you are using, your screen size, plugin
support and much more. But that may be restricted by the security level you set for your
browser. It can also detect and change any property of the page (like the width and
background-color of a table) you are watching and change it on the fly, based on any type of
detected interaction. This interaction can even be a slight mouse movement or the press of a
key.

The javascript source code can be read with any text editor, so don’t place passwords within
them. But information a user enters remains client-side (minimizes server load) and normally
isn’t send to any server. But there are ways to send information to the server-side.

Depending on the security settings in your browser, javascript can request and read external
files like XML feeds. To circumvent stricter security settings, javascript may also request
images; And that is what is exploited by many client-side web analytics programs like Google
Analytics. The requested file/image URL can be stuffed with information, so the server can
retrieve these GET variables from there.
p.s. Javascript can also vacate forms and send them and it can also read/write cookies to
communicate with other files.

Javascript web analytics only logs visitors that support this language, in files that allow
javascript execution.

Server-side summary
Languages like PHP can request (and change) any property of the webpage it is on and any
variable used to while compiling the resulting HTML code. It can also see properties of the
connection between visitor and server and unlike Javascript it can detect the IP address. Any
change requires a reload or new page request, which requires more loading and a client-side
action (can be from both a user or client-side script).

Server-side scripting code can’t be read by visitors, so no one can steal your script and no
client support is needed. The calculations are done by the server, so more visitors means more
server-load. Different server-side languages, plugins and external data can supplement
eachother and the only thing that counts is the end result.

Languages like PHP offer numerous ways to communicate with other servers and files across
the web and no one will ever know what was required to compile the data. When a website is
hosted on a shared server, the possibilities of server-side can be somewhat limited, but on a
dedicated server the only programming limitations are posed by server-load, software licenses
and your own technical capabilities.

Standard server-side web analytics is based on server logs. This is a very limiting way of
measuring visits and you need many filters to drop search engine robot requests and other
non-human visits. But Javascript can’t detect non-human visitors at all.

So how do you combine both in your analytics reports?