Beginning the Process of Writing Scripts

Approach your first script the right way by planning, implementing and then testing it properly. Walk through a simple (yet a step above "Hello World"), detailed example to build a solid scripting foundation.

This chapter is from the book

Over the first two chapters we have taken a look at JavaScript and how it fits
into the Internet picture. We have given you insight into what you can do with
the language and how it works with XHTML, and have talked about browser support.
We have approached the language from a coder's perspective by helping you
understand the tools you will need to get started.

Now we are going to tackle the task of writing your first scripts, which is
what excites us all. We are going to keep it simple for a specific purposeto
build a solid foundation on good programming practices. We will cover each step
of creating this simple example in detail, so that we do not have to cover the
longer examples in as much detail later in the book.

To do this, we are going to approach your first script the right way. By the
right way, we mean that we are going to plan the script, implement it, and test
it properly. While doing this, we will also remind you of some of the things
you learned in the first two chapters.

Initial Decisions

First, remember that JavaScript is embedded into XHTML documents by using the
<script> element. As the browser is loading the page, it begins
interpreting the code, starting with the first line of the script and processing
everything that follows until it reaches the end. This is true whether the code
is inline or it is pulled from an external library (.js) file.

JavaScript interprets each line of code into instructions it then uses to
perform specified tasks. It is the same as following directions to a party, for
example. Just as you would read each instruction and act on it by turning or
driving your car in the appropriate direction, JavaScript follows each of your
instructions in order.

On your way to the party, you might need to stop at a red light, or you might
need to pick up a friend. These types of rules you can also emulate with
JavaScript. For instance, you may want the browser to sit idle until some kind
of event, such as a mouse click, happens.

Before you even start writing your code, you do have to make some initial
decisions. These decisions will help you better understand what you have to do
and how to write your code. The following sections will step you through this
process with the objective of helping you understand the questions you should be
asking yourself that ultimately lead to the creation of successful code.

What Browsers Do You Want to Support?

The first question you need to ask is, "What browsers do you want or
need to support?" This is a huge question because it will determine how
much code you need to write. As we said previously, JavaScript has changed
drastically over the first several versions of the language. So it is important
to know what syntax is available to you when writing your scripts.

In fact, the language had a tendency to be all over the map until the
ECMAScript standard was released. Because ECMAScript defines only the core
portion of the language, however, it still leaves a lot of gray areas in
client-side and server-side implementations. Because of this, you are going to
spend a substantial amount of time trying to write scripts that work in all
browsers. Hence the question, "What browsers do you want to
support?"

In deciding what browsers you want to support, there are several factors that
can help. They are as follows:

Do you have server-side functionality to help you determine the browser
before pages are returned to the browser?

Do unsupported browsers need to fail gracefully?

Help from the Server Side

If you are able to determine the browser making the request, you have a major
advantage when creating client-side JavaScript programs. This allows you to
avoid potential client-side errors by not sending code that is not supported.
This is especially key because many of today's popular browsers have
different versions that support different standards.

True, it might mean that you need several versions of your scripts, but the
amount of download time for the browser and the chance of error will be greatly
reduced. You are no longer sending code to determine the requesting browser
because the excess lines needed to perform "client sniffing" are no
longer needed. Having this functionality also allows you to better handle known
non-supporting browsers gracefully.

Failing Gracefully

The second question has to do with how gracefully you want to handle
non-JavaScript browsers. This would include not only browsers that do not have
JavaScript support, but also those that have it turned off.

CAUTION

If you have ever taken a look at the preferences of your browser, you will
notice that you can turn off JavaScript. See Figure
3.1 for Mozilla 1.0's Preferences dialog box, where you can turn
off JavaScript. This is important to keep in mind, because you will need to
be able to handle instances with JavaScript turned off gracefully. To do so,
simply treat these instances as browsers that do not support JavaScript at
all.

When asking yourself this question, you need to understand your true
objective. Are you building a site that you want all people to access and get
the full experience? Maybe you are developing an intranet for a company, and
your users will only have one browser. Or you may just be building a sample site
to see what you can do with JavaScript.

