Tech Support Section Home Mekong Network Home
About This Site...
Mekong.Net Sites...
Recently Updated...
Recommended Links...
Contact Us...
Questions? Comments? Requests? Click here to contact us.

The Mysterious Javascript Includes

Old map of Indochina

by Bruce Sharp

If you've arrived at this page, you've probably been doing one of three or things:

The first of those three options is probably the most common, and we'll talk about that at length in a moment.

First, however: Those of you who were visiting Mekong.Net might be wondering what you were missing by having disabled Javascript. The short answer? Not very much: just some links and navigation aids.

Since this page is here, however, I'll take this opportunity to briefly discuss the oh-so-fascinating technical aspects of Javascript includes, "noscript" tags, and other minutiae.

Javascript Includes: The Good, the Bad, and the Ugly

What are includes? And why should we use them?

An include is a section of a web page that draws its content from another source. The idea is simple: if several pages will use the same content, that content can be stored in a single location. Each page using that content will grab it directly from the file.

As an example, suppose that we want to include a copyright notice at the bottom of every page in a website. When the new year rolls around, we want to update that copyright notice. If we inserted the date on every individual page, we'd have a truckload of changes to make; but if we keep the copyright notice in an include file, we'd need to change only that one file to have the update appear on every page.

Include files are usually handled "server-side." With a server-side include, the webserver handles the task of extracting the contents of the include and inserting it into other pages.

Unfortunately, there are some down sides to this method. First, different webservers use different file suffixes for includes. That means that if you're using a Microsoft IIS webserver, you'll probably be using .asp or .aspx files. If you are using Apache, you'll probably be using .shtml or .html files. That means that if you want to port your site to a different server platform, you're going to have to change page names... and that will likely also mean that you'll have to change all the links within those pages, too. Not a pretty prospect.

There is one other annoying aspect to relying on server-side includes. If you want to preview your pages locally, you'll need to have a compatible webserver running on your development machine. After all, server-side includes don't work when there isn't a server.

Alternatively, you can rely on "client-side" includes. With a client-side include, the web browser is reponsible for managing the process of getting the data out of the include file and inserting it into the webpage.

Recent versions of the major web browsers have the ability to handle client-side includes in a way similar to the behavior of server-side includes fairly closely: that is, they have the ability to insert the complete contents of a file, exactly as written. There is a good article at that discusses the use of client-side includes, using either Javascript or iframes.

I prefer a slightly different approach: I use Javascript to render the text I want to display. Scripts which execute on the client can be embedded in the code within a web page... but they can also be executed from separate files. By storing the script in a separate file, we can reference the same script from any number of different pages. The script contains nothing but Javascript "document.write" commands to write the desired text into the page. In this way, we can effectively mimic the behavior of an include file.

Here's an example of what I use on this site. First, a script tag like that below is inserted into the appropriate location in the page:

Then, in the "linklist.js" file, you'd have this:

This method has some drawbacks, however. First, compared to writing HTML directly, it's a little more difficult to write the text into a document.write command. That's because you'll need to escape any special characters in that occur in the text. An example would be a single quotation mark: if you don't precede it with the escape character ("\") your script is going to break, and your text won't display. There is a list of Javascript special characters and escape sequences at

Another drawback is that search engines will not index text within scripts. For that reason, you should avoid putting critical content in the scripts.

On this site, the text stored in the Javascript includes is not terribly important; I use it mainly for a little boilerplate text here and there, and for the list of links to other site and pages. Does it really matter if your links aren't indexed by search engines?

Well... it matters a little, though probably not to you: Instead, it matters to the webmasters of the sites you are linking. Systems such as Google's Page Rank are based in part on the number of other sites that link to a particular page. Links rendered by a Javascript include are invisible to Google. Most webmasters also find it mildly interesting to see what sites link to their own, and many search engines have the ability to locate referring links. Again, however, links from within scripts won't show up.

One way to address that is to use a "noscript" tag to provide alternate content for users (and search engines) who can't use the scripts. Content enclosed in a "noscript" tag is rendered only if the script is not executed. By placing a link to an alternate page (like this one) within the "noscript" tag, the search engine can spider the page, and register the links. Users who don't want to enable Javascript, meanwhile, can see what they're missing.

There is one other minor consideration involved in using Javascript includes: as with any Javascript, if you preview files locally, later versions of Internet Explorer will disable the script, and will pop up a warning asking whether or not you want to let the script execute. It's possible to disable that behavior by adding the local file system to the trusted sites, but I don't recommend that. It's a security risk. Moreover, by leaving the warning in place, you'll have a chance to see whether or not your "noscript" tags are working correctly, since IE should display that content until you allow the script to run.