Thursday, March 6, 2008

To Template Or Not To Template

Since developing the tutorial in the last few posts, I have been working on developing a real web app in Haskell with HAppS. Now that I know my way around the basics of HAppS, I need to move on to generating actual HTML (as opposed to the plaint text messages that the tutorial used). Before starting, I had to decide what methodology I would use to generate the HTML. I'm new to web development, so I may be missing something, but as I see it there are three main possibilities:

  1. Serve static pages that use AJAX to load dynamic content
  2. Dynamically generate pages with Haskell and HAppS
  3. Use Haskell to populate static page templates with dynamic content

Let's first take a look at the last option, static templates. Most of the web frameworks that I've seen (ROR and several Python frameworks) use templates. The main argument for them seems to be that templates allow a separation (MVC style) of the view and controller. The page template defines the view and the Python code is the controller. This allows a nice separation between the work areas of the web designer and the programmer. The web designer works with the template, and the programmer works with the code. This is very appealing. HAppS does not have templating built in, but there is a Haskell library called HStringTemplate (based ond the Java StringTemplate library) that will work.

The second option is to avoid templates and use Haskell code to generate HTML. Mixing HTML strings with Haskell code could be ugly, but the Text.HTML or Text.XHTML libraries can be used to make generation relatively painless. The advantage here is that you have more of Haskell's power available at the HTML creation level. This can be used to create better abstractions that can eliminate repetition. It also can eliminate the need to keep variable names synchronized between a template and the code. This gives you better compile-time guarantees of correctness.

Many will argue that these benefits come at the expense of requiring the designer to understand Haskell code. However, after looking at sites like CSS Zen Garden, it seems to me that most of the designer's work can be done in the style sheet. This means that you can generate you can use an external style sheet in haskell-generated HTML and still avoid the need for the designer to understand Haskell. If this is the case and the HTML is carefully designed to properly represent semantic chunks, it seems like it might even be beneficial for the coder (who has to know about page semantics anyway) to generate the HTML.

Now let's look at option #1. The main page on advocates this approach. HAppS does not come with a server-side templating system. We prefer the pattern of developing static web pages and using AJAX to populate them with dynamic content. I think this is similar to how GMail works. You send one static page at start up that has JavaScript code that makes requests to the server for dynamic data and then does whatever transformation is necessary to display the data on the page.

This approach also allows for good separation of the work of the designer and coder. Additionally, it could reduce the bandwidth requirements for the site because the boilerplate code only has to be transferred once. After that only the dynamic data needs to go across the wire. And since the page is being built on the client, it should reduce the server's CPU load as well. This also makes it easy to separate static content from dynamic content. In a system like this, you could even use HAppS for dynamic content while serving static content with a completely different server like Apache or Lighttpd.

Because of my limited experience with web design, I think I will go with option #2 to start out. I like that it allows me to take advantage of Haskell's functional structures to aid in HTML generation. Since I don't use a graphical HTML tool, templates aren't a high priority. I think the AJAX approach would ultimately be a good one, but I've already got plenty of work cut out for me without adding JavaScript and all it's browser compatibility issues to the mix.

I'd love to hear readers' thoughts about these three approaches. Is there a significant benefit to page templates that I'm missing? I hope to learn more from readers who have more experience in this area.

Sunday, March 2, 2008

HAppS Demo

Several people requested that I post a link to a running instance of the HAppS code that I developed here over several posts. One person was nice enough to actually offer me the use of a server. So the demo is now up and running. It's not at all meant to be user friendly, since it's just a demo of the basic HAppS capabilities. So here are a list of links that are useful. Hopefully this will be useful.