Creating a reusable header and navigation bar


One of the first design challenges I faced when making my own web site was how to create a web site template. In other words, for each of the pages on my site, I wanted a navigation bar and a header that always stay the same, and a large content area that is different for each page. This seemed like a straightforward problem that should have a straightforward solution. But it turns out that there are many ways to make a reusable web site layout, each with their own pros and cons. What I really could have used when I first started making websites is a good overview of all the different ways I could make a template for my site. But I did not find one, which is why I am writing this tutorial now.

This tutorial is not about how to use HTML tables and/or style sheets to create a detailed professional quality site layout. There are plenty of great and in-depth resources available on the internet and in your local bookstore that discuss this topic in depth. I would recommend as a starting point and CSS 2.0 Instant Results as a finishing point if you are looking for specific techniques to position content on your page. Instead, this article emphasizes how to reuse a site layout if you already have one.

The Problem

Let's assume you have made a single web page - your home page, and this home page is laid out like a large scale and more professional looking version of this:

My Website




Welcome to my web site

Now, for each of the links in your navigation bar on the left, you want to create a separate page in the main area. The perfect solution to this problem is one that would satisfy the following conditions, in order of importance:

  1. Your solution does not negatively affect the user experience (bookmarking, navigation, refreshing, using old browsers or portable devices, etc) .
  2. You only have to write the navigation bar and header once. So if you make a change to your navigation bar or header, all pages using them should change automatically.
  3. Designers can easily view and modify your template using visual tools.
  4. Your solution follows solid engineering principles - like separating the site's presentation from its contents to ensure it is easy to modify in the future, or adhering to web standards to ensure the solution works in past and future browsers .
  5. Your solution works no matter what tools/software you are using to make your site.
  6. Your solution allows you to keep each part of your site in a separate HTML file. Specifically, the main area pages you make do not include HTML for the navigation bar and header.
  7. You may optionally reuse common parts of your site. For example, if you want a navigation bar in the sidebar as well as the footer, you would only need to define your links only once.
  8. For the sake of efficiency, only the main area of the page reloads when you change pages. The rest should stay the same.

Unfortunately, I have yet to find a solution that satisfies all of these points, and I seriously doubt that such a solution exists. So, the best we can do is look at some solutions that come close. I will introduce these solutions one by one, starting with beginner level solutions and gradually moving up to more complex ones.

Solution #1: Frames

See this solution in action


Frames are a basic HTML feature that can divide a web site into several parts. They seem at first like a basic and elegant solution to laying out your web site, but beware - this technology is flawed and antiquated and mainly covered for historical reasons. The best way to visualize how frames work is if you imagine each part of the site - navigation bar, header, and main area - as a separate window. This visualization should reveal some of the biggest disadvantages of this method, as you will see in the 'cons' section.


To create a reusable web site layout using frames, you need to take the following steps:

  • Create a separate html file for each content page (in this case - home, contact, and links)
  • Create a separate html file for each rectangular section of the site that does not change (in this case - navigation bar and header)
  • Create a template page. This a short html file that uses frames to lay out your site into a header, navigation bar, and content area.
  • For every link that you use, you need to specify that the link opens in the content area of your site .

See a complete walkthrough, including sample code


Frames are by far the easiest method to learn and use

In just a few lines of HTML, we can create not just a site layout, but a reusable one. It just doesn't get any more straightforward than this. This is a huge advantage to cut the amount of time you spend making your site. It is also good because keeping the solution short and simple means your site will download faster.

Frames use basic HTML

Because frames use only HTML, the most basic web technology available, it means that they play together nicely with all kinds of web development software. So you will not run into any compatibility issues if another engineer uses different web development software than you or a designer wants to edit your site. This is another way in which the frames method distinguishes itself from its competition.

HTML is clearly organized

Notice how every piece of information is in a separate file, and especially how there is never any piece of HTML that shows up more than once.

Frames use partial page updates

Whenever you open a new page, the navigation bar and title bar are not reloaded. Only the contents of the main area are sent to your browser. Though this is not a key feature, this behavior is very hard to find in other solutions. Typically when you browse the web you will refresh either the entire page or nothing.

The list of benefits for using frames is actually quite impressive. But don't get too excited - there are a lot of drawbacks as well!



External linking does not work

