It’s long been known by anyone who has ever asked me about my views on web-coding that there are few things in the world that I hold in higher contempt than webpages who use clientside scripting excessively to do redundant tasks. Even moreso than that is sites which combine that with excessive use of applets (or total use of applets; read: Flash-based websites). Even moreso still, are sites who do that, and then offer no backdoor for those who aren’t supported (for one reason or another, be it disabled plugins or disabled scripting.. or just outright non-support). Sadly, it’s not until you’re in that boat until you realise how often it actually occurs. So, why does it happen? What compells web coders to utilise these tools to perform even the most redundant or trivial of tasks?

Now, while anyone is not able to run these methods into the ground completely (any decent coder will acknowledge they are useful), as with anything else in the world of the internet, there is a time and a place. Unfortunately, that time and place gets lost in translation all too often. So, to me, this poses a few questions;

• Do Javascript and other Clientside Scripting methods have enough universal support to make them viable to perform main tasks?
• When people learn to code websites, are they taught to rely on these methods too heavily?
• Are the alternative methods (if any) viable to make sites more functional for everyone?

  and;

• Is there any way to make applets and scripting safer to enable them to be more widely supported?

Unfortunately, the answers to those questions are seemingly a touch on the bad side. While the concept of using clientside scripting to do everything on your website is a novel one, and even understandable, it still does not help the fact that a good majority of people who view the content will be stranded. Well, at least if there is not something implimented for those who don’t have support. A good example of this is window popups (new browser windows). All too often coders fall into the trap of making scripts for their window events (primarily Javascript). And why not? It allows you to have total control over the browser window, in terms of size, scrollbars, address bars, navigation, even positioning relative to the actual screen’s dimensions. While this can’t be replicated with straight (X)HTML, for the most part, it is a redundant technique that actually bloats the page’s sourcecode. For this example, there are three possible outcomes:

• The code remains the same and a large portion of viewers remain unable to use the site properly (if at all)
• The code is modified to make use of a <noscript> tag with the same result URL and a target=_blank" added to the <a> tag to serve the same purpose (opening a new window), with a reduced set of functionality

or,

• The scripting is completely removed and replaced with the same method of placing a target="_blank" in the <a> tag

Unfortunately, all of these have their drawbacks. Option one (leaving the code) shuts people out from the content you have to offer; Option two bloats your code considerably (particularly on pages with a lot of links, eg. image galleries); and Option three kills the overall functionality of being able to place windows, et cetera. So which method is the correct method? While all three work, the final option tends to be the best. It not only keeps page sizes down, but it doesn’t shut viewers out from the content either. The sad reality, however, is that option one tends to be the first. When this is true, the only real hope for people who are “unsupported” is to scour through lines of sourcecode to figure out where the URL is actually leading. Now, as an intelligent web coder, you don’t want this to be the case with your pages, do you?

Sadly, the same is true of applets. While applets are needed to making content rich (movies, soundclips, games, et cetera), they should not form the cornerstone of the entire content. These generally come in two forms: The Flash-based site, and the Flash-rich site. Don’t get me wrong, Flash is a great little tool, but as with everything, it has a time and a place. Recently, the trend of the internet has been to code websites entirely in Flash and leave that as the only entryway for browsers. Cool trend? Maybe. But, when you’re unsupported, the view of nothing but a blank page causes one to either want to claw their eyeballs out with a rusty spoon, or, to claw the developer’s eyes out with a rusty spoon. And as a general rule, Flash tends to be massive in terms of loadtimes and download required to even begin to use the content. For this, there are also a few remedies:

• Continue to use complete applet-based content (and once again shut people out)
• Use appleting where absoltely needed (eg. movieclips, et cetera)

or,

• Eliminate the use of applets completely

This time, the most extreme of the solutions probably isn’t the best step in terms of offering dynamic content. Completely eliminating it from your content, while making your site available to more people, greatly reduces the drawing power of your site. Well, when you are offering videos as your main theme, et cetera, anyway. In this situation, some appleting is acceptable to allow the inclusion of rich content. What is not, however, is either using an entirely applet-based interface, or, even more painingly worse still, using clientside scripting to set the options to link a new window to set options for an entirely applet-based interface. Don’t laugh, it happens more than most people would care to aknowledge.

As a general rule of thumb: If the peice of code is mandatory to making the site work, make it as functional for a wider range of platforms as you possibly can. This means applet-based menu systems (for example, Java applets to control menus) are a no-no, and use of scripting to do what (X)HTML and CSS can (and even stay valid in the process, no less) is another no-no. If I see another applet-based navigation system that does nothing more than the afformentioned can achieve, I think I may well scream.

And now, one of the biggest, ugliest, and silliest functions of clientside scripting: Clocks. Clocks are everywhere, almost everywhere we go, in fact. Also, most modern operating systems that utilise a GUI have a clock located somewhere in immediate view virtually all the time. Why does there need to be a big, ugly, script-based one in the middle of content? If you want to echo time in a way that is simple and doesn’t distract the eye, go serverside. PHP’s date() function (or time()) will achieve this nicely. ASP’s <%response.write(time())%>. function will do the same. Simply put: if you must, don’t do it clientside.

Clientside isn’t a bad thing; It’s something which should be embraced openly by developers the world over. It has the potential to makes function easier and more controlled, which at the end of the day is a good thing for both parties involved (development and user). And I can’t completely write it off anyway, this site actually uses a script to make the little tags that POP up over titled elements look prettier. But, that said, it reverts to the default display when scripting is turned off, so no harm done there. Here’s a rule that will help produce better content and better accessability for a wider range of people: If it’s not mandatory to making the site work, it’s not needed. The occasional enhancement here or there is nothing to begrudge, but as has been stated many times already, there is a time and a place.

Clientside scripting is a very powerful tool in the right hands. It can make life simpler and more user-friendly, thus heightening the end-user’s enjoyment of your content. There is a time and place to make it work its magic, and a limit on how much to use. Are your hands the right ones, or those of an ignorant developer (intentional or not) who hinders their viewer’s ability to use the site? Hopefully the former.