Emblem.js: concise, indented alternative templating language for Handlebars.js | Hacker News Reader

Emblem.js: concise, indented alternative templating language for Handlebars.js

emblemjs.com

78 pointsmachty66 comments

Why do people do this? Obfuscating the HTML seems like the worst of both worlds. Either use a component model that abstracts it away or use HTML so you can see what is going on. Also, get your code out of the view. Has the world gone mad?

What code? The only stuff in there is to respond to changes in underlying data or pass click events to their rightful handler. Also, making something prettier, more readable, and easier to maintain seems like the opposite of obfuscatory, no?

This is code "each person in people" — once you go down the path of doing that kind of thing, the next thing people will ask for are filters, etc. and eventually half your business logic is in the "template" and half in the view code.

I would say that "each person in people" is a far cry from the type of logic in views normally frowned upon. What would you propose to be different in this case? Where does iteration of this type belong?

Check out mustache. It has things that can be used for iteration but it isn't explicit and you decide what actually happens at runtime in code rather than in the template.

http://mustache.github.com

The {{#array}}item{{/array}} syntax is functionally equivalent to and equally logicless as {{#each array}}item{{/each}}, only the latter (handlebars) has the benefit of being precompilable and easily extensible by frameworks such as Ember, Meteor, and the like.

They may be equivalent, however, the first version has the freedom to do what they wish, for example, what is represented by array may not be directly iterable or it may be filtered. Precompilation is available in a variety of languages for mustache, including js.

IMOH, handlebars is a lazy version of mustache where the developer using it sacrifices maintainability and encapsulation. Which is probably ok for most apps that don't grow beyond a single developer.

Hogan.js by Twitter is a mustache implementation that supports precompilation, among other things.

I'm guessing cause they use sucky editors that make writing *ML style markup hard.

Writing is the easy part (stuff like zencoding tools help with this).

But reading and grokking mountains of HTML code gets difficult for some people (me). That's when these templating languages are a lifesaver.

Well yes, but Haml/Emblem are trying to answer the question of where tooling should belong. Is it better to "abstract" syntax with your development environment, or in the source code itself?

So now we have Emblem.js that is compiled to Handlebars.js that can then be compiled straight to JavaScript, that is finally rendered as HTML. When will the madness stop?

Actually, Handlebars.js is a 2 step process. First step is compiling the syntax to something the runtime can understand, and the other is actually executing at runtime.

Emblem.js just replaces the first step of that process. So technically no more steps than plain Handlebars.

An alternative point of view is that each level of abstraction offers an insertion point for specialized tweaks without having to drop all the way down to the bottom level. Is that of practical significance? I have no idea. But it could be.

It's turtles (or you know, compilation) all the way down.

Interesting, but I really do not like the implied HTML tags (+ blocking via indentation) going on there. Mentally parsing HTML isn't that bad for someone with a bit of experience. This would add a new wrinkle (i.e. friction) to design.

I agree, and it's also the reason I dislike HAML and all the other things that want to use significant whitespace.

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.

Yes, I agree here. I've written a fair whack of plain HTML, whilst having used some preprocessors before, so I have some thoughts.

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

This would be expanded to:

  <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>

ZEN further provides hotkeys for navigating the blank spaces in this generated code where I'd likely want to fill something in.

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.

It's called Emmet now.

http://emmet.io

Oh wow, thanks for this, I didn't know the name had changed. So much for being such an advocate!

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:

  %p= @this.is(way.too.much). |
      code("and I should").   |
      really_move.it.into(    |
        :a => @helper)        |

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.

I've been hand coding HTML for years. Switching to HAML was a no brainer. We already write indented HTML, why worry about extra angle bracket syntax and closing tags? I'm surprised by the number of people who don't like using technology for what it was invented to do: make your life easier.

I'm surprised by the number of people who don't like using technology for what it was invented to do: make your life easier.

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).

This is a JavaScript templating language; aside from the fact that I like Emblem's syntax way better, you can't use HAML for JavaScript templates unless you go the hacky/ugly hamlbars route.

Seeing as you can obviously use technology to not worry about extra angle bracket syntax and closing tags, I don't see why you need to hide them in order to achieve that. I'm surprised by the number of people who want to strip out visual cues like that. To me, that makes life harder.

Some people like different things than the things you like.

I like `abstractions` instead of `tools that let me coexist with clunky things`.

Precisely. The abstraction removes human error. Coffeescript is a great example: it lets me forget about extra commas in an array, or semicolons. Jquery is another: it lets me forget about the inconsistencies between certain browsers with, for example, Ajax.

Indentation languages in general are a step up from editing raw HTML; by the time people are ready for another abstraction, the common tags will be far more ingrained in their heads. Syntax highlighting helps, too (existing solutions for the Slim templating language are already pretty good for Emblem, even coloring unrecognized html tags). And last but not least, you can optionally prefix your html tags with % to be explicit, and prefix dynamic "mustache" content with =.

Still no template inheritance! I feel like I'm taking crazy pills when that's the one feature I need / care about and none of the newer template languages implement it. I'm spoiled from Django/Jinja2/twig.

I'd consider this functionality in the future, but Emblem's bound by the constraints of Handlebars.js. In the meantime, most JS frameworks that you'd use Handlebars/Emblem with provide something pretty close to template inheritance. You'd achieve something similar in Ember with 'outlets', if I understand correctly.

Jade has template inheritance, mixins, includes and plenty of other cool stuff. If you haven't, you might want to check it out: https://github.com/visionmedia/jade

Most of the mustache implementations (.java, hogan.js, php, objc, etc) now support this.

https://github.com/mustache/spec/issues/38

    a concise, beautiful, and fully compatible templating alternative for Handlebars.js"
    [...]
    Introducing Emblem.js: a new templating language that compiles to Handlebars.js

If it compiles to Handlebars, it's not an alternative to it, is it?

If Coffeescript is an alternative to Javascript, then yes. If not, no.

Exactly. Emblem.js is for people who love Haml / Slim / Jade and want to use that style of templating with Handlebars.js

It really fits into place if you're coming from one of those libraries. I only wish I could enable percent-sign indicators for HTML tags! (%h1 vs h1)

%h1 is totally valid emblem syntax.

edit: it's optional, of course, but you have to use it if you need to use non-standard (read: unrecognized by emblem) html tags

Not sure how I missed that. It's a kick-ass little feature in my book, because while I appreciate the "implied HTML tags", I do find them easy to miss.

It is not an alternative to a handlebars dependency, but it does mean you can write templates without writing any handlebars code. So it is an alternative to writing Handlebars templates, but not an alternative to using them.

I really dig this kind of simplicity and clarity. The similarity to python really helps to keep things understandable.

Any chance of making this work with http://angularjs.org/ ?

Not sure if/how angular makes use of / extends Handlebars, but Emblem internally compiles to a Handlebars AST so it should be flexible enough to integrate with angular, though that's not on my immediate TODO list. Please feel free to have a go at it though, Anglebars seems like the logical place to start

Looks nice, but why would I choose this over handlebars? Don't wanna sound negative but it looks like just another layer of indirection...

Mostly because mucking around with raw HTML is a pain, and very much error prone (missing closing tags, etc.). You can either spend the time learning the ins and outs of text editor shortcuts to make your HTML editing easier or you can spend the time working through another layer of abstraction (Emblem in this case).

Hmmm, after years of editing HTML and having lots of shortcuts in my muscle memory maybe I forgot that, so yeah that is a valid use case.

That's a good way of putting it.

After half-heartedly learning Zen Coding (aka Emmet), I realized most of the reasons I wanted to learn it were obviated by Haml.

My favorite feature is implicit Ember actions and bound attributes. http://emblemjs.com/syntax/#implicit-bind-attributes

That feature alone made my Ember templates vastly more readable.

What is the difference between Emblem and Jade?

http://jade-lang.com/

afaik Jade can't be precompiled; all the parsing needs to happen in the Browser, whereas Handlebars (and therefore Emblem) can be precompiled so that browser processing is minimal. Also, for frameworks that heavily extend Handlebars, such as Ember.js, you'd miss out on a lot of features such as auto-updating templates if you didn't choose a language that compiled to Handlebars, i.e. Handlebars or Emblem.

It can. See the example at https://github.com/visionmedia/jade#a4

Similar syntax. Emblem.js compiles to Handlebars to make it ideal to use for client side templating and Ember.js

Everyone who doesn't like HTML template languages is going to eventually mention Zencoding. Note: They changed the name to Emmet, and it's still actively maintained and works with Sublime, et. al.

http://emmet.io/

If you find Zencoding anywhere, it's outdated and sucky.

I'm really excited to watch this come to further fruition. Alex gave a great quick demo at the last NY Ember.js meetup and I was really impressed. I'm a big fan of Handlebars but really appreciate the cleaner syntax.

Before I had to make my own jade-handlebars Meteor package. I hope that someone will quickly make a Emblem.js package for Meteor.

We'd love to. Would you be interested in helping out? Shoot me an email (on my profile) and we can coordinate.

Where can I find an example of using it in Node for precompiling templates to html or use it instead of jade?

Yet another templating language! I really don't see why this is any better than Handlebars itself, other than having lesser number of characters. C'mon ppl, developers are not that lazy!

> C'mon ppl, developers are not that lazy!

Challenge Accepted

Developers across history have gone through great length to remove pain.

    <div class="name">{{name}}</div>

vs.

    .name= name

That's not laziness. That's just sensible.

Absolutely.

An html dsl is not a templating language. It's something else that you can use to solve a similar problem. Why do people keep calling them that?

Wow, I read 'Ember.js'...:)

Emblem is not ashamed of its roots

Reply on news.ycombinator.com