The genius of Enlive as a template system | Hacker News Reader

The genius of Enlive as a template system

github.com

24 pointslkrubner13 comments

I dislike PHP, but why did they purposely make the PHP example as horrible as possible? Like, they skipped short-tags, wrapped closing PHP tags, didn't use non-brace syntax (which is useful in templates), and didn't use a foreach loop like they did in the Python example.

    <?php
    for($i = 0; $i < $len; $i++) {
    ?><p>Foo <?echo $i?></p><?
    }
    ?>

    <? foreach($foo as $i): ?>
      <p>Foo <?= $i ?> </p>
    <? endforeach ?>

I understand you want to sell your project, but don't make the examples deceiving.

I don't… I don't see much difference.

    ~$ python
    >>> A = "<?php for($i = 0; $i < $len; $i++) { ?><p>Foo <?echo $i?></p><? } ?>"
    >>> B = "<? foreach($foo as $i): ?> <p>Foo <?= $i ?> </p> <? endforeach ?>"
    >>> L = [A,B]; import re
    >>> map(len, L)
    [68, 65]
    >>> map(lambda x: len([s for s in x if re.match('\w', s)]), L)
    [23, 29]

Isn't it about the same amount of alphanum vs noise? About the same length too.

I'm not sure B is more readable than A in any way. Maybe more 'idiomatic', meaning 'way humans think'; but I'm not sure about that.

B is just a bit more cleanly organized. Somewhat like the difference between code that uses sensible indentation and code that uses deceptive indentation — they both look statistically similar, but the organization helps us read it.

Short tags are widely frowned upon. IIRC they are deprecated in the current release of PHP and are due to be removed in the next major release. Not using them seems quite fair to me.

(Incidentally, though, the <?= tags are now considered a fundamental feature and not part of the short tags syntax, so you can use those everywhere.)

because they picked <? without realizing that those were being proposed/used as the xml parsing directives. hence they clash(ed) with xhtml.

Unfortunately, it seems the author doesn't have time to keep up with it's popularity. The code hasn't been updated in months (other than the "lazy fix"). There are 23 open issues, many over a year old.

https://github.com/cgrand/enlive/issues?state=open

I got hit by a bug the other day (it assumes http resources are UTF8), and even though fixes are available, none have been merged in.

See also "Is Enlive Alive?"

https://groups.google.com/forum/?fromgroups=#!topic/enlive-c...

Having said that, I still think Enlive is awesome. I just which development was more active. Take a look at the network graph and you'll see people fixing a lot of issues on their own branches.

Lots of these kinds of push templates have existed, none of them seem to have legs. I think they seem elegant, but mixing logic and HTML is actually just a great way to do things. When you want to change something you see in the HTML – be it dynamic or static – then you always know where to look. And when you come back to some code 6 months later you'll really appreciate the simplicity.

Even in Javascript traditional templates have seen a surge in popularity, even though push-style templates have always been the more natural way to operate (in the case of Javascript, modifying the DOM directly).

I'll give it a try in a personal project but I hardly see myself asking my designers to use this template system.. Call me grumpy or old, but when working in a team, I like to keep template files as close to html as possible. It's so much easier to use a technology that everyone understands or to hire externally to speed things up.

That's sort of the point, though: the templates are completely HTML. There's nothing else in them at all. Your designers can write straight up HTML and not worry about templating at all.

Of course, then it's on you as a developer to use Enlive to replace whatever stub/sample elements are present in the HTML with real data, so it's not an entirely free lunch.

That doesn't fit my experience of how designers work with templates. The problem with this style of template system is that it's very tightly coupled to the HTML of the template. If a designer wants to e.g. change the class on an element (because they want to use a CSS class from bootstrap) they can't without worrying about what's in the clojure code. It becomes almost impossible for them to make anything more than a trivial change without a full understanding of the code that will be manipulating their templates.

Hmm, I've only used enlive on a small project, and that was quite a while back (I haven't done any webdev lately) and I generally ended up marking my templated elements with special ids or classes. Artificial example coming up:

  <ul>
    <li class="item-template">
      <a href="#" class="item-link-template"><strong class="item-caption-template">Some dummy caption</strong></a>
        &mdash; <span class="item-description-standin">Some dummy description</span>
    </li>
  </ul>

The item-template marks the outer-most element to use for repetition. The item-link-template can be used to set the href attribute. The contents of the tag marked with item-caption-template will be replaced with whatever content. The item-description-standin gets replaced with content outright. If you, say, want to remove the <strong> tags around the caption, just move the templating class to the parent item.

  <ul>
    <li class="item-template">
      <a href="#" class="item-link-template item-caption-template">Some dummy caption</a>
        &mdash; <span class="item-description-standin">Some dummy description</span>
    </li>
  </ul>

If you come up with some conventions, e.g. "-standin" gets replaced completely, whereas "-template" just gets transformed; each marker is only used for one purpose (don't conflate the link and the caption marker in the latter example), it works rather well, probably better than any other templating system I've used.

My only gripes with Enlive at the time were that it was overly macro-heavy (def'ing everything as opposed to returning values), and loading templates was quite slow, which made on-the-fly modifications to HTML generated elsewhere ineffecient. I suspect both are better these days, as it was still heavily in development at the time.

This is not gonna fly. It's replacing a quick, but dirty solution (PHP-style templating), but in turn makes it too complex to maintain and very hard to understand.

I have never understood why someone would another abstraction layer to templating.

Seen lots of template systems use this "Push style" before - http://www.perlmonks.org/?node_id=674225

Reply on news.ycombinator.com