Hacker News Reader

That will depend very much upon your HTML developers. Some will be able to do it, a large number will not.

Even when using simple template languages I have experienced the I didn't understand those funny bits in the HTML so I have removed them far too many times.

In Clojure, Enlive (https://github.com/cgrand/enlive) is a better solution because the HTML remains as HTML.

Is anyone aware of something similar to enlive in pure Java? I would certainly like to give it a try.

Wicket and Tapestry are trying to do the similar thing. Not as good as Enlive though.

I agree that it depends pretty heavily on who is doing your HTML. That being said, you can just not use the defpartial stuff and instead include Enlive to use with Noir just as well. There are purposefully no constraints on what you use to generate HTML. The main purpose of settling on Hiccup in this case is to provide something that I think the Clojure web community desperately needs: a single place to start and build something. The only way I can provide that start pointing is by making some choices and running with them.

Also, I really love html functions as opposed to JQuery-esque template filling. It's cleaner and more flexible to me.

The main advantage of writing HTML using a tool like Hiccup is that you can factor out repeated sections of markup into functions.

For example, one might write a page like:

  (defn user-settings [user]
    (settings-for [user]
      (breadcrumbs (link home) (link settings))
      (text-field :login)
      (text-field :email)))

And the functions used would take care of generating the page, layout, form, fields, error notices, flash messages, CSRF protection and so forth. By the time you've finished with all that, those 4 lines of Clojure will be 50 lines of HTML.

Hiccup tends to lend itself toward user interfaces that are uniform and predictable, with repeatable elements. Think Facebook or Github, for instance.

I don't see how this any different from what Enlive provides. Enlive templates/snippets create functions which generate HTML. In anycase, using Hiccup with Enlive seems to combine the best of both worlds.

HTML is a markup language, rather than a Turing Complete programming language, so there's a lot of redundancy in a HTML file that could be avoided in a programming language.

You can get around this in Enlive and other HTML-based templating methods by taking a hybrid approach. The layout HTML is written by a designer, but all the tedious repeatable elements are written by programmers in helper functions, or factored out into dozens of smaller templates.

I'm not sure I like this approach, as it (a) glues together several different methods for generating HTML, (b) encourages people to write the HTML around the page design, rather than treating HTML as purely semantic markup.

I admit to being something of a purist when it comes to HTML. I'd prefer to keep the style and design of the page out of my HTML as much as possible; idiomatic HTML should be semantic markup, whilst the design of the page should be defined in CSS.

I don't see anything in Enlive which is at odds with your viewpoint.

My viewpoint is that HTML shouldn't be written directly, because the language isn't designed to be particularly DRY. Isn't that very much at odds with Enlive?

Enlive does exactly what Hiccup does with the additional bonus that it allows designers who are comfortable with HTML to be a part of the process. Enlive is not page centric - that's the whole point of snippets.

But if none of your designers are writing HTML, what benefit does Enlive have over Hiccup? Whilst Enlive could probably mimic Hiccup's style through aggressive use of snippets, it seems to me that it would need more code to produce the same result. Enlive seems the wrong tool for the job if you want to use it in the same fashion as Hiccup.

Enlive vs Hiccup seems entirely dependent on the composition of your group. For a group of programmers, Hiccup is an efficient means of not repeating yourself. Add a single designer and you'll find programmers implementing a lot of mockup images to be compatible with IE7. Try hiring more designers, especially ones who can use existing design tools, and you'll find Hiccup-style to be completely unusable. Enlive-style allows a company to hire designers who can produce HTML that works in all the browsers that you support, leaving programmers to work on functionality.

In short, step 1 Hiccup, step 2 ???, step 3 profit!, step 4 Enlive.

(Also: dealing with browser induced styling edge cases while you're trying to focus on substantial features is every programmers hell.)

(Edit: I'm a compojure/hiccup fanboy in my spare time, but during the day I work at a large company who can't hire enough programmers.)

For the record, I think Enlive is incredibly useful for a large number of teams.

However, I'm a HTML purist at heart. I believe HTML should be semantic markup, and that the page design should be independent of the HTML generated, whenever possible. Ideally, it's the CSS that should determine the page layout and style.

I also work for a company that produces very uniform web interfaces, and where the developers significantly outnumber the UX guys. Hiccup would work very well in this environment, but perhaps not so well in an environment with many designers :)

Using them together does seem ideal, but it turns out it is pretty inefficient in practice: http://groups.google.com/group/enlive-clj/browse_thread/thre...

The same philosophy is applied in the Seaside framework for Smalltalk. See for example [1].

[1]: http://onsmalltalk.com/page-templates-and-seaside

If a front-end creates a mockup using a certain DOM, it is easy for the back-end to generate that DOM (or tell the front what needs changing). If the back-end generates a DOM, it is typically easy for the front-end to create CSS/Javascript to fit (or tell the back-end what needs changing). Also, learning that (:a :href uri name) maps to <a href=uri>name</a> is not hard, so usually the front-end will be capable of making basic changes.

It is not a significant obstacle.

The examples uses Clojure as the language for defining the HTML

See this Stackoverflow question... CL-WHO-like HTML templating for other languages? (http://stackoverflow.com/questions/671572/cl-who-like-html-t...) which provides some examples in other languages.

However, I'm wondering if anyone has any experience developing web applications using a Lisp-dialect for generating the HTML (as Noire and the example in Practical Common Lisp), and if this is scalable to a team where front-end developers might not be used to or familiar with Lisp.

I like keeping the HTML markup within the back-end developers domain and leave the front-end developers/designers to just use Javascript & CSS around it. (disclaimer: In most cases I'm both the back-end and front-end developer :)