* Readability

* Portability

* Assists with avoiding common errors in formatting

* Generally easy to learn, with thin abstraction layers

* Enforce DOM hierarchy with formatting

* Readability can be somewhat subjective. Neither Coffekup or any of the markup DSLs I've seen are inarguably much more readable than HTML. A few extra braces to closing tags do not immediately make something less readable to me, and the example given does not seem like a clean win to me. Better in some cases, worse in others, a wash overall.

* I do not think "portability" means what you think it does. Coffeekup appears to only run under Coffeescript. That makes it rather un-portable. Many other template languages have multiple implementations in many languages. That seems unlikely with Coffeekup.

* Reducing formatting errors would presumably be because of static syntax errors caught by a Coffeescript-aware editor, and dynamic errors caught by the Coffeescript compiler and JS runtime. The same is achieved with a HTML-aware editor and various available validators.

* I don't see how Coffeekup that generates HTML is easier to learn than just HTML.

* Or screw up the hierarchy because of whitespace errors. This is just the significant-whitespace debate brought to markup. If you want significant whitespace for your markup, I'm sure there are portable template languages with significant whitespace.

I like PHP because I can wrap logic around HTML so that documents are described in document markup and code is in code.

I like Mustache because I can write a document in document markup and then pass in the variables like a MS Word "mail merge".

Using HTML means less things to learn, which is very good.

However, HTML is definitely not the perfect language. Things like HAML and Slim are attempts to make a cleaner, less verbose document language. (However, they are mixing the ideas of document markup with code, since they are trying to solve "templating" together and not just one problem at a time.) So I appreciate things like this, but I still choose not to use them unless I'm forced to.

There are places where using any DSL designed for building HTML is not that great of an idea, for example when using external template files or writing large chunks of simple HTML.

However, there are necessarily places where you need small snippets of HTML embedded inside your JS/CS code and where it's not worth creating external file for it. Then you have two choices - either have your snippet as a long string (with ugly manual concatenation if it spans multiple lines in JS), which introduces another language inside your JS file or, on the other hand, to use programmatic builders of DOM. In a context of small script this would have only advantages were it not for extremely verbose default DOM API, but this particular problem was solved many times now, for example in MochiKit[1] quite a few years ago - and now in CoffeeKup.

I use both types of generating markup - if it has more layout elements than embedded data I use external template files, however if it contains many more logic specific elements, like variables and class or id names I tend to generate it programmatically. Terseness of such approach makes modifying it easier and faster and being able to use a full blown programming language instead of constrained templating one makes it much more efficient to write in the first place.

Also, I'd like to point everyone to Nagare[2] and it's DSL for creating HTML[3] - it's pythonic equivalent of coffeekup and it's cute :)

    [1] http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html
    [2] http://www.nagare.org/
    [3] http://www.nagare.org/trac/wiki/PresentationTier#imperative-dom-building-api