Adding JavaScript to HTML – Best Practices

To embed JavaScript within an HTML page, use the script element:


In earlier versions of HTML, the tag’s type attribute was required, and should have a value of text/javascript. That’s no longer the case in HTML5. If you’re using an older version of HTML, then do use type.

The JavaScript code is then placed between the opening and closing script tags. When the browser loads the Web page, it will execute the code found there.

Alternatively, the JavaScript code can be stored in an external file that will be included by the HTML page using the script element’s src attribute:

<script src=”path/to/file.js”></script>

The path/to part needs to be accurate, but the path can be relative to the HTML page or absolute (see the following sidebar).

It’s still common for small pieces of JavaScript to be written directly within the HTML page, not in a separate file. But as your JavaScript code gets more complicated, or as it’s repeated on multiple pages of a Web site, it makes more sense to use external files, where the JavaScript code is easier to maintain. When you use an external JavaScript file, that file can just begin with the JavaScript code, without the script tags (because those are HTML tags). Conventionally, external JavaScript files use the .js file extension.

A side benefit of using an external JavaScript file is that it can be cached by the user’s Web browser. This means that if multiple pages on a site use the same external JavaScript file, the browser will only need to download that file once.

There are five more things you should know about using script. First, as with most HTML elements, you can use multiple instances of script within a single HTML page. In fact, you commonly will.

Second, each use of script can present inline JavaScript code or incorporate an external JavaScript file but not both. If a single HTML page needs to do both, you’ll have to use two instances of script.

Third, if you’re using strict XHTML, you’ll need to wrap all of the JavaScript code within CDATA tags, which leads to some awkward and ugly syntax:

// Actual JavaScript code!

Relative vs. Absolute Paths

A common point of confusion, especially among beginning Web developers, is the proper way to reference other files and folders. There are two options: use an absolute path or a relative path. An absolute path begins at a fixed and consistent point, such as the root of the Web site. In HTML, absolute paths always begin with either http://domain/ or just / (replace domain with your actual domain, such as Therefore, the absolute path to the index file in the Web root directory would be http://domain/index.html or just /index.html. An absolute path to file.js, found in the root directory’s js folder, would be http://domain/js/file.js or just /js/file.js. The benefit of using an absolute path is that it will always be correct, regardless of where you use it: An absolute reference works and is the same for index.html in the main directory and for somepage.html in a subdirectory.

A relative path is always relative to the HTML page making the reference and will not begin with either http:// or /. To begin a relative path, you can start with a file name. For example, another.html is a relative reference to the file another.html, found in the same directory as the current file. To create a relative path to a file found within a subdirectory, start with the subdirectory’s name, followed by the name of the file (or by other subdirectories as needed): js/file.js. Some people prefer to begin relative paths with a single period and a slash, the combination of which represents the current directory. Thus, ./another.html is the same as another.html, and ./js/file.js equates to js/file.js. To move up to a parent directory, use two periods together. For example, if page.html, in a subdirectory, needs to include file.js, in the main directory’s js folder, the correct relative path would be ../js/file.js: up a directory and then into the js directory.

Relative paths can be harder to get right, but they continue to remain accurate even when files and even entire sites are moved (so long as the files retain the same relative relationship).

The technical reason for this is complicated, but it has to do with how data within script is parsed in XHTML. The <![CDATA[]]> wrapper prevents certain entities from causing problems. However, because [CDATA[]] is a parsing indicator and not JavaScript, both the opening <![CDATA[ and the closing ]]> tags must be prefaced, on the same line, with the JavaScript comment combination (//). You only have to do this if you’re using XHTML and have JavaScript written within the script tags; this isn’t required (or recommended) for HTML, including HTML5, or when the JavaScript code is in an external file. I’m just mentioning this, as you might see it when looking at other people’s code.

Fourth, it’s common to place script elements within the HTML head, but that’s not required. In fact, many current developers advocate placing script elements near the end of the HTML whenever possible. Yahoo!, for example, recommends putting script tags just before the closing body tag. The argument for doing so is that it improves how quickly the page seems to load in the browser. This is because when the browser encounters a script tag, it will immediately start downloading that script (assuming the script is not already cached). The browser will not be able to continue downloading the HTML, and therefore display it, until the script(s) have downloaded.

Finally, try not to use too many external scripts in the same HTML page. Doing so will also hurt performance.

This entry was posted in Business Booster e-Tricks. Bookmark the permalink.

Comments are closed.