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:
- Serve static pages that use AJAX to load dynamic content
- Dynamically generate pages with Haskell and HAppS
- 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 happs.org 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
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.
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.