views:

298

answers:

1

What are the current choices of mature Clojure web frameworks? I am looking for some kind of feature matrix telling me what the popular frameworks support and to what extent, including:

  • Response templating (response written in Clojure or in some other markup - e.g. like JSP with Tiles)
  • HTTP sessions
  • REST with automatic mapping of URLs into action-functions and params
  • HTML forms (params available as map, error handling, validation)
  • Application flow (known from Java frameworks - request handlers return action identifiers which are eventually handled by renderers)
+9  A: 

Perhaps my answer to the What is the good starting point to developing RESTful web service in Clojure? question on SO might be of help to you. It mentions some important web libraries for Clojure (with links and short summaries). The key point which I would like to reiterate here is stated in the first paragraph of that answer:

First of all, I think that you are unlikely to find a single shrinkwrapped solution to do all this in Clojure (except in the form of a Java library to be used through interop). What is becoming Clojure's standard Web stack comprises a number of libraries which people mix and match in all sorts of ways (since they happily tend to be perfectly compatible).

To that I would add that you should probably not expect to handle things with the sort of "application flow" you might know from Java (or if you believe you really need it, you'll probably have to roll your own lib to support it!). That's alright, though, as people seem to be very happy with Ring's handler-is-a-function, higher-order-middleware-friendly approach.


To address your bullets:

  • Response templating:
    There is a number of Clojure-specific solutions, including Enlive and Hiccup (Enlive is a very powerful HTML scraping / templating / transforming engine; Hiccup is a DSL for writing HTML in Clojure with the nice property that it renders fast). Also, this is probably one place where it makes perfect sense to drop down to Java and use something like, say, StringTemplate. This even has the good side of discouraging the mixing of templates and logic! (I believe Stuart Halloway has mentioned that Relevance -- his company -- is using this strategy in their work and having great success with it.)

  • HTTP sessions
    That would be Sandbar, I suppose. The author has started a series of blogposts about it which looks very promising.

  • REST with automatic mapping of URLs into action-functions and params
    That's Ring & Compojure and/or Moustache. See below.

  • HTML forms (params available as map, error handling, validation)
    As above.

  • Application flow (known from Java frameworks - request handlers return action identifiers which are eventually handled by renderers)
    As mentioned above, not really something people tend to do in Clojure.


As a starting point in learning about the Clojure web stack, this Ring tutorial by Ring's author Mark McGranaghan is very helpful. Compojure's author James Reeves has some documentation on Compojure. Perhaps my recent answer to the What’s the “big idea” behind compojure routes? question might be of help too. Ring's sources also include a great SPEC document.

Michał Marczyk
@Michał Marczyk: would you mind expanding a bit on the issue of templating options, and why you might recommend 'dropping down into java'? Is it an issue of the maturity of functionality, of performance, or something else?
Rob Lachlan
@Rob Lachlan: I wouldn't necessarily *recommend* dropping down to Java -- I just think that this is one task where doing so might not necessarily lead to an inferior experience. If you structure your application so that your template engine never calls out to your application logic at the rendering stage, what difference does it make if it's written in Java / Scala / whatever? At least as long as there is a sane way of setting template variables, of course (e.g. StringTemplate uses `.setAttribute` on templates, which is simple enough to use with `doseq` and a map from Clojure).
Michał Marczyk
That is not to say that there are no reasons to prefer pure Clojure templating schemes -- I'm not sure I know of anything quite like Enlive outside of Clojure land, for example (but working wonders costs time, so it might not be the appropriate choice where something significantly simpler would do perfectly well), Hiccup is a great HTML-producing DSL (but is there much point to teaching a designer to write Hiccup when they already know another JVM solution which you can just call out to?) etc.
Michał Marczyk
I believe that in the case of this particular answer I simply thought that if the OP is used to Web development in Java, he may well be perfectly happy with whichever JVM templating engine he would normally use. Plus I can't really think of a direct equivalent to StringTemplate in Clojure (nor can I see much of a reason to invent one) and it seems to be a great solution for HTML templating.
Michał Marczyk
@Michał Marczyk: Good points all, thank you. That clarified things for me a bit -- I've come to the conclusion that, at least for my personal projects, I'm going to using straight hiccup. After all, since our language's syntactic form is isomorphic with xml and html (or very nearly), it would seem a shame not too exploit that fact.
Rob Lachlan