Bringing functional to the frontend – Clojure and ClojureScript for the web

If you're interested in a functional approach to UI code, check out functional reactive programming (FRP). It's a declarative way to specify UI logic which abstracts away much of the inherent messiness of using mutable state and callbacks.<p>I've played around with FRP in Haskell, and have found it much nicer than the more standard approaches to implementing UI logic. Before using FRP, my main UI experience was with Java Swing and web development, and FRP is definitely a step up. I've found it easier to write the code in the first place and then <i>much</i> easier to add new features and logic.<p>I've only used FRP with native UIs, but I think it would be very natural for web development as well. It's certainly a shift in philosophy and mindset, but one that I think is well worth overcoming.<p>Unfortunately, I do not know of a good tutorial for using FRP. I'm sure there are some out there, but I basically picked it up by reading academic papers which are not to everyone's taste. That said, I actually found some of the papers were clearer than the blog posts and SO questions I found online!<p>I'm probably going to write a basic FRP tutorial in Haskell some time soon, probably built around some very simple application (maybe John Conway's Game of Life). It really is a fun subject. Is anybody interested in something like that?

We use ClojureScript (and Clojure) at <a href="http://economi.co" rel="nofollow">http://economi.co</a> and I'm really enjoying it.<p>Maybe one of the most difficult things coming into it is trying to relate it to something like BackBone.<p>However generally speaking in Clojure the culture is more about libraries than frameworks.<p>C2 <a href="http://keminglabs.com/c2/" rel="nofollow">http://keminglabs.com/c2/</a> which on the outset looks just like a ClojureScript version of d3 is actually a great library to use instead of a traditional front end framework.<p>Check the example implementation of the class TodoMVC list here: <a href="https://github.com/lynaghk/todoFRP/tree/master/todo/c2" rel="nofollow">https://github.com/lynaghk/todoFRP/tree/master/todo/c2</a><p>It's uses normal Clojure data structures within atoms as the data model (<a href="https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/cljs/todo/core.cljs#L9" rel="nofollow">https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...</a>) and uses C2 to automatically update the UI (<a href="https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/cljs/todo/list.cljs" rel="nofollow">https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...</a>). Very elegant.<p>I'm just starting to explore this area myself, but have already found it useful for a few smaller parts of our site.

If you're interested in learning more about Clojure and ClojureScript, check out the upcoming Clojure/West conference in Portland, OR March 18-20th (<a href="http://clojurewest.org/schedule" rel="nofollow">http://clojurewest.org/schedule</a>), including a keynote from Rich Hickey, creator of Clojure. There is also a 1 day training class the day before on ClojureScript if you want the deep dive (<a href="http://clojurewest.org/training" rel="nofollow">http://clojurewest.org/training</a>). Register here: <a href="http://regonline.com/clojurewest2013" rel="nofollow">http://regonline.com/clojurewest2013</a>

Great article. I have spent a fair amount of time playing with ClojureScript, read "ClojureScript: Up and Running" and a lot of tutorial material on the web, and used it a bit in a customer project.<p>That said, ClojureScript has not really <i>clicked</i> for me yet, but this article and the pointer to dommy is getting me closer to adopting ClojureScript.<p>I use Clojure + Compojure (and still Noir) + Hiccup for just about all of my web app development. Love Hiccup. Having (mostly) Hiccup on the client side with dommy looks very cool.

So guys, I hate to bring this up in an unrelated topic, but when are you going to open-source Graph? It has been 4 months since you said "soon" and I'm squirming in anticipation.

On server-side templating - did you consider a selector-based approach like cgrand's Enlive?<p>As I see it, it brings the best of both worlds (the comprehensibility of "logicful" templating, the maintainability of strictly separating presentation and data transformations)

"The above is valid Clojure code, not another language whose syntax you have to learn or separate compiler to use."<p>Even though this is a fair point, the comparison between the Jade solution and the Clojure one is invalid. Jade was conceived as a whitespace-significant language. Its biggest benefit over plain HTML (or HTML-based template engines like Moustache) is the usage of indentation to determine hierarchies.<p>The comparison would be more valid with something like <a href="http://domo-js.com" rel="nofollow">http://domo-js.com</a>, which is solving the exact same problem: using a single language (JS) for markup production – and even replacing CSS.

