homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
Forum Library, Charter, Moderator: open

JavaScript and AJAX Forum

JavaScript vs Server-Side
Pick your winner

 2:34 pm on Jun 10, 2003 (gmt 0)

In the JavaScript JumpStart - Part 2 [webmasterworld.com], we discussed form validation with JavaScript. Some feel that server-side scripting should handle everything and JavaScript is a waste of bandwidth.

I believe that used in tandem it is very powerful depending on what your project. So where does JavaScript come into play? Why do you think it is a waste of bandwidth?



 2:58 pm on Jun 10, 2003 (gmt 0)

IMO, JavaScript is vital and that there will always be a need for a client-side language. Why? Real-time interactivity, event handling and even validation.

The question of when to use JavaScript for your form validation is one, I feel, that depends very much on the scale of the project. I do believe that every form should have some JavaScript validation: does the email address have an @ and at least one instance of "." in it? Does the name contain numbers? Does the CC number contain letters? This sort of cursory look at the data in a form is best done at the client side - just to check for the user before hitting the more-extensive server-side validation.

The above holds true for large sites, high form traffic and large forms (ie many fields) - but more smaller sites, with more manageable form sizes (contact us forms, for example) then JavaScript validation is all that is really needed. Check that the field value formats are ok and then submit the form.

