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.
Want to nest elements? Either you can't, some syntax has been introduced to discourage it (the end of line pipe), or you're told to just... use plain HTML.
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.
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.
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.
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. They've actually been staring it in the face all along: plain old HTML.
Writing plain HTML purely by hand is a pain. A massive pain. Don't do it. If you're writing HTML by hand, you're writing well over half of what you should be writing. There are tools out there that help, my number one favourite being ZEN coding.
ZEN coding is a set of tools, namely an abbreviation engine, for writing and manipulating HTML. The abbreviation engine allows you to write CSS selectors in place that ZEN will expand for you, which alone is extremely powerful. For example, the if we want 2 unordered lists of 4 links, we can write:
ul*2>li*4>a
<ul>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ul>
<ul>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ul>
This is just the start though, it really comes into its own when you realise the power of Wrap abbreviation.
ZEN coding dramatically increases the rate I can write HTML and it did this within a couple of days. I remember when me and a colleague would receive a Word doc which had to be completely marked up. My colleague would take it up using a hacked together solution - he wasn't a very good programmer but had more HTML/CSS experience than me. This would take him around 2 hours to complete (70+ page doc). When he left, it was down to me. I completed it in the same amount of time using just ZEN coding (I'm not crazy though, I did write a better tool which cut that job down to 5 mins).
I advocate it so much I demand any new starter to learn it as a priority - the difference in productivity is phenomenal.
With ZEN coding, I don't need these abstractions. I can just write HTML and I don't need to recompile every time I update it.
I urge you all to try it. It will change your perception of writing HTML. Funnily enough, I now find it therapeutic.
> 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
<ul>
<li></li>
</ul>
The end of line pipe is for when you have very code that goes with a single element. From the docs:
%p= @this.is(way.too.much). |
code("and I should"). |
really_move.it.into( |
:a => @helper) |
> 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
> 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>
%ul
%li
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.
That's my point - I don't see this being much easier or particularly valuable, considering I will always have to be highly competent with straight HTML regardless. To me, this is a mental switch with little payoff (handlebars + HTML is fine).
But reading and grokking mountains of HTML code gets difficult for some people (me). That's when these templating languages are a lifesaver.
After half-heartedly learning Zen Coding (aka Emmet), I realized most of the reasons I wanted to learn it were obviated by Haml.
That feature alone made my Ember templates vastly more readable.
Emblem.js just replaces the first step of that process. So technically no more steps than plain Handlebars.
a concise, beautiful, and fully compatible templating alternative for Handlebars.js"
[...]
Introducing Emblem.js: a new templating language that compiles to Handlebars.js
Any chance of making this work with http://angularjs.org/ ?
If you find Zencoding anywhere, it's outdated and sucky.