NOTE: it's highly recommended to experiment with the demo or look at the complete walkthrough to fully understand this part.

Let's say you wanted to email someone a link to your contact.html page. Which URL would you use? If you point them to contact.html, they will get ONLY the contact page, without navigation bar and header. This is a good thing - we generally don't want to copy the navigation bar and banner to every single page because doing so is wasteful and can lead to maintenance problems. But which URL do you use to direct the user to the contacts page? The only other viable option is to use index.html, the page that creates the navigation bar, header, and content area. The problem is, because of the way frames and browsers work, this page will always just have your home page! So there's really no URL you can use to specify your contacts page. To understand this, you need to look at the site from your browser's perspective. Your browser starts with index.html (see complete walkthrough) and, because this file uses frames, the browser thus sees your site as a collection of 3 differently named areas ('navigation', 'header', and 'content', in this case) and nothing else. This never changes. Sure, the contents of the main area change, but this unfortunately doesn't affect the site as a whole. Your site as a whole is still the same collection of frames, and will still look just like index.html to the browser. So, in short, the URL for your site is always index.html, no matter which page of the site you are looking at!

Bookmarking does not work

Let's say you wanted to bookmark the contact.html page. This will not work. For the same reason that external linking doesn't work, you would always end up bookmarking your home page, even if you are in the contact or links subpage.

Refreshing does not work

If you click on the navigation bar and reload the page, only the navigation bar reloads. The main area, which is probably what you wanted to reload, does not. Again, think of your 3 frames as behaving like 3 windows when imagining this scenario. If you clicked on one window out of 3 open windows, then issued a refresh command, you would refresh only the window you selected, not the other two inactive windows.

Frames are deprecated

Because of the aforementioned issues, frames have become deprecated, which is an engineering term meaning officially obsolete. This means that future browsers do not need to support frames. So if you are unlucky some new browser version could come out and cause your site to fail. It also means that if you are working on a more advanced web site that serves dynamic content like user comments or search results, you will most likely not be able to use frames. This is because sites with dynamic content use XHTML instead of HTML, and XHTML does not allow you to use features that are deprecated. Finally, the last disadvantage to using a deprecated feature is that serious engineers will tease you and make fun of you, and for good reason.

Frames are hard to read for machines

Remember, your browser only sees your site as the short contents of index.html instead of seeing all the beautiful content you put in the various areas of your site. This can seriously hurt your site's google ranking, because it makes your site harder for a search engine robot to browse. It could also be an issue if you have blind or disabled users that are more reliant on the browser's view of the site than you are.

Frames use fixed positions for your site areas

When you use frames, your header and navigation bar stay in the same place even if you scroll through your site's content. This is unlike standard site layouts where the navigation bar and header scroll down along with the content area. This could actually be a big advantage if you are absolutely sure that this is the behavior you want. Sure, you can get the same behavior if you use more advanced techniques like the absolute positioning feature of your style sheet, but it will be far more difficult to get this working right. Especially if you want a liquid page design (i.e. you want your content area to resize properly if the user resizes his browser window). But in all but basic site designs, fixed positioning is not the behavior you want. For example, if you have a footer or if you have a sidebar that is higher than the height of a window, fixed positions are a bad idea.

Frames break separation of presentation and content

This is a pretty moot point compared to the others, but one more disadvantage is that frames are a slight violation to the design principle that presentation and content should be separate. This design principle says that your html files should store only your site's content, and any information relating to how your site looks should be stored outside of your html. The reason for this principle is to facilitate making changes in design, and also to make it easier for designers and engineers to work together. But when you put frames in your html and use code like <frameset rows="100,*">, you are violating this principle because now your html (instead of your style sheet) stores the size of each of your site's areas.

The Verdict...

Frames get most of our engineering requirements right. Unfortunately, they also flagrantly violate a sacred rule in web development and business: thou shalt not piss off thine users. For this reason alone you should use a more thorough solution instead! Because of their poor usability, the web development community has cut off support for frames as well, so now developers and designers will also frown upon you and call you bad names you if you use frames. This solution was acceptable in the past, but is no longer considered a real solution today.

Solution #2: Dreamweaver Templates


If you decided to use Dreamweaver to design your web site, you are in luck. Dreamweaver has a feature called templates that was specifically made to solve our problem. To use this feature, all you need to do is create a template page and attach this template to each of your content pages. Dreamweaver has good examples and documentation to walk you through the details, so I will give you just enough details to get a feel for how they work.


