HTML and Javascript HTML and Javascript

A weird revelation on Javascript/HTML programming.

I have been working recently to learn HTML and Javascript in order to put up a web site, and, frankly, because it is fun. I spent 15 years working professionally as a programmer after six or so as an amateur. I did it because it was fun and addicting. I got out because it consumed me.

That said, I got totally faked out. HTML is the language used to lay out web pages, including, I am sure, this one here. Javascript is what makes web pages fun. It is essentially embedded in HTML. Javascript is not the only language (or script) that you can embed in HTML, just by far the most common. Thinking back, in 1999 (at Bull), I learned Java the same way.

In any case, the way things work is that to some extent the way things work in HTML is that basic layout is done in HTML. But HTML is static. So... you use a scripting language, such as Javascript (or Java), to generate HTML dynamically. You just write out HTML, which is then interpreted by your browser for further layout. While you are at it, you can also play with the HTML you have already generated using the DOM, which is/are standardized data structures and routines made available for just this purpose (DOM in Mozilla and IE based browsers are slightly different, but close enough that you can easily write scripts that work with both).

In case you are wondering, Java and Javascript are quite different, though Sun has their hands in both. Java is somewhere between Javascript and C++, which is what most of the real executable code on Windows machines is built using. C++ of course is an Object Oriented version of C, and C was a stripped down version of Algol, etc. Unix was originally written in C, and C was originally developed to write Unix. I think that the way it worked was that then Java was developed by Sun to be an interactive or interpreted C++. Finally, Javascript is a stripped down version of Java.

I should add that my professional programming experience moved from FORTRAN to assembler to an Algol derivative to C, with the last half using structured programming languages, and at least the last third using C almost entirely.

The reason that this is relevant is that the C roots in Javascript are obvious - too obvious. We will get back to that shortly. Blocks in C and Javascript are delimited by "{" and "}" compared to "begin" and "end" in Algol/Pascal. Similarly, both the later use ":=" for assignments, while the C family uses just "=", but all also implement "+=", "-=", etc., missing in Algol/Pascal. C++, Java, and Javascript follow C in the more obvious areas closely - such as flow-of-control commands, assignments, etc. In other words, if you look at C, C++, Java, and Javascript code, it all looks superficially very much alike. Algol (60) and Pascal look fairly similar to each other. The big difference between the various members of the C family is how variables are handled. Very crudely in C. (You can cheat to your heart's content in that language). C++ is just the opposite. It is extremely highly typed (and Object Oriented). Variable types need to be extensively defined before they can be used.

The point then is that it is very easy to slip into my old C programming mindset when writing Javascript in an HTML document. They look the same. They have most of the same constructs. In both, you are pretty much using built-in variable types, instead of going through the object oriented stuff in C++.

But there is one very critical difference that I forgot about because of these simularities. C code is compiled before it is executed. Javascript is interpreted on-the-fly by your browser. In C, it doesn't really matter where code is located, since it all must be compiled before it can be executed. In Javascript, it is critical.

So, my problem. I have been using Javascript to interact with the DOM (Document Object Model), and thusly, with the HTML. But it has been flaky. Sometimes I can't find things I know should be there, and sometimes I can. Has been driving me crazy. I am used to a system where when you create a structure, for example, it is always there at the same place. Always. This sometimes stuff was blowing me away.

And then, this morning, the revelation. My HTML documents, as do many, if not most, these days, consists of a mixture of HTML commands and Javascript. The Javascript is embedded in the HTML between <script> and </script> delimiters; Some of my Javascript is put in the <head>section</head> of HTML, while the rest goes in the <body>section</body> .

So, I essentially have a HTML program. I used HTML to set up the user interface, but the heavy lifting is done in Javascript. After all, I am a C programmer by heart. Try 90/10, Javascript/HTML. Since the HTML was an afterthought - similar to COBOL or PL/1 pictures in my mind, I put it where it was convenient. Since it was an after thought, I put it at the end. After all the important Javascript stuff.

But I couldn't find the HTML Forms I had included in the HTML from the Javascript code. I knew they were there. I just couldn't find them. I should add that this HTML program that I have been working on is a dynamic HTML debugger. It allows you to essentially interpret an HTML document in one frame or window, while showing trace data consisting of DOM table dumps in a second frame or window, under control of a third frame or window. Why anyone would want a tool like this is another story.

In any case, the reason that what the HTML was for is relevant is because it meant that I had available (already included into my document) functions to dump all the relevant DOM tables. So, it was a simple matter to just include static calls to them (the purpose of the program is to provide them dynamically). And I ultimately discovered that the critical Document object for the Control frame/window did not have links to the missing Forms when dumped during startup, but did when dynamically dumped shortly thereafter. This was driving me crazy. What was wrong with my program?

And then the light went off. I had put all of my Javascript code up above the Forms in my HTML Control document, because, well, why not? BUT when I was executing the startup Javascript, my browser(s) had not yet gotten down far enough in the HTML to interpret the Forms HTML. So, of course, I couldn't find the forms - they hadn't been created yet. But since my dynamic debugging used the buttons which were the purpose of (and result of) the HTML Forms, those exact same HTML forms were visible to the Javascript at that time. Because they existed during dynamic debugging. They had to - I was using them to invoke the table dumps. But they hadn't been created yet when the program was starting up.

The solution is, of course, obvious. Don't try to access the Forms (or any other HTML) until created. Two solutions. The first was to wrap my startup code into a function called by the ONLOAD handler for the HTML Body (or Form). The better one is probably to just put the startup code invocation AFTER the HTML Forms in the HTML cource code.

I know. This all sounds obvious. But it is a result of accidently making implicit assumptions based on my previous experience as a programmer.

Finally, a note. While I was writing this, I realized that it is kinda slick, using my HTML debugger to debug itself. In particular, using the buttons I couldn't find to find out why I couldn't find them.