By going through this exercise, you are determining the type of restrictions
that need to be placed on your users. Be sure to make this decision carefully
and with the full understanding that leaving out some people may mean leaving
out a percentage of potential users. If you have made the decision not to
support users who do not have JavaScript enabled, your task will be a bit
easiersimply do not provide secondary XHTML for these users. Otherwise,
you should try to provide them with as much functionality as possible with the
intention of not compromising your content.

How Do You Want to Handle Non-JavaScript Browsers?

Up to this point, we have not talked about how to actually handle browsers
that do not support JavaScript or have it turned off. If you have the ability,
you can eliminate some of your worries by using the server-side functionality we
spoke of earlier; however, this does not solve the problem of those browsers
that have JavaScript turned off. But there is hope: the <noscript>
element.

The <noscript> element allows you to specify additional XHTML to be displayed
when JavaScript is turned off or not supported. This element and its included
code usually go directly under any <script> sections you may have. Listing
3.1 shows how you can use this element, and Figure
3.2 shows how this is rendered in Mozilla with JavaScript turned off.

If you look at Listing 3.1 and Figure 3.2,
you will notice that the <noscript> section tells the user that JavaScript
is turned off. If it were turned on, this same page would interpret the JavaScript
code and ignore the <noscript> section, as shown in Figure
3.3. This is a great tag to help handle non-supporting browsers gracefully.

Some of the older browsers, such as Navigator 2 and early versions of
Internet Explorer, do not support the <noscript> tag. We have
also seen problems with using this tag multiple times on a page with older
browsers that support JavaScript, but have it turned off.

Inline or src It?

The final question you need to ask is, "How do you want to put it on the
page?" The question is a determination of where you want to put all of your
code. This can either be in external library files that have been included using
the src attribute, or directly in the document itself.

As we mentioned before, by placing your code in an external file, you will be
able to edit one file to affect scripts on all of your pages. Additionally, if
your code contains the characters < or &, it will not properly validate
if you are attempting to create valid XHTML documents. Although this is not a
problem for most implementations today, the momentum XHTML has in the market,
from a standards perspective, could easily make this a requirement in the near
future.

We recommend that you put all of your functions in external source files,
which solves these problems. We even recommend you split up functions into
separate files according to their functionality. For instance, you might have
one file called calculations.js that contains reusable calculations, but another
file called formhandling.js that contains form handling functions.

NOTE

The src attribute was not supported until JavaScript 1.1, which
means that Navigator 3+ and Internet Explorer 4+ support it fully. Additionally,
Internet Explorer 3.02 did attempt to support this method of referencing
external scripts, but we have had limited success in getting it to work. The
good news is that these older browsers represent only some fraction of 1% of
users, although we do feel it is important to point out this information.

What Are Your Objectives?

The process of defining objectives is among the most overlooked steps in
starting a project. You would expect it to be the first and most thorough step,
but often it is not completed successfully or fully. We have all seen many
JavaScript programmers approach a script from what we call the cool angle rather
than the functional angle.

JavaScript is definitely "cool," and if the cool factor is your
main objective, go for it. However, if your main objective is to provide solid
and useful functionality, try to avoid excess and unnecessary coding. In the
long run, other programmers and even you will find it hard to follow your code
if you have a lot of "cool" features that offer no real value. You
will also find it difficult to implement changes and fixes, because you will
have to program around your cool code.

When defining your objectives, you fully determine your objectives and
ultimately the end result of your program. For instance, you may want it to
perform error checking on forms. With this goal in mind, you should work
backward to determine what will accomplish this goal. Using the form example,
you should ask yourself how many elements are going to be in the form? How many
are radio buttons, text fields, selection options, and so on that you want to be
able to process?

After you have nailed down this second level of objectives, you can start
figuring out how to code your scripts. You will want to write code that handles
the radio buttons, text fields, and selection options. You may be able to create
a function that will cover all the functionality you need and that simply works
from a parameter passed in, such as "radio" to signify the handling of
a radio button. Remember that code reuse is a good thing and that you should
apply any coding experience you have to reducing the number of lines of code
your scripts need.