To make a web site layout and reuse it across all of your content pages, you will take the following steps:

  • Create a new html template (this is one of the built-in options you get every time you decide to make a new file)
  • Create all of the content that you want to reuse across all of your pages. In this case, this will be the html for the navigation bar and header as well as the html or style sheet you used to create the layout of your site.
  • Mark all of the parts of your site that can change from page to page as editable regions in your template. You will need at least two editable regions: your content area and the page's title.
  • Create a separate html file for each of your content pages
  • For each content page, apply the template you made earlier. This will automatically add a header and navigation bar to the page. You will also go through a simple user interface where you specify which part of your new page goes into which of your template's editable regions.

As you can see, there is a bit more manual labor involved in setting up templates for the first time. But the process is straightforward and user friendly, and you only need to do this setup once for each page. For more advanced users, you can also create templates from other templates, so it's a very flexible solution as well. Overall, this is an adequate solution, but like any solution it has its benefits and drawbacks.


Easy to use once set up

Once you set up your template and apply it to all of your content pages, you may never need to worry about templates again. If you make a change to your site's template and save it, all the content pages that use this template are updated automatically. Also, if you look at any of your content pages in Dreamweaver, you will see them with the navigation bar and header added on, just like a user would see them.

Very designer friendly

I'm no designer, but I would guess that this is a web designer's favorite solution, assuming the designer is a Dreamweaver user. The reason is simple: this solution was made by and for Dreamweaver, a software that specializes in the design side of web development. So it integrates flawlessly into any and all design features that a Dreamweaver user would use.

Uses basic HTML and style sheets

Dreamweaver templates use pure HTML to create your site. You will not need to learn any programming or do anything on your web server for this solution to work.


The solution is proprietary

Dreamweaver templates are made specifically for Dreamweaver. They use a Dreamweaver specific .dwt file extension and inject your html with Dreamweaver specific tags. So, if you are working together with people who do not own Dreamweaver, you could run into trouble. This is by far the biggest drawback of using Dreamweaver templates, but it is also not as bad as it sounds. Dreamweaver makes sure to comment out the Dreamweaver specific tags, and a .dwt file is just an html file on the inside, so you can still view Dreamweaver templates and files created by them even if you do not own Dreanweaver. Also, if you apply a template to a page, the html of your template gets added to your page (so, for example, your contact.html page would have the html for your navigation bar and title bar included in it). This means that if you create a web site using Dreamweaver templates and share it with non-Dreamweaver users, these users can still see all of your site and modify most of it without any problems. The only thing they will not be able to do is make a change to the site's template and apply it to all pages. In other words, they can change the site's content areas, but not the navigation bar, header, or common areas.

Poor directory structure

There are some minor things that annoy me about how Dreamweaver templates work from an engineering perspective. My biggest qualm is that Dreamweaver templates MUST be in a 'templates' subfolder. Using magic file or directory names like this is just plain bad design. But it is especially bad for Dreamweaver templates when you consider that within your template file, all relative paths that you specify to link to other files are relative to the template folder, not relative to the web site's folder! What this implies is that your site could behave differently if you are looking at the site's template than if you are looking at the actual site. It also implies that to get both your templates and your sites working properly, you will have to jump through some hoops. You will either have to copy whatever files your template uses into the templates folder during testing (a dangerous idea, since you now have duplicate data) or set up all of your file paths so that they work from the templates folder as well as from the actual site. Ugh!

Cluttered html

I'm not very happy with what Dreamweaver does with my site's html. First of all, it actually adds the html for the navigation bar and header to ALL pages that use them, so I end up with a lot of duplicate html. This was arguably a necessary design decision to make it possible for non-Dreamweaver users to see the results of your Dreamweaver-created templated site, but it also has drawbacks. First of all, it clutters up my html with duplicate information, making it noticeably harder for me as an engineer to find my way around the html code. But it also has more practical implications. Imagine that you have two web sites - like, oh say, a business and a personal web site. Also imagine that you have some content that should be on both web sites - like, oh say, your contact information and some video game demos. But, since you are using Dreamweaver templates, instead of having one html file for these common areas and applying different headers and navigation bars to it depending on the site, you now need to have two separate copies of the same data. Another bump in the road is that if you attach and remove a template from a page, the new page will still include the templated content (navigation bar and header). To add insult to injury, Dreamweaver's approach of copying your navigation bar and header to all of your content pages is unusual and incompatible with other templating methods. So once you decide to use Dreamweaver templates it is very tedious to turn back.

