At work we have recently been researching various web frameworks to replace our aging cocoon/SOLR solution for the majority of our websites. Cocoon has served us well for our TEI based websites, but it is getting in the way of implementing newer features. I’ll have more on the research part of this later, but in this post I wanted to talk about templating.

In an MVC framework, the views are often done in some kind of client site template. The Comparison of Web Application Frameworks page on wikipedia has a nice overview of the different frameworks and whether they do templating. Some frameworks have their own templating language–for instance, Django has Django Template Language. Some use one of many independent templating languages such as Haml, Smarty or Slim). Some use straight code in the view (php, eruby, ejs).

I prefer the latter approach to views. Below I will list a few of the arguments for views and my counter argument. Note that these arguments are for the specific setup I work in: a small shop (two programmers, one designer developer) where everyone does a bit of everything.

Templates are necessary to separate concerns

Templates might help to separate concerns, especially in a larger shop, but in our case, I think this could be accomplished with a few rules, a bit of discipline, and some oversight (code reviews).

Also, while I agree it is best to try as much as possible to separate concerns, web applications are messy, and sometimes data needs to get thrown around a bit more than we’d like. As an example, suppose you are in a sub view and want to set a page title/some other bit of text to be inserted into the main template view (the HTML wrapper). In Ruby on Rails you can do this by setting a variable (since the views are in eRuby) and that variable is available in the HTML template. In a strict MVC Framework you’d set the page title in the controller, but that doesn’t make a lot of sense to me either since this isn’t page logic. This is a bit of a forced example but you can start to see the issues.

In some other examples I have seen, all forms are written in the controller and passed on to the view since there are handy form builders available for the language, but they are not available in the templating language. This sort of makes sense, since the forms are concerned with data, but at the same time, great rich UI demands a lot of control over the look and feel of forms, so it just makes sense to build forms in the view.

Views don’t need programming concepts

This is false, as evidenced by the amount of programming concepts that end up in templating languages: variables, for loops, if/then statements, functions. To be sure, some templating languages cut out almost all of this, but it seems like working with these to build any kind of really rich UI would be unnecessarily difficult, and the amount of logic and variables you’d have to pass through from the controller would threaten to unbalance the MVC in the other direction by forcing stuff that’s really a UI concern into the controller.

Templates are easier to remember/work with/look at

This may be the case for other shops where the designers work separately from the programmers, but as a designer/programmer, I’ll be moving between the view and the controller frequently, and it would add a little bit of friction to have to switch my brain between two ways of doing things. Every time I want to add a variable or do a simple for loop, at least for a while, I’d need to look up the correct way to do it for the given context.

As for looks- well, you might have me there, depending on the language. eRuby is pretty nice looking, as is the embedded javascript I have seen in examples. PHP is pretty ugly, though. In the end, I care more about the function of the code than what it looks like.

A few advantages of templateless views

• quick prototyping
• letting students hack at code without giving them too much leeway with the system (and then later folding that work back in correctly)
• quick testing of code
• experimentation

To be sure many of the above can lead to messy code. But I think experimentation is as important in our context as getting the separation of concerns exactly right.

What I prefer is a system that allows a choice in templating system or embedded language. Even better would be to allow that choice on a view by view basis, so we could have, say, a subset of views that use a simple templating system but embedded language in the rest for complex UI building.

I’m still at the beginning of this thought process, and as such, would love to hear other thoughts about why I should consider templating (or shouldn’t be too concerned with it).