Thanks for the writeup! I'm currently experimenting with Ring/Liberator on the server side and Mithril on the client, and was unsure whether I should just use ClojureScript or plain JS. I chose plain JS for simplicity, but damn, reagent and figwheel look like a killer combination.
To me it seems client side Clojure is a bit harder at first than server side, since most of it has to do with mutating DOM state - do you think thats true?
It is difficult, which is why Clojurescript adoption didn't really take off until React (via Om) showed up. The whole point of the virtual dom model is to avoid stateful DOM manipulation and instead have view code that is an idempotent (and generally pure) transformation from app state to virtual dom. This is a great fit for any functional programming language and makes keeping the DOM in sync mostly a solved problem.
I haven't tried Mithril in cljs personally but it fits the model so you should be fine with just writing a wrapper function or macro to save some boiler plate on the cljs to js data structure conversion.
The challenges in the cljs app I'm working on are the same challenges you run into any app: how do you separate concerns, where does state reside, how do you keep it in sync with the server, etc. A problem that's unique to React based apps is how to get data from your app state to a component without higher level components needing to be changed.
My main annoyance with cljs is that rethrowing errors in Chrome swallows the stack trace and core.async wraps everything in a try/catch block. This means that you need to debug by breaking on error, typing `ex.stack` in the console, and reading compiled JS frames to find the source.