On a different note, Dreamweaver templates also put some commented out proprietary tags in your html - things like ' <!-- InstanceBeginEditable name="doctitle" -->'. This is completely harmless, but it makes the site just a smidgen more difficult for engineers to sift through and understand.

Somewhat tedious initial setup

There is a bit more upfront work in setting up Dreamweaver templates on your site for the first time. This is especially true if Dreamweaver makes automatic decisions for which part of your page goes into which content placeholder and gets something wrong. I often find myself attaching a template, checking the result, and making manual corrections when I want to apply a template to a page.

The verdict

Dreamweaver templates are an adequate solution to creating a reusable site layout - that is, if you have made the decision to use Dreamweaver and stick with it! They have some minor issues, but overall my only real qualms are that this solution requires Dreamweaver and that it adds your site template to every page. If you are new to making web sites and not yet familiar with working on the backend / server side, Dreamweaver templates are probably your best bet.

Solution #3: server-side Scripting using PHP


So far, all of the solutions we have discussed are client side solutions. This means that we created and saved html files that represent entire web pages. In the case of using frames, we had an elegant modular solution where we created a small html file that defined places for us to show several other html files. In the case of templates, the end result is that we have a navigation bar and header duplicated on all of our individual html pages, but we used an efficient tool to do this.

There is a better way to make html pages, though, if you take the next step and start controlling how your web server handles your files. The idea is simple: you do not give html files to the user as is. Instead, you store individual bits and pieces of your web page and write a script to piece them together. Specifically, you will create one html file for the parts of the site that don't change (header + navigation bar, i.e. your web site template) and one html file for each content page (home, contact, links). Also, just as with frames, your content files have only the site's content, excluding common areas like the header and navigation bar. Typically, if you would request the contact.html file from the server by navigating to the contacts page, it would just serve the contact.html file as is - without navigation bar or header. But if you use server-side scripting, you can override this behavior. You can get the server to take your contact.html content, take your template page containing the navigation bar and header, and cobble them together into a single web page in a way that does not break the user experience like frames did. So your server automatically creates a complete web page from bits and pieces every time a request is made and sends the results to your browser. This complete web page is nowhere to be found on the server's hard disk - it is recreated on the fly somewhere in the server's memory every time a request is made. That way, if you change any of the html files representing parts of your web site, the whole site changes automatically.

The simplest approach to assembling web pages on demand is by running a script on the server. There are many languages for making such scripts. The one presented in this solution is PHP, since that is the scripting language I am most familiar with, and also arguably the most popular one.


To create a reusable web site layout using PHP scripting, you will need to:

  • Create a template html file that has all the reusable parts of your site (header and navigation bar, in this case)
  • In the parts of the template that need to change from page to page, add some minor PHP to just output a variable. For example, you could define TITLE as a variable that stores the page title for each content page, and CONTENT as a variable that stores the contents of each content page.
  • In each of your content pages, add a few lines of PHP code to the beginning and/or end of the file to attach the page to your template.

See walkthrough with sample code


Powerful, flexible solution

PHP is a powerful scripting language, so using PHP to make your templates gives you a lot of options that you would not have with a simple HTML based solution. For example, you could define a lot of settings for your site in variables (width/height of each major area, default values and selections for forms, etc) and automatically generate the appropriate HTML or style sheets. You can also use templates to store common logic instead of just common design.

Simple and easy

This solution uses only basic HTML and PHP, and the PHP used is basic, short, and easy to understand. Any PHP developer should quickly be able to pick up this method, and designers should be able to understand the resulting web page with little extra effort.

Minimally invasive

This solution does a great job of not disturbing the site's HTML. The template file just has some trivial PHP statements sprinkled into it. Unlike other solutions, this solution does not add any unusual HTML elements or comments to your HTML - just clearly marked php directives. In fact, I noticed most software tends to gray out php statements when you are editing HTML to make the php even more unobtrusive. Also, on the content pages, we just add a few lines to the beginning and end of the file. We do not make any changes at all to the actual HTML in these pages.


Requires PHP

This solution is only for PHP developers, so if you are using anything else to develop your site, you are out of luck. Also, since this solution involved adding PHP to all of your content pages, switching to another templating solution would be tedious.

Cannot see templates with contents while designing

This solution is slightly designer-unfriendly because whatever software you use, you will most likely not be able to see the content pages with the navigation bar and header added on while you are making changes to the site. To do so, you would need a design software that also executes PHP, and I do not know of any such software. A designer could, however, design the template and contents separately, and use a browser to see them together. Since designers should frequently test their designs in a browser to ensure that they work properly, this seems like a pretty reasonable concession to make.

The verdict...

The bigger question is not whether or not to use PHP templates, but whether or not to use PHP. If you have committed to using PHP, then you may as well use PHP as a templating system, since this will give you more power and flexibility than any solutions that do not require programming. Beware though that the lack of built in support for designers could be a substantial drawback. Using a simple templating system like the one shown in this article would be fine if you are working individually or are using a premade template. But if you were working on a large project in a team with specialized designers, you would want your own templating system that can work with whatever format the designers use as well as the format you are using in your PHP. But, as is usual in the open source community, you may either write your own templating system from scratch or pick and choose from a variety of free open source solutions and customize them to your needs.

Solution #4: ASP.Net Master Pages


server-side scripting is a great solution if you are using an open source environment, like developing for Linux servers. But what if you are the Microsoft brand of engineer and are using Windows servers? As usual, Microsoft has its own way of doing things. The Microsoft way of creating reusable web site templates is called Master Pages, and is part of a large set of features that Microsoft's ASP.Net platform makes availabe to all Microsoft web developers. This is conceptually very similar to server-side scripting. The differences are that you are using a real programming language (C#) instead of a scripting language, and that, also as usual, Microsoft has already made a feature for you to make your life easier. This feature is called Master Pages, and looks like this:


To create a reusable site layout using ASP.Net master pages, you need to take the following steps:

  • Create a new master page (by just selecting it from a variety of new file types you can add to a web project in Visual Studio). A master page behaves just like any other web page.
  • Put your navigation bar and header into your master page.
  • Mark the parts of your site that change from page to page (like your page title and content area) in your master page file by surrounding them with an <asp:ContentPlaceholder> tag.
  • For each content page, attach the master page by referencing it at the top of your page.
  • For each part of a content page (in this case, page title and page contents), associate that part of the site with the appropriate part in the master page by surrounding it with an <asp:Content> tag. A content tag must reference the name of a content placeholder that you defined in the master page.


Master Pages are easy to use

Part of Microsoft's strong suit is that if you use their web development software (visual studio or visual web developer), they will go out of their way to make your job as a developer as easy as they can. There is a rich set of features to support master pages using visual drag and drop tools. Or you can type in the above code yourself and get outstanding feedback from your code editor to make sure you don't make any mistakes (features like giving you a list of autocomplete dropdown lists of commands as you type and highlighting typos and errors as you type). So developer-friendliness is where Microsoft really shines.

Master Pages are very powerful

Master Pages allow for some very sophisticated development, since you are leveraging the power of C# and ASP.Net, which are very powerful programming tools for developing software and web applications. You can also make a master page from another master page, so you can create a whole hierarchy of templates for large projects. Best of all, you can use an unparalleled number of different user interface controls (like menus, drop-down lists, form validation, etc, etc) that Microsoft made for you. And since you are using a real programming language, you have pretty much unlimited options for how to respond to a user's input. So, if you program your pages well, you will have a common place not just for reusable sections of your web site (header, navigation bar, login, footer, etc), but also for reusable programming logic (identifying users, handling errors, navigation, etc).

Master Pages work together nicely with other Microsoft tools

Since they are part of a very wide array of Microsoft technologies, you can do a lot with master pages from inside your visual studio / visual web developer environment. For example, if you attach a master page to another page, visual studio's designer shows you the entire site contents and lets you modify it with a visual interface. This is very similar to what Dreamweaver does when you use Dreamweaver templates. The notable difference is that Microsoft does not actually add the html of your navigation bar and header to all of your pages, which I think is a good thing.

As a Microsoft developer, working together with other Microsoft technologies is all the compatibility you need. It's a mixed blessing. On the one hand, you are not using open standards and cannot use this solution on other platforms like Java or Linux, so the solution has compatibility issues. On the other hand, Microsoft has more technologies for you to choose from than you could possibly put to good use, and they work together VERY nicely, so Master Pages are extremely compatible with a wide variety of other technologies. Besides, choosing a development platform like ASP.Net is a bit different than using a design program like Dreamweaver. Once you choose a development platform to work with, you are expected to stick with it (for a variety of good engineering reasons), so it is OK to pick tools that are catered toward your particular development platform.

Many people know how to use Master Pages

Because .Net is a very widespread technology, it will be relatively easy to find developers that can use .Net technologies like Master Pages.


Master Pages are only for Microsoft developers

The only way to use Master Pages is to commit to becoming a Microsoft developer, and thus using not just ASP.Net, but using Microsoft brand technologies for almost everything. This may sound very scary if you have had bad experiences with Microsoft user software (like Word, Windows, Outlook, Internet Explorer, etc), or if you were a Windows programmer in the olde days, before the .Net framework was created. But, as a former Microsoft hater, I have to honestly say that they have done a killer job when it comes to making their .Net based development tools as programmer-friendly as possible. I am especially blown away by Visual Studio's debugger (especially if you're debugging something that takes place on more than one machine, like, oh say, a web application). But I am also very impressed by visual studio and the .Net framework in general. In stark contrast to the Windows development days of the past, this time around Microsoft really went out of their way to give the programmer as much helpful feedback as possible, from helping programmers write code quickly and detect errors while typing to providing excellent help and documentation. In fact, I'd go as far as to say the Microsoft .Net technologies are the most programmer-friendly development tools I have ever seen.

Master Pages have a steep learning curve

