I work on ClojureScript - so I'm obviously biased.<p>I think there are very deep seated assumptions in even the best designed JavaScript libraries. Because of this I think there will tend be impedance an mismatch between Clojure and the API that JS libs present. If you're willing to spend a little bit of time upfront - I believe macros & protocols can likely eliminate at least the tedium you'll find at the interop barrier.<p>Still, I'm hopeful for pure ClojureScript libs that show how expressive Clojure can be for client side development if you approach the problem without the usual JS assumptions.<p>One example, I recently returned from the Clojure Conj where I saw Conrad Barski's (Land of Lisp) presentation on functional DOM programming - impressive stuff and worth checking out if people are curious what an idiomatic client side ClojureScript library might look like - <a href="http://github.com/drcode/webfui" rel="nofollow">http://github.com/drcode/webfui</a><p>EDIT: I don't mean JS libs in general (simple functional libs integrate great!) but the various MVC frameworks mentioned in the post.
I know nothing about ClojureScript except that which I know from Clojure (mostly syntax and whatever semantics carry over). I'm not that familiar with JS framworks either. Caveats out of the way...<p>It doesn't seem like frameworks necessarily solve anything that needs to be solved in ClojureScript. I mean, my impression of KO/backbone/spine/etc. ad nauseum, is that they're code organization & maintenance enablers. That doesn't fit into my mental model of a problem that needs to be solved in ClojureScript (that mental model being "ClojureScript is basically Clojure").
I agree that using it with existing frameworks is not that useful and probably a bad move.<p>I'm using it a bit with jQuery.<p>The real benefit I see are with some of the new ClojureScript libraries.<p>My feeling is that we wont see many ClojureScript frameworks as thats not really the Clojure way.<p>I'm struggling myself with finding the right way of using ClojureScript, but it's early days yet and whatever experimentation we do now will probably guide the way.<p>There are interesting patterns happening now though such as the use of atoms for data binding as is used in Reflex/C2<p><a href="https://github.com/lynaghk/reflex" rel="nofollow">https://github.com/lynaghk/reflex</a>
<a href="https://github.com/lynaghk/c2" rel="nofollow">https://github.com/lynaghk/c2</a><p>I'm still looking for good ways of doing routing in single page apps.
I've only recently started using ClojureScript with any intensity, but at the moment I agree with the author that the experience has been neither fun nor productive.<p>I don't necessarily feel that this is a problem with the language (though the current macro system doesn't seem simple or easy) but rather that this is a problem with the youth of the language.<p>The Closure compiler seems like a wonderful thing, but you really want to be able to use advanced compilation and that makes interop with other libraries... confusing (at least while you're getting started). This makes it a lot harder to just jump in and get started by calling on host (Javascript) libraries to get stuff done. Combine this with the fact that there aren't so many pure ClojureScript libraries and wrapper-libraries available (relatively speaking), and productivity is a bit stunted.<p>All of that said, I think ClojureScript has as much potential as Clojure on the JVM and I look forward to things improving as the ecosystem matures. It is wonderful to write Clojure and control the client, and I think that those people who can fight their way through (what I found to be) the unfortunately steep getting-started curve will have a hard time going back to vanilla JS.
While I like Clojure, and I think ClojureScript represents some (at least theoretical) benefits, like being able to reuse same logic client-side and server-side, I think I'm leaning towards the same conclusion the author does:<p><i>Contrary to plain Clojure, “fun” and “productive” aren’t the words that come to mind when I think of my adventures in CLJS ... All that only to bridge the gaps and make ClojureScript look more like… JavaScript.</i><p>It may be a matter of habit, but as both languages are dynamic and untyped, I just feel it's more natural hacking at the web using plain JavaScript. I don't see ClojureScript providing me with enough unique capabilities I cannot have in JavaScript to be worth the trouble.<p>If I want to reuse Clojure-based logic, to me at least, it is starting to look as if it is easier to write your main client-side code in JS and just include CLJS-compiled JS when you want to reuse stuff.<p>That is, if you are willing to accept the overheard that involves. And in these times of "yslow", you may not. I probably am, but you may not.
My gut feeling is that integrating with js components (<a href="http://www.github.com/component" rel="nofollow">http://www.github.com/component</a>) is going to yield much better results than full blown "opinionated" frameworks.