Well, thanks for providing a peek, although I'm still not sure I could bear that syntax. I just find it very hard to parse ("})})))", seriously?), but perhaps that gets better with age/familiarity.
The "can extract fragments from pure HTML" part certainly sounds interesting. But still I have to wonder how well that scales to complex templates. I mean, mixing logic into templates is ugly, but the alternative - completely separating the interpretation from the template - doesn't seem so rosy to me either. During a bigger re-arrangement I imagine it could become quite nasty to re-sync the new template version with what the code expects?
I assume the above "template interpretation code" was for quite a trivial thing. What would it look like for complex stuff? (70 chars of closing parentheses? ;-) )
{%for x in foo%}
<div id="cool">{{x.bar}} {{x.baz|pluralize}}</div>
{%endfor%}
It's just different flavors of line noise. At least with Emacs you have paredit to manage code structure for you, no need manually track parens/braces at all.
Not pretty in any way but I guess 15 years of familiarity play their part and I have never had a big problem with that particular concept (it just works well for me in practice).
However, to each their own. Looking forward to see how compojure adoption will play out, perhaps at some point I'll just "get it" and wonder how I ever worked without it. ;-)
The "can extract fragments from pure HTML" part certainly sounds interesting. But still I have to wonder how well that scales to complex templates. I mean, mixing logic into templates is ugly, but the alternative - completely separating the interpretation from the template - doesn't seem so rosy to me either. During a bigger re-arrangement I imagine it could become quite nasty to re-sync the new template version with what the code expects?
I assume the above "template interpretation code" was for quite a trivial thing. What would it look like for complex stuff? (70 chars of closing parentheses? ;-) )