I get the feeling you've never really used HAML, because this is a load of FUD. I'm going to respond primarily with HAML, because that's the whitespace-significant template language I have the most experience with.
> Writing plain old HTML is fucking simple. Abstracting it out into another 'language' just means you have to deal with a whole load of quirks and workarounds you'd never see with HTML, and while it looks all purdy and shit to some, it's an absolute nightmare to maintain.
I've maintained a lot of older projects, and the closer the templates are to HTML, the worse they seem to be. I can't count the number of times a DIV is left unclosed, or a TR is closed by a function call, or a P is nested 20 levels deep in a one-line monster tag. HAML and other whitespace-significant template languages prevent all that. You can't leave a tag unclosed in HAML, it closes them for you; because it closes them for you, you can't close them in weird and separate places; finally, because it forces you to have a newline before each tag, it looks really obvious when you've created a huge nested mess of HTML.
> Want to nest elements? Either you can't,
Wrong. Nesting elements is dead simple in HAML:
%ul
%li
yields
<ul>
<li></li>
</ul>
> some syntax has been introduced to discourage it (the end of line pipe),
The end of line pipe is for when you have very code that goes with a single element. From the docs:
Usually, though, this should go into a helper, because your templates shouldn't have that much logic in them.
> or you're told to just... use plain HTML.
This makes me think you don't know what you're talking about. Again, it's easy to nest elements in HAML. You wouldn't drop to HTML just because you want to nest elements.
> Want to interpolate variables? That's probably built in, which is great until you try changing it back to plain HTML, and then have to scan for all the interpolation, which is now plain text.
Of course it's "probably built in," interpolation is core to any templating engine. Interpolation is dead simple, as well.
%ul= some_variable
I'm not sure what you mean by "turn it back to plain HTML." At what point can you turn any template language back to plain HTML without having the interpolation be a problem?
> There's likely so much focus placed on "one-lining" everything that you have to do silly things just to actually make the template readable, when it wouldn't be a problem in HTML.
Do you have any examples of this? In my experience, whitespace-significant template languages do more to discourage one-line operations. Instead of doing this:
<ul><li></li></ul>
you're forced to break it up into multiple lines:
%ul
%li
> Never mind the total lack of portability and, especially these days, requiring a copy of Node just to run the damn things. Which is fine until you realise you shouldn't need to add a full on javascript VM to your development dependencies.
I've never used a template language that didn't require some programming language to evaluate. Usually they require the language that the entire project is being built with; e.g., HAML assumes you are writing a Ruby project.
There are a lot of framework tools that require some sort of precompilation, too. If you're building anything reasonably complex, you're probably going to want to be able to split your files out into smaller chunks, which means using something like Less/SASS for CSS and require.js for dependency management. All of those have external dependencies. Or do you really not care to compile your disparate JS and CSS files into a single download?
> That so many of these attempts at 'HTML templating languages' exist is probably testament to the fact that no one agrees on what one should look like.
Isn't that a great thing, though? Diversity in this means the technology hasn't stagnated.
> They've actually been staring it in the face all along: plain old HTML.
I have no idea what you are suggesting with this point. What does HTML actually offer as a templating language? There's no built-in variable interpolation, no built-in template segmenting (e.g., rendering a partial), and no built-in control structures (loops, conditionals, functions, etc.). Once you've added all that in, you either have another template engine that requires something like node.js to precompile for performance reasons, or you have a mess of spaghetti that only the creator knows how to maintain.
I've used HAML and Jade a fair bit, and I've also had the joy of converting them back to HTML. I've experience the opposite to you, where we've had a much easier time with plain HTML than a specific abstraction of it. I've also had the joy of taking HAML and turning it back into HTML. It's no fun.
To clarify the nested tag example, using an unordered list fails to take into account the other methods of nesting elements in HTML:
%p This is a paragraph with
%strong emphasis
inline and maybe a
%span dynamic portion of the text
%p This is a paragraph with <strong>emphasis</strong> inline
and maybe a <span>dynamic portion of the text</span>
I'd also add that the fact HAML auto-closes your tags is totally negated by the fact you have to keep track of indentation instead. If you nest something when you shouldn't or vice-versa, good luck tracking it down, because the markup won't be broken.
As for interpolation, I like to know when part of the template is evaluated as code, and when it isn't. PHP, ERB, etc. all keep the distinction between the markup and the language very clear. These don't.
This stuff clearly adds value for you. That's fine. For me, it doesn't, and I think using an abstraction like this on the basis that it stops you getting the markup wrong feels worse than using it because you just dont know HTML. If you need something like HAML or Jade or this thing to close your tags for you, then that says something about the structure of your document.
I would argue, from personal experience, that anytime you can either 1-remove a class of errors, or 2-move that error discovery sooner to the time of authorship or compilation you have likely reduced the number of bugs that you will ship with. HAML accomplishes this for tag closing errors.
but with the downside that incorrect nesting errors are less visible. When elements are spaced far apart vertically it can be hard to tell if the indents are the same; whereas with a closing tag it can be more obvious, particularly if your editor highlights the matching opening/closing tag to the one your cursor is over. If your editor can show HTML validation errors then tag closing errors are also visible.
A valid point, although I have had the opposite experience. I can site down a line of code and see what is indented, as it is physically more to the right. The highlighting of matching tags doesn't work well for me because in highly dense or imperfectly formatted code, I'm not sure which tag I want it to be highlighting for the close tag in the first place.
Comments
I get the feeling you've never really used HAML, because this is a load of FUD. I'm going to respond primarily with HAML, because that's the whitespace-significant template language I have the most experience with.
> Writing plain old HTML is fucking simple. Abstracting it out into another 'language' just means you have to deal with a whole load of quirks and workarounds you'd never see with HTML, and while it looks all purdy and shit to some, it's an absolute nightmare to maintain.
I've maintained a lot of older projects, and the closer the templates are to HTML, the worse they seem to be. I can't count the number of times a DIV is left unclosed, or a TR is closed by a function call, or a P is nested 20 levels deep in a one-line monster tag. HAML and other whitespace-significant template languages prevent all that. You can't leave a tag unclosed in HAML, it closes them for you; because it closes them for you, you can't close them in weird and separate places; finally, because it forces you to have a newline before each tag, it looks really obvious when you've created a huge nested mess of HTML.
> Want to nest elements? Either you can't,
Wrong. Nesting elements is dead simple in HAML:
yields > some syntax has been introduced to discourage it (the end of line pipe),The end of line pipe is for when you have very code that goes with a single element. From the docs:
Usually, though, this should go into a helper, because your templates shouldn't have that much logic in them.> or you're told to just... use plain HTML.
This makes me think you don't know what you're talking about. Again, it's easy to nest elements in HAML. You wouldn't drop to HTML just because you want to nest elements.
> Want to interpolate variables? That's probably built in, which is great until you try changing it back to plain HTML, and then have to scan for all the interpolation, which is now plain text.
Of course it's "probably built in," interpolation is core to any templating engine. Interpolation is dead simple, as well.
I'm not sure what you mean by "turn it back to plain HTML." At what point can you turn any template language back to plain HTML without having the interpolation be a problem?> There's likely so much focus placed on "one-lining" everything that you have to do silly things just to actually make the template readable, when it wouldn't be a problem in HTML.
Do you have any examples of this? In my experience, whitespace-significant template languages do more to discourage one-line operations. Instead of doing this:
you're forced to break it up into multiple lines: > Never mind the total lack of portability and, especially these days, requiring a copy of Node just to run the damn things. Which is fine until you realise you shouldn't need to add a full on javascript VM to your development dependencies.I've never used a template language that didn't require some programming language to evaluate. Usually they require the language that the entire project is being built with; e.g., HAML assumes you are writing a Ruby project.
There are a lot of framework tools that require some sort of precompilation, too. If you're building anything reasonably complex, you're probably going to want to be able to split your files out into smaller chunks, which means using something like Less/SASS for CSS and require.js for dependency management. All of those have external dependencies. Or do you really not care to compile your disparate JS and CSS files into a single download?
> That so many of these attempts at 'HTML templating languages' exist is probably testament to the fact that no one agrees on what one should look like.
Isn't that a great thing, though? Diversity in this means the technology hasn't stagnated.
> They've actually been staring it in the face all along: plain old HTML.
I have no idea what you are suggesting with this point. What does HTML actually offer as a templating language? There's no built-in variable interpolation, no built-in template segmenting (e.g., rendering a partial), and no built-in control structures (loops, conditionals, functions, etc.). Once you've added all that in, you either have another template engine that requires something like node.js to precompile for performance reasons, or you have a mess of spaghetti that only the creator knows how to maintain.
I've used HAML and Jade a fair bit, and I've also had the joy of converting them back to HTML. I've experience the opposite to you, where we've had a much easier time with plain HTML than a specific abstraction of it. I've also had the joy of taking HAML and turning it back into HTML. It's no fun.
To clarify the nested tag example, using an unordered list fails to take into account the other methods of nesting elements in HTML:
I'd also add that the fact HAML auto-closes your tags is totally negated by the fact you have to keep track of indentation instead. If you nest something when you shouldn't or vice-versa, good luck tracking it down, because the markup won't be broken.As for interpolation, I like to know when part of the template is evaluated as code, and when it isn't. PHP, ERB, etc. all keep the distinction between the markup and the language very clear. These don't.
This stuff clearly adds value for you. That's fine. For me, it doesn't, and I think using an abstraction like this on the basis that it stops you getting the markup wrong feels worse than using it because you just dont know HTML. If you need something like HAML or Jade or this thing to close your tags for you, then that says something about the structure of your document.
I would argue, from personal experience, that anytime you can either 1-remove a class of errors, or 2-move that error discovery sooner to the time of authorship or compilation you have likely reduced the number of bugs that you will ship with. HAML accomplishes this for tag closing errors.
but with the downside that incorrect nesting errors are less visible. When elements are spaced far apart vertically it can be hard to tell if the indents are the same; whereas with a closing tag it can be more obvious, particularly if your editor highlights the matching opening/closing tag to the one your cursor is over. If your editor can show HTML validation errors then tag closing errors are also visible.
A valid point, although I have had the opposite experience. I can site down a line of code and see what is indented, as it is physically more to the right. The highlighting of matching tags doesn't work well for me because in highly dense or imperfectly formatted code, I'm not sure which tag I want it to be highlighting for the close tag in the first place.