BashGXD is the system I use to generate most of the xHTML pages of this web site. It is based on Gnu Bash and Gnu Make, and now some Objective Caml...
The purpose of this system is to allow you to build your pages in XHTML 1.1 [that is described by this DTD (Document Type Definition)], using some "templates" (or "containers") to generate the final files. Unlike Apache/PHP system that generates some dynamic pages, this system generates mostly static pages that take no CGI arguments.
The first good point of this system is the security matter: whereas dynamic pages can introduce security holes, especially if the script language is reflexive, generating static pages can't introduce this kind of security hole.
The second good point is that it saves bandwidth. Let me explain. If you use dynamic generation, the default behaviour is to send as a response to each request a newly generated page. Well, if that page is different each time, you don't have a choice but use a dynamic system. But if you keep sending the same page, you will have to check at the generator level if the page is the same or not as last time, and then send the good http header. And if you use static pages, you don't have to deal with that.
The third good point is that the static pages are generated! That means that you don't entirely write them by hand. Most of the rendering job must be done by scripts, which is the purpose of BashGXD. BashGXD allows you to generate the pages only when you need to (re)generate them.
A forth good thing is that staic pages don't need to be generated each time they are asked. If you use PHP or another dynamic system, and want to simulate this, you handle caches so that pages are partially static and take less generation time... So you save time and CPU time...
Okay now one bad point: today it's not possible to make a good web site without dynamic treatments of requests. It's totally necessary to use CGI applications (which can be in php or perl or other, it doesn't matter) to handle the data submitted by the visitors. So BashGXD will soon integrate some dynamic stuff... :-/ (actually there is already a little bit of that but it was done specifically, so it can be used for BashGXD as it)
Another bad point: you need to know XHTML (very) well, or at least be ready to learn it, because it's unusable if you don't want to write in XHTML. Even if it's really quite easy to use to me (as I designed the system), it may be really hard to someone that doesn't deal with Makefiles, and bash. About the use of Objective Caml, for the moment it's only to write external generic programs, so it's not necessary to know Caml at all.
A third bad point is that it's really not WYSIWYG at all. Well it's not a bad point to every one. So while people are using their brains to make easy-to-use-WYSIWYG editors, I am designing a system that has nothing to do with such systems. Hey WYSIWYG tools are often very useful and I do use them. But not for websites, it's too "hard" to handle them "efficiently". I don't want to use my mouse to write a post in a blog: I just want to write the text and ask for it to be published, not clicking a thousand times before I get to the right page to finally write the post with the risk it disappears because the web browser has crashed. So I use (Carbon) Emacs because it's an efficient text editor. Of course BashGXD doesn't depend on Emacs. You can use VIm as well, or gedit, kate, kwrite, and even Microsoft Notepad! It doesn't matter as long as you have make and bash (and Objective Caml...) (and several gnu utils, such as sed). Well, it doesn't mean that I haven't used nor won't use WYSIWYG tools to build web sites. It just mean that I won't do it for my own web site...
Now that I've built several pages with this "tool", I can tell that it's quite efficient for what I do, except for the blog: it's a little bit "slow". So in December 2006, I started adding some Objective Caml programs, and that adds one more dependency. Soon I'll add some data handlers...
For the moment, there is no JavaScript... Nothing prevents me to include some JavaScript in my web site, but myself. Right now I don't want to use JavaScript. Maybe my mind will change...