I disagree, HTML is a datastructure like any other, and it should be easy to build one without going through an untyped string or an auxiliary file. It's painful to make one html file per renderable item -- and debugging takes more time (once you've found who's responsible for rendering it, you need to check the corresponding template, so there's an additional step in your way.) There's no semantic in using the filesystem to organize your templates: it's the code that specify the meaning, and your programming language provides more organization units than your FS (or should we do "one function per file and one directory per class/module"?). (Also, the obvious filename typo vs static checking of function names; and the fact that your template is going to contain some rudimentary form of code or force you to obfuscate your intent even more.)

Which is why I don't like the proposal: it's not unifying HTML and Erlang, it's compiling string macros into Erlang. Is there any reasons not to embed the interpolation in Erlang directly?

    hello(N) ->
      Name = <em><? N ?></em>,
      <#>
        <p>Hello <? Name ?></p>
        <p>The <#></#> lets you group
           multiple elements, that don't
           have a parent, as a single value.</p>
      </#>.

(Whether the <X></X> is doing simple string interpolation, or is HTML-smart is left for the reader to decide -- it's certainly overkill for server-side only code.)

> I have always found something really off putting about mixing html with programming languages. Whether it be HAML or Rails or really anything.

You could use XSL , i'm pretty sure you never do that.

Any solution that relies on "templating" involves logic in templates. And templating languages are there because they ALLOW separation of concern. A template is independent from the controller that called it. They just share a contract at the data level.

Totally agree. And actually, I find HTML in itself too verbose to begin with. Why require those close tags? So that one can see what tag is being closed? That is stupid, because in most cases, we're using just a few tags (DIV, SPAN) anyway, so this gives very little information. I'd rather use real open and close braces like most data-structures in modern programming languages.

Sometimes seeing the closing tag is rather useful for the very reason you mention, to know which tag is closing. The simple fact that once it was popular to use a comment to identify the id or class of the closed element at the bottom of a long file suggests it's a problem to consider.

But nowadays, the behavior of an element can be completely styled by CSS. So in most code, you will find a lot of DIVs. And imagine having 10 DIVs nested: you can't possibly tell by looking at the closing DIVs which DIVs they are closing... Unless perhaps you put also the classname on the closing tag (which isn't allowed or enforced or verified). So, as you can see, the closing tag has very little utility. It only makes the code less readable (as it takes space). And also, but this is secondary, it requires more bandwidth.

Well, first I would say that if somebody has ten nested DIVs then they're doing it wrong. But if the DIVs are formatted properly then it's usually not that hard to find the matching start tag. As for the class in the closing tag, that's what my statement about people putting comments with the closing tag is referring to. It's been done and was quite popular at one time. I'm willing to bet our editing tools fixed that problem simply by highlighting matching element pairs.

But in the end, if HTML went with <div></> instead of <div></div> then I probably wouldn't mind so much. But I can't agree that no closing tag is more readable because it takes less space, that makes no sense. It might look better.

I would be curious about bandwidth savings but I'm willing to bet in most cases it would make very little difference.

You just read my mind.