What are the perks and drawbacks of using html templates versus building the html in-code [closed]

Question

As far as I can see there are two ways of building a html page: "inside" the language (I'll call it building for lack of a better name) or outside the language (using templates). Let me explain a bit what I mean by this before I jump to the questions.

Building

One way is to build the html page "inside" the language you are using, using preferably in-language constructs (not just by concatenating strings), and converting these constructs to html in one last step.

A really good example of this is Clojure's hiccup library, which uses the Clojure maps and vectors to represent the html. This allows one to use the full power of the language one's working in to manipulate these structures.

Templating

The second way is to write the html separately from the main program and use some kind of template DSL to insert logic into the templates. The hamlet package for Haskell is an example of this.

Now my question is: what are other advantages and disadvantages of both approaches?

---

I'd love to get more acquainted with these concepts so pointers to articles etc. are more than welcome. Also please inform me if there is another approach I didn't think of.

---

Summary of answers so far

Pro templating

• It's easier to separate the view from the rest of the code. The code will be easier to maintain and you avoid mixing business logic with the rest of your code.
• This approach generally is much more accessible to people with less technical skills.

Con templating

(none so far)

Pro building

• Functional languages, make it easy to write declarative code natively so a template language is not required.
• You can get all the power and flexibility of your programming language, and still get the benefits of a declarative syntax.

Con building

• Designers/clients are bad at your preferred logic language.
• It still boils down to hard-coding the page into codem just that it is not separate template code.
• Has more power, that could be used inappropriately. You have to take extra care
  to separate view code and business logic.
• In ideal cases it is faster though.

Answer 1

Template languages provide a declarative syntax, which is much less error-prone for this particular use case than an imperative syntax. In other words, you're specifying what the end result looks like rather than step by step instructions for how to build it. That's why template languages are so popular when the back end is written in a more imperative language.

On the other hand, functional languages, especially in the Lisp family, make it very easy to write declarative code natively, so a template language is not really required. You can get all the power and flexibility of your programming language, and still get the benefits of a declarative syntax.

However, if you have more power, that tempts you to use it inappropriately. You have to take extra care to separate view code and business logic, or else you will end up with something very difficult to maintain.

The other huge drawback is some of the best designers are not very good programmers. Even a lot of good object oriented programmers get lost in functional languages. If you want to work with those designers without a workflow where they always hand off an HTML file to a programmer for transcription, then you probably want to stick with a dedicated template language.

Answer 2

If you are working with a team, it is very helpful to use a template and breakout the html from the code. By separating the two, different people can work simultaneously without interfering.

It is also nice for working with contractors or employees with different skills. We OEM our product to customers and this allows more freedom for customization.

Answer 3

It is a good idea to break the representation from the data in any case. It is not made clear explicitly from your question if this is what you want, but my guess is that it is what you're pointing to.

I'm not familiar with the precise implementations you've mentioned, but generally speaking it can de handled as follows:

If you roll your own, then you have more control over how you deal with your input. In the Clojure examples it is shown that does some pre-formatting for you, but judging by the examples it still boils down to hard-coding the page into code, with some flexible fields for easier and more consistent response management. It is still something that requires some skill. In ideal cases it is faster though. The downside is that it's much more tempting to sneak in code that should be separated from your representation, fading the distinction between the two.

If you use a true templating engine, the page becomes data that's interpreted before being shown. It's something that can be stored as data, and which is independent of the rest of your design, save for the code hooks that you've defined in the data. These hooks need to correspond with code that you've made available. This approach generally is much more accessible to people with less technical skills, as long as they know how to interface with your code. (see it as learning how to use a new version of HTML vs learning how to program in some functional language) Because this approach takes more interpretation, it can be slower.

I generally favour the latter approach, as it forces you to make a much cleaner separation between code and representation. This forces you to carefully consider what you're doing. I think it leads to better design overall.

Answer 4

When talking about generating ("building") HTML vs. using template language one thing always pops into my mind: separation of concerns i.e. separating the representation ("view") from the business logic.

I'm always in favor of using template languages:

• It's easier to separate the view from the rest of the code. The code will be easier to maintain and you avoid mixing business logic with the rest of your code.
• Designers will often know some template language but very few designers will know Clojure or Haskell.
• Templating languages are often very easy to learn and very good at creating the presentation layer.

By building HTML in the code you can certainly be more flexible and use the whole power of the language, but you will need to be more careful to not mix the business logic and the presentation code.

To compare it to other (non-functional languages): Microsoft created XAML as a language to create the presentation layer (WPF, Silverlight) and always recommended to use the XAML (not code-behind to create elements).