

Emblem.js: concise, indented alternative templating language for Handlebars.js  - machty
http://www.emblemjs.com

======
spullara
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?

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

~~~
jacquesc
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.

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

~~~
jacquesc
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.

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

~~~
FuzzyDunlop
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.

~~~
jwdunne
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.

~~~
randall
It's called Emmet now.

<http://emmet.io>

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

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

~~~
machty
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.

------
becojo

        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?

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

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

~~~
mtsmith85
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)

~~~
machty
%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

~~~
mtsmith85
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.

------
beernutz
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/> ?

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

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

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

~~~
st0p
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.

------
combataircraft
What is the difference between Emblem and Jade?

<http://jade-lang.com/>

~~~
machty
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.

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

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

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

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

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

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

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

~~~
danneu
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.

~~~
cnp
Absolutely.

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

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

~~~
machty
Emblem is not ashamed of its roots

