Advocacy

  Myths
  Press

Dojo (HowTo)

  General
  Hack
  Hardware
  Interface
  Software

Reference

  Standards
  People
  Forensics

Markets

  Web

Museum

  CodeNames
  Easter Eggs
  History
  Innovation
  Sightings

News

  Opinion

Other

  Martial Arts
  ITIL
  Thought


JavaScript / DHTML
What is it, why did I stop using it?

By:David K. Every
©Copyright 1999


This article assumes a very basic understanding of HTML.

The Web technology of the week is called DHTML (Dynamic Hyper-Text Markup Language) -- which is basically just a renaming, and some extension, of JavaScript. DHTML has some added functionality, and uses extensions to HTML and has more features -- but the concepts are the same.

What is it?

Well what is JavaScript? JavaScript is just a poorly implemented scripting language that allows programmers (and web designers) to make web pages do certain things based on users actions. Sometimes it is used to send in a form when a user clicks on send (a useful way to use JavaScript), and other times it is to highlight a button or picture when the mouse moves over it. (you see this one a lot -- including on the previous versions of MacKiDo).

JavaScript is NOT Java! JavaScript has nothing to do with Java. Sun started promoting Java as THE language of the Web, so Netscape AND SUN decided to rename LiveScript into JavaScript to try to tag along on each others marketing. They are as related as car and cargo (which both have 'car' in their name). Special thanks go to their respective marketing cretins (and management) for forever confusing users!

In an wonderful metaphor for life on the web. I tried to cross reference their Press Release (non prime-time, on a weekend). Suns site was dog-slow, found dead-link to the release once [951204], search wouldn't work the second time (with the exact same parameters) and crashed my machine -- hard. Netscape had no references to their own press releases at all. These are the supposed leaders of the industry!

How does it work?

There is no magic to JavaScript, it is a simple scripting language, with some branches and functions (routines ) to perform simple functions. We embed this script right into the HTML page. This script gets run by your browser, and will allow for changing things, depending on what the user does (that is where the Dynamic, in DHTML comes from -- things can change).

Let me show you the basics of how to animate a button in three easy steps.

1) First we should create the button itself.

<A HREF="URL" 
   onmouseover="setImage('button1'); return true" 
   onmouseout="resetImage('button1')"
>
<IMG SRC="Graphics/navAbout.GIF" 
   name=button1
>
</A>

The <A> tag is a link, and we must fill out a URL for what it is a link to.

"onmouseover", means just that -- when the mouse goes over this object, then we call the "setImage" routine, with 'button1' as the first (and only) parameter.

"onmouseout", means just that -- when the mouse stops being over this object (it goes out of the region), then we call the "resetImage" routine, with 'button1' as the first (and only) parameter.

We also must remember to name our object the same as the parameter we are passing ('button1').

This is all done anywhere where you would normally define your HTML code for a link.

2) Next we have to implement the two functions we used; setImage() and resetImage(). 

function setImage(imgName) {
   imgOn = eval(imgName + "on.src");
   document [imgName].src = imgOn;
}
                     
function resetImage(imgName) {
   imgOff = eval(imgName + "off.src");
   document [imgName].src = imgOff;
}

The routines just sets a temp variable (imgOn or imgOff) to be the parameter we passed ("button1") and we append a string to that (either "button1on.src" or "button1off.src).

Then we call (execute) the main (document) script with button1.src set to what was in our temp variable ("button1on.src"). A little complex, but all this is just a way to set things up for the main script.

3) Lastly we have to implement the main script.

button1on = new Image(sizeX, sizeY);
button1on.src = "imageON.gif";
 
button1off = new Image(sizeX, sizeY);
button1off.src = "imageOFF.gif";

The main script creates an image for button1on (or off), that will display in the same physical place on our web page as the original item did (of the size we specify).

Then the browser sets the source (the picture) to be the image we want -- so it will change to the "imageON.gif" or "imageOFF.gif" as is appropriate.

That's it. Our image changes depending on moving over the item or not.

Steps 2 and 3 are placed between <script></script> tags at the top of the HTML document (in the <head> block) -- so that the code is preloaded before it is run. Imagine if it wasn't loaded yet, and the user moved over a button. The browser would look for code that isn't there, or only partially loaded, and there would be some ugly results.

Pretty easy stuff.

Now the example I used was a little simplified, since you should really check what Browser version you are being run on (to make sure it supports JavaScript) and so on. But you should get the idea. It is not that complex for programmers -- and even nonprogrammers can understand the basic concepts.

However, there are glaring flaws in the design.

Why it fails to work and why I will avoid it whenever possible

If JavaScript is so simple and easy, then why did I pull it out of my page?

