Your templating engine sucks and everything you've ever written is spaghetti code | Hacker News Reader

Your templating engine sucks and everything you've ever written is spaghetti code

workingsoftware.com.au

2 pointsnnq3 comments

An interesting, simpler and more designer-friendly approach to templating.

This is why I love Enlive[1], Enfocus[2] and Kioo[3] (and Enliven[4] is looking awesome too!).

Your logic stays in your code, the templates are snippets of pure HTML. Dynamic content is generated by manipulating and composing the snippets in code. Snippets can be defined in one large HTML file or many files - up to you. The code uses CSS selectors to choose which parts of the HTML to use and transform.

For example, lets say I have a blog application:

    <body>
        <div>Welcome to my Blog</div>
        <div id="posts">
            <div class="post">
                <div class="title">My post</div>
                <div class="content">Post content here</div>
                <div class="comments">
                    <div class="comment">A comment</div>
                </div>
            </div>
        </div>
    </body>

Then my code might look something like this:

    (enlive/defsnippet comment-snippet "myfile.html"
      [:.comments]
      [comments]
      [:.comment] (enlive/clone-for [comment comments
                    (enlivecontent comment))

    (enlive/defsnippet post-snippet "myfile.html"
      [:#posts]
      [posts]
      [:.post] (enlive/clone-for [{:keys [title content comments} posts]
                 [:.title]    (enlive/content title)
                 [:.content]  (enlive/content content)
                 [:.comments] (comment-snippet comments)))

That is, parts of snippets are selected and transformed in some way (changing the content, adding/removing css classes or styles, setting attributes, prepending or appending content, wrapping or unwrapping tags, duplicating for each element in a list, etc). This lets you write your page elements as mocked up snippets with dummy data and then merge them together, fill in content, dynamically update attributes and classes all without putting any logic into the HTML.

This also makes it very designer friendly because they can work in pure HTML and CSS without worrying about templating - they only need to make sure to follow your basic structure outline (ie making sure your selectors match the right thing).

[1] https://github.com/cgrand/enlive

[2] https://github.com/ckirkendall/enfocus

[3] https://github.com/ckirkendall/kioo

[4] https://github.com/cgrand/enliven

Nice, didn't know about all that happening in the Clojure universe. The scary part is that now your view code is tied to the structure of the HTML. The logic gets brought up in the code, where it belongs, but so does a lot of markup structure knowledge. Seems like an even worse outcome. Maybe it isn't, but I've never tried the approach on any real project.

...anyway, the thread died as this is never really a hot topic, people just use whatever templating language is "default" in their fav framework and don't like to overthink this, I guess :)

The scary part is that now your view code is tied to the structure of the HTML.

I haven't really found this to be the case as long as you only use id's and classes as selectors. That is, in my example, I don't care what a post looks like, as long as it has a .title, .content and .comments. In large projects, I use naming conventions to designate certain classes as data elements (ie elements whose content will be overwritten with data), some as non-data content (ie elements which will be duplicated), some as page elements (containers for other elements) etc

The reality is that all templating has logic and HTML structure married in some way (in most templating systems its the reverse as the code is in the HTML), but I find that as long as you don't need complex selectors that rely on which span is contained in what div or whatever, then I don't care about the structure - I only care that certain id's and classes (sometimes sets of classes) refer to a snippet I wish to modify. At the end of the day, in a real application, there is likely always going to be a little coupling, but I haven't noticed it to be a big deal (at least, not yet).

I also find that in large applications, you may have a lot of self-contained reusable components (dialogs, widgets, etc). In these cases, I don't mind having the code and HTML coupled, as long as the components can be styled to suit my application externally (ie purely with CSS). For example, in an app I'm building right now, I have a table widget - the code and HTML are tightly coupled, but I can reuse the widget without touching either because I can style it using CSS. This is obviously only the case for self contained widgets that don't need to be changed and not general UI components.

Final thoughts: my current application is written with Om (one of the ClojureScript libraries for using React), which treats the rendering as a function of the state: f(state) -> UI

I use Kioo to construct my components in template-free HTML and my ClojureScript code manipulates it based on the data. The logic is really simple - its a one-way system: data -> logic -> template (raw HTML) -> page (processed HTML)

Reply on news.ycombinator.com