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.
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 - http://github.com/drcode/webfui
EDIT: I don't mean JS libs in general (simple functional libs integrate great!) but the various MVC frameworks mentioned in the post.
I havent used coffeescript, but from the article and your comment, it doesn't sounds like the integration is as good - the Java/Clojure integration is really very very good in practice.
For others, I assume that the imperative style that's so pervasive in JS makes it more difficult to use in cljs without lots of tedious macros. I'm slightly optimistic that the google Closure library, as much as I dislike the style of it, may actually end up imposing just enough structure and reasonable common practices that cljs and other languages can really interop nicely.
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").
Unless you mean something besides what I understand "real-time" to be, I don't think this actually happens.
You could of course update the DOM in real-time without KO, but KO basically provides a lovely declarative DSL for how to do that. Why throw that away?
I don't know what your last comment meant. KO binds values to DOM elements, so when you update the value, the DOM element instantly changes. If you saw the Meteor video, its just like that.
Anyway, of course they're code organization and maintenance tools. You and I apparently have very different definitions for various phrases such as "real time", "DSL", and "code organization".
I'm using it a bit with jQuery.
The real benefit I see are with some of the new ClojureScript libraries.
My feeling is that we wont see many ClojureScript frameworks as thats not really the Clojure way.
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.
There are interesting patterns happening now though such as the use of atoms for data binding as is used in Reflex/C2
I'm still looking for good ways of doing routing in single page apps.
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.
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.
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.
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.