Well there are quite a few problems with JavaScript. Let me give you an idea of some of the problems, so that you can make an informed decision on whether to use it or not.

  1. JavaScript is proprietary and Microsoft is pure evil. Microsoft didn't implement JavaScript for their browsers -- they use something called JScript. JScript is almost like JavaScript, and some scripts can run -- but many don't. Microsoft added some features, and implemented some different (some say it is better). Either way, many Scripts will only run right on one platform (Netscape or Explorer). Many other browsers don't implement it at all.
     
  2. You can't depend on JavaScript being there! I'm not only talking about all the browsers that don't support it -- and there are quite a few. I'm talking about the fact that people turn it off. Almost everyone that has ever visited GeoCities has turned it off (because of those annoying pop-up ads), and many people have security or reliability concerns. So you can't depend on it -- which means you have to be real careful what you try to do with it (because some people won't have access to it).
     
  3. JavaScript is slow. Now the scripts don't run that fast, but they run fast enough for most things -- so that is not what I'm complaining about. JavaScript slows down your entire page/site. Lets take the example of my page. I had 16 animated buttons. Because JavaScript is poorly designed, I had to implement the above code 16 times in my page -- this cause my pages to be much larger (sometimes twice as large), and size is the same as performance (the bigger the slower). It is a poorly designed language that causes such redundancy. Then I had to have multiple versions of every button image (3 of them), one for each state. Individually, the buttons were small, but loading 48 of them was a pain, and it caused peoples disks to thrash, and loading all those sub-files slowed performance even more. More complex JavaScripts are even worse, often they require large chunks of code, for very small displays, and every possible display element to be preloaded -- so users have to wait for everything to load, to see the one choice that they want. More importantly, since removing JavaScript, people keep telling me how much faster my page is.

    NOTE: I made a mistake. I thought that I had to add the same code to every page -- that users couldn't define the JavaScript on one page, and tell others to use that one instance (because JavaScript is part of your HTML file, not an additional file). I was wrong, you can in a limited way -- there is a command <SCRIPT LANGUAGE="JavaScript1.1" SRC="script.js"> that allows this function.

  4. JavaScript is poorly designed. It is a bad design that can't eliminate redundancy, and causes as many problems as it cures. Instead of being able to create text buttons that highlighted as I moved over them, I had to create graphic ones (that take more space). I was annoyed at the documentation, and the size that scripts ended up. I was annoyed by the loss of stability. All elements of bad design -- but read on, it gets worse.
     
  5. Javascript causes crashes. It will bring down the browser and sometimes the System -- and crashes (bugs) can survive that will survive a restart and crash you again and again. Why?
     
    • Microsoft and Netscape don't value stability and quality in their products. Their browsers are proof of this -- crashy monsters that they are. JavaScript is actually a language -- and bugs in something so complex as a language make things worse, but it is hard to remove such bugs.
        
    • Networks are "buggy" and introduce "noise". So sometimes text comes across as gobbledygook. So when you load an HTML page that has a script, the script can have errors in it caused by network noise. This means that when the JavaScript is run, it will crash. (A good design would have prevented this by having a special "validated" stream for the JavaScript, or sanity checking the JavaScript). It was unimportant to have noise in HTML text, but for script embedded in that stream it can be catastrophic.

      NOTE: I know in theory this isn't supposed to happen. I also know that in function, I do get noisy connections, and garbage in my web pages, and scripts, that causes the machine (or at least browser) to crash or hang. I've also recieved enough complaints from MacKiDo readers, to know that it is not a fluke with my machine.

    • Browsers CACHE (they save files locally, to your hard disk, for speed). So lets say you go to my site, and you get some noise in the JavaScript. Crash! If Microsoft or Netscape valued quality products, they would validate the Script before they ran it (sanity checking), and they would stop the script before it caused a problem. They don't, so your browser may come crashing down. Furthermore, your browser may crap all over memory or on system resources and bring your whole machine crashing down. Bad design and testing by Microsoft and Netscape -- but you get to reboot. Rerun your browser. Go back to the page that crashed you (say my old site) -- but the browser saves a local copy of the file (it cached it). The browser will try to use that cached one first (instead of reloading) -- guess what happens? It crashes again (the script is still wrong). It will continue to do so until you (the user) flushes the browsers cache, or forces a reload from the site. I was getting just such complaint, infrequently (one or two a month) -- but common enough. Microsoft and Netscape had forced me into become THEIR technical support, because they didn't design or implement a usable scripting language.

     

Conclusion

JavaScript as a concept is not bad, and there is a lot of functionality that it can add. Sometimes you need that functionality so much, that you will use JavaScript. Too bad. It will slow your site down, it may work right only on some browsers, it will cause crashes, and it will promote a bad implementation of a mediocre technology -- but sometimes the importance of that feature (function) outweighs all the disadvantages of the technology / implementation. I know that I will use JavaScript only when I can't avoid it -- and avoid it whenever I can (1).

(1) This doesn't mean that Java is better alternative, nor does it mean that CGI's can't slow your site down as well. There are tradeoffs with all the technology choices.

Now I am not advocating a "No-JavaScript" policy. I would use it for small and occasional things (where you are statistically less likely to get an error, and where it won't effect performance much). Using JavaScript on a single page, for filling out a form, or so on, is not so bad. At least problems with your site will be localized to a single page or two. However, using DHTML, which is supposed to add all sorts of little controls, palettes and doodads, to every page, is a really bad idea. On a web site, remember -- it's the content, not wizzy little features, that bring your readers back. Stick with the basics and what is reliable whenever possible -- JavaScript is neither. Notice that most content publishers don't go JavaScript happy, Netscape uses it sparringly throughout their site (except for their annoying homepage), and Suns site seems to use it even less -- instead opting for more Java, and more crashes. So don't go feature happy. Think about what your viewers want more, think about the tradeoffs, and think if they want to pay for a little animated buttons with their browsers running slower, machines crashing (occasionally), or other obstructions to their browsing experience.

JavaScript Resources

Created: 3/13/98
Updated: 11/09/02

Top of page
Top of Section
Home