I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation. However, I'd ignore that if the performance gains were significant. What are the performance advantages of ClojureScript server-side templating compared to client-side Javascript templating? The vogue style these days seems to be a one-page app where the clicks take barely any time, because the jQuery/Zeppo/Underscore selectors are all cached.

I'm using my ported version of Hiccup [1] to ClojureScript for a while now and share most of my templates between Clojure on the server, and ClojureScript on the client side with good sucess. It can sometimes get a little bit hairy to share code between the 2 platforms, but I hope something like Common Lisp's feature expressions [2] will make it into Clojure and ClojureScript soon. When this arrives, life will be a lot better ...<p>Just for fun, I benchmarked my Hiccup port against the other candidates.<p>Compilation Mode: Whitespace {:crate 7.076333333333333, :jquery 1.4643333333333333, :dommy 2.1186666666666665, :hiccup-str 1.985, :hiccup-node 2.3476666666666666}<p>Running Hiccup and Dommy in advanced mode get's the time towards unoptimized jQuery.<p>Compilation Mode: Advanced (Crate and jQuery don't run in advanced mode) {:dommy 1.3436666666666666, :hiccup-str 1.0293333333333334, :hiccup-node 1.3506666666666665}<p>One thing to note: The original Prismatic tests were building jQuery Nodes and appended them to an UL element. Building strings and appending those to the node speeds the whole thing up a little bit further [3]. In the above benchmark :hiccup-node uses DOM nodes to append to the root, :hiccup-str uses Javascript strings.<p>I can only agree. Using a Hiccup like template system in Clojure is very nice.<p>[1] <a href="https://github.com/r0man/hiccup/tree/clojurescript" rel="nofollow">https://github.com/r0man/hiccup/tree/clojurescript</a> [2] <a href="http://dev.clojure.org/display/design/Feature+Expressions" rel="nofollow">http://dev.clojure.org/display/design/Feature+Expressions</a> [3] <a href="https://github.com/r0man/dommy/tree/hiccup" rel="nofollow">https://github.com/r0man/dommy/tree/hiccup</a>

Author here. Happy to answer any questions or comments.

I agree that using data as templete is great. This is a typical example of "The value of value"(Rich Hickey's speech).<p>And I think client side have a bit different requirement compared to server side. At client side, I often need to manipulate specific element instead of root element which crate and dommy return. So I forked crate in order to get a collection of created elements as a hashmap. <a href="https://github.com/hozumi/crate-bind" rel="nofollow">https://github.com/hozumi/crate-bind</a> This is useful. I will create dommy version of this.

the dom is a mutable data structure and the native (fast) dom apis expose mutable interfaces. so dynamic sites (you know, single page html5 apps doing all sorts of client-side dom manipulation) are either going to be slow, or are going to have an imperative core, which is where you need functional programming the most ;(<p>maybe HTML6 will have native functional dom manipulation and we can rewrite all our favorite javascript libraries to expose functional interfaces. one can dream.

Another option for functional on the front end (and back end) is LiveScript. <a href="http://livescript.net/" rel="nofollow">http://livescript.net/</a> Many people may not have heard of LiveScript.<p>I prefer LiveScript for a number of reasons, starting with the fact that I just don't like brackets and parentheses enough to want to use them everywhere.

My biggest problem with ClojureScript is that is very hard to reason about code written in it if you are a beginner.

Semi-related question but...<p>One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file).<p>Now my question: with all these templating libraries like Jade, aren't you losing feature like real-time validation?<p>And when such a templating library comes out, it means every editor out there as to be modified so that it supports it?<p>Or is there some kind of a schema that can be used to perform real-time validation + auto-completion?<p>My point is: I definitely see the point as replacing Jade by Clojure because you can then manipulate your templates as data, which is gorgeous. But I don't see the point of using Jade in the first place...