The use of JavaScript for form validation can lead to very gracefull flagging of invalid fields without the wait of the form being submitted, the server chewing through the server side code and then spitting back the results/errors (ok - I'm making light of that, but you get the drift!).

While server side validation is necessary some of the time, it's my belief that client side validation of some form is needed all of the time.


 3:00 pm on Jun 10, 2003 (gmt 0)

Ok, appologies for threadjacking Korkus2000's excellent Javascript Jumpstart. I've been asked to bring my argument against client side validation into a new thread...


If somebody makes a mistake completing a form, rather than simply throwing some client-side JavaScript form validation at it, ask yourself why your user completed the form incorrectly in the first place.

Is there anything you can do to improve your form? Should you be providing clearer instructions?

If your first time error rate is bad enough to warrant JavaScript then I would argue that your form design, layout or instructions are poor.

So if you're with me so far, and you've improved your form by studying invalid input and doing something about it, you should be in the position where your client side JavaScript code is only rarely brought into play.

So given that it is only rarely brought into play, there is your argument for taking it off the client and doing all validation server side, since you have to anyway (cannot trust anything from the client) and saving yourself perhaps several megabytes of bandwidth a day on a busy site.

Sure, there will be occasional round trips which may inconvenience the odd modem user, but probably not that much, and certainly not more than one round trip otherwise you really do need to reconsider your layout!

[please note - i'm not discounting anything to do with forms and javascript - there are excellent usability tweaks that can be achieved - but they benefit every user and hence don't fail at my "only rarely comes into play" clause]


 3:09 pm on Jun 10, 2003 (gmt 0)

saving yourself perhaps several megabytes of bandwidth a day on a busy site.

I didn't want to jump into this discussion, but I will.

I totally disagree with the argument above with respect to form validation and design flaws. Take an email address. You can't be clearer about "email address". If a person leaves out the @ or the . then there is nothing short of a 2 x 4 against the head that will remind the person to use it.

It does not take megabytes of bandwidth to have client side javascript validate that form before using the bandwidth to make the round trip to the server, only to find out there are missing symbols.

Client side javascript, like the HTML page, is cached on the client, so there is no further call to the server until the form is submitted.

It is better to catch simple mistakes on the client, and have only one trip to the server when the form is ready.

Server side validation is then used to check the validity of the data - is this a duplicate ID? Is the person eligible to go further?

All the basics should be handled client side to save bandwidth.


 3:19 pm on Jun 10, 2003 (gmt 0)

You can't be clearer about "email address". If a person leaves out the @ or the . then there is nothing short of a 2 x 4 against the head that will remind the person to use it.

But that doesn't defend the client side case in the face of my argument. I'm saying people won't get their email address wrong often enough for you to justify the overhead.

I just thought of an analogy to help support my case.

Consider the police. They patrol the streets normally in pairs in a single car. Most incidents they come across don't require the back-up of a prison van in which to take prisoners, so they don't have one. On the rare occasions that they need one, they'll call one in.

Client-side JavaScript form validation is like the police having the prison van with them all the time, even though the vast majority of incidents they come across do not warrant it.

Police patrols don't have a prison van with them all the time because it is a waste of resources. So is client side JavaScript code specifically for form validation.


 3:31 pm on Jun 10, 2003 (gmt 0)

Hi All

I think the argument about looking at some of the mistakes people are making on your forms, and using that to improve the site's usability is a great one. But I don't think it should be done to the exclusion of javascript form validation.

You need server-side validation as well, but I think client side processing improves usability because of the immediacy of the response. So an argument to avoid using javascript while aiming for a goal of utopic usability is ill-formed, I think.

Perhaps one idea to collect information to help improve the sites usability might be to periodically take a sample of incorrectly filled in forms (e.g. For a short period every feww months, substitute the javascript file with a set of dummy header functions, collect the data on incorrectly filled in forms, and substitute the proper javascript file back in).

The other argument against javascript (bandwidth usage) is not something that is easy to comment on without hard data. But here is a bit of gut feel/conjecture: The bandwidth savings in form retransmission will far outweigh the bandwidth spent on javascript code. Usability is not an exact science and you can't totally eliminate all form mistakes, so there will always be retransmissions no matter how much you analyse the failed forms and tweak the form layouts. Wel, that is conjecture. I'd be interested if anyone has any hard data.


[edited by: ShawnR at 3:34 pm (utc) on June 10, 2003]


 3:32 pm on Jun 10, 2003 (gmt 0)

>>Client-side JavaScript form validation is like the police having a prison van with them all the time

I would aurgue that it is the second officer in the car.

My point is you just can't make complicated forms with no or almost no error rate. Small forms I can see your point, but not for large forms. I work with useability guys who cannot get the error rate on forms down enough to warrant getting rid of JavaScript. I have not seen your forms, but I have seen the studies by our crew with our forms. Our audience needs the client side validation.

It really is not a design issue either. There are bad and good forms. You can only try and make your site useable for the majority of your audience. If your audience is very focused then you might have a very low error rate, but instances like these are few and far between. Most general sites cannot get a small error rate no matter how good the design. The higher the trafffic rate the more this error group rises in numbers and needs to be dealt with.


 3:35 pm on Jun 10, 2003 (gmt 0)

I'm saying people won't get their email address wrong often enough for you to justify the overhead.

I wish that would be true. Always remember that internet users are not all as savvy as you (and all of us here I guess). Some just don't know that they have to put the ENTIRE address, including the '@whatever.foo'. And even if you write that just under the text box, they won't read it.

Then there are the typos. People don't really check what they're writing on the web, so more typos happen.

And then there are always people who will try to send a form without completing all the mandatory fields, or just write some random characters. I know even with a JS check they can give a bogus address, but still it helps.

In short, there are lots more mistakes detected through JS than you might think. I have no stats to 'prove' that, but I get enough calls from friends and family asking why they can't send in a form and just overlooking something which seems obvious to me.


 3:36 pm on Jun 10, 2003 (gmt 0)


Let's consider it from the users point of view. He/she is entering some information into a form and mistypes something - let's say for arguements sake that they hit the 5 key instead of the "r" in their surname.

Using client-side validation this error is picked up immediately, they are given an error message telling them that there is an error with their surname - they check and see the error, fix it and submit the form. Fast, useable and intuitive.

Consider then the server side case. Using the same example, the user submits the form, waits for the reply page which tells them that there is an error with their name (hopefully repopulating the data they submitted!), they correct the error and resubmit. In this case, the time taken to correct the error and re-submit the form is hitting close on twice that taken for the error to be caught and the form resubmitted using client side validation.


 3:41 pm on Jun 10, 2003 (gmt 0)

This may go in a little different direction..., I see the use of Javascript and where it "kicks in" more from a conceptional point of view.

In Web Programming there is module called "client-side-scripting" which offers this and that functionality. It depends on my expectations of the availability of client-side-scripting on the client ("are they using a webbrowser like IE, Mozilla or Opera?"):

- If I expect it is there, I can use 100% functiality (and take bandwidth balances into account to decide client<->server-side)
- If I must expect, it is NOT there, I don't use it.
- If I'm somewhere in between, i don't RELY on it. (In case of the ongoing email-verification topic here, I would need both solutions server+client for the plausibility!) [I personally don't validate email-addresses. The client might not have it available, wants to stay anonymous or is drunk, but he still has something to say/send.]

Question to the high-performance-website-webmasters here: Does some Javascript really blow up bandwidth so much? (I feel stupid vs. intelligent table layout may have far mor impact...?)

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved