Why SSI?

When I came up with the extremely vague idea of adding a navigation bar to my site, I looked at the various ways of doing it and eventually decided on SSIs. The choices I had, and their pros and cons are thus:

Hard code the navbar onto every page

Arggh! Now this just sounds stupid from the offset, doesn't it? (Doesn't it!?) If I ever want to change the navbar, I'd have to make the same changes to each page in the site. Not my idea of fun.

Put the navbar into a frame

This appears to be the standard way to do this kind of thing. The advantages are that it would be easy to maintain (just the one file would need to be changed), and the navbar would stay on the screen all the time.

Disadvantages are that some (not many) user agents can't display frames, so I'd be cutting out some of my prospective audience. Also, its very easy to create a bad frameset so that bookmarks don't work properly and the user can never be sure about where they really are.

Use a client-side scripting language (VBScript, JavaScript etc)

I was tempted by this, but they all involve learning new syntax, and although that's not normally something I shy away from, I didn't really feel like learning lots of new stuff to do something as simple as a navbar. I'm also quite wary of relying on such methods, as they usually involve allowing users and/or thieves to read your source code.

Use a server-side scripting language (SSI, ASP, JSP, etc)

I like the idea of server-side scripting. The results are just plain HTML which any user agent should be able to understand. It also allows the developer to keep his secrets safe, by hiding the source away on the server, away from prying eyes.

I chose SSI because its syntax is very much like that of HTML. All you need to do is put some special comment-like directives in and bob's your uncle. SSIs do put an extra strain on the webserver, but if you can notice you're a better man than me.