Master Pages per se are a very simple concept, but to really use them efficiently, you will have to also get familiar with the .Net framework. And learn a new programming language (C#). And a new development environment (visual studio). And possibly a new database management system (SQL Server), operating system (Windows Server), web server (IIS), version control system, etc, etc. In other words, you will need to learn a lot of other Microsoft web development technologies. Then again, more people are familiar with these Microsoft technologies than with open source technologies. So if you have a lot of knowledge in Microsoft technologies, this point is actually an advantage for you, since you will be able to leverage your existing skills.

The verdict...

Master Pages are both easy to use and extremely powerful. This decision is a no-brainer - if you happen to be a .Net developer, then by all means use Master Pages, as it is the best technology for your platform and has more options and features than you could possibly put to use. If, on the other hand, you are not a .Net developer, you have no choice but to use something else. So the real question is not whether or not you should use Master Pages, but whether or not you should use ASP.Net. This is one of the biggest questions in the world of web development, and the cause of many holy wars among devout programmers defending either the Microsoft, Java, or open source ideology.

Solution #5: Templating Software


In case you are ready to bring out the big guns, there is a wide variety of sophisticated specialized software made specifically for templating your web site. This ranges from small templating solutions like TinyButStrong to large products like Smarty. I have not used any of this software myself because I have not had the need for it, so I cannot write too much about it.

The verdict...

It is generally said that templating software is very powerful but complicates matters because it introduces an additional technology to learn. As a developer, features like ASP.Net master pages already give me all the power I would ever need, so I never found the need for this extra complication. I might consider this solution if I were a designer, especially if the design software I typically use has poor or no template support. I would also consider this solution if I am working in a team and I find a templating software that meets some very specific need, like being able to convert between a designer friendly format like Dreamweaver templates and a developer friendly format like PHP templates or Master Pages. If I were a PHP developer who frequently deals with design issues (like a user interface developer, for example), I would also look for software that can edit my PHP using a visual interface, similar to the design views in Dreamweaver or Visual Web Developer.

Bad Solution: Javascript Templates

This is a purely theoretical idea that no one uses in reality for practical reasons. Still, I thought I would mention the idea of using JavaScript to create web site templates because it certainly seems like a viable option in theory if you are not yet familiar with usability issues. In fact, I remember contemplating this solution myself when I was starting web development and had no experience with Javascript or knowledge of its usability.

The general idea is to create Javascript code that would generate all of your site's contents for you. So, for example, you could write some functions that create the navigation bar, header, and content, and have these functions use Javascript's DOM (document object model) features to automatically write the contents of your site. I'm not going to go into a walkthrough or any details on how to write such Javascript because using Javascript templates is a bad idea, so I'll just leave it at the conceptual level.


A client side solution with endless flexibility

Javascript, because it is a programming language, gives you a lot more options than you would have if you just used html. The possibilities are endless. You could automatically create different sites depending on which browser your user is using. You could define some variables, like the widths and heights of your site's areas, and have your Javascript automatically create the proper web site contents based on these variables. You could personalize the page according to the individual user. You could even do things like define in detail what happens when users resize your site (for example, you could theoretically set a minimum and maximum width and height for each element in your page to make sure it behaves just right when the user resizes the window), something you would not be able to do with even the most advanced server-side technology. In short, you would be able to do most of the things that you could do with a professional server-side technology like PHP, Java, or ASP.Net, and even some things that you cannot do with any of these technologies. And you would be able to do it all in the client's browser, without the need to consume resources on your server, or to set up a complicated and expensive development environment, or to learn professional grade technologies with a steep learning curve. Sounds like the greatest thing since sliced bread, right? Wrong!!


Breaks site for non-Javascript users

Users have the option of disabling Javascript in their browsers if they want to. They may do so for security reasons, or they may do so because they just hate popups or other interactive web features that mostly annoy users. As of 2008, 5% of users do this, though the rate fluctuates and has typically been over 10% in the past. For this reason, it is a widely accepted design principle that you should never require Javascript in order to run your site! If you used Javascript to lay out your site, then users who do not have Javascript would get an empty screen. Losing 5-10% of your visitors may be OK for your personal web site, but for any commercial web site losing a few percent of your paying customers to your templating solution could cost you millions and is just unacceptable.

This solution would be VERY slow

Javascript is not meant to do large tasks like create an entire web page. Also, a particularly slow part of Javascript is updating a page's Document Object Model, which is what you would do a lot when you are constructing the web site from scratch. This is not only because Javascript is slow at making changes to your site, but also because your browser is slow in responding to these changes. Think about it this way - if you have a fully loaded web page, and you add a single picture to the top of it, then your browser would have to update the entire web site by moving everything down on the screen. If the browser updates up to the entire web site every time you add a single item, it could get overwhelmed very quickly.

This slowness assumes that you are programming your Javascript in a straightforward way. There is actually a wide assortment of advanced techniques that you could use to attempt to get rid of the speed problem. You might use AJAX to update only the content area and keep the rest of the site unchanged. You could use the little-known OnDomReady event to run your Javascript before most of the site is output to the screen. You could write a custom function that parses the entire site structure in a single run, as opposed to searching the entire DOM tree every time you want to find or modify something in the site. You could go out of your way to write highly optimized code, and maybe, just maybe, your performance would be acceptable. But I'm not making any guarantees here. Which brings me to my next point:

Engineering skills are put to better use on the server side

Even if you had the advanced engineering skills needed to make a fast, usable Javascript based site template, it would not be worth making it. Because if you use those engineering skills on the server side by writing Java, ASP.Net, or PHP code instead, you would get better results. Javascript was not made for complex tasks - it is far slower, has far less features, and has far less development software and tools than a full fledged programming language does. So if you use a server-side programming language instead, you will get better results in less time.

The verdict...

The fact that users who disable Javascript can't see your site at all should in itself be more than enough reason not to use this 'solution'. Also, you are much better off if you save your advanced programming skills for the server side instead of squandering them on abusing Javascript to do things it was not designed for. So, although it at first seems like a great idea on paper, using Javascript for site templates is unfortunately impractical in the real world.

Appendix: Using Professional Templates

Creating a basic web page layout like the one shown at the top of the page is easy. But creating a beautiful and professional looking web site layout that works well across all browsers can be a very daunting undertaking, especially if you are short on artistic skills or knowledge about browser compatibility issues. I should mention, though, that there are easier ways to make a great looking web site than to do everything yourself. No matter which technology you use, there are many, many designers who have made great looking templates that you can modify and reuse for free or for a small fee. Personally, I think the basic design on this site is more than adequate for a personal web page, but if I wanted to make a site to take Amazon or Yahoo by storm, or to showcase a flashy new product, I would definitely get a professional quality template made by someone with more artistic skills than myself., for example, features a plethora of extremely high quality templates for all kinds of technologies and web sites.

Back to web development demos