I work on ClojureScript - so I'm obviously biased.
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.
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 don't understand this. We use Clojure for our startup - we occasionally drop down to Java for some libraries (EC2 comes to mind). If I were to use clojurescript, I'd want to drop down to JS too. So why is clojurescript being designed without taking that - the thing that allowed clojure be so successful - into account?
The post was mostly about challenges around integrating with popular JS MVC frameworks. I think the overall ClojureScript JS integration story is as about as good as Clojure and Java.
I was responding to this line "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.", which is what I don't understand.
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.
I wrapped/integrated handlebars templates last weekend, and after understanding how the google Closure library/compiler does things, it took ~15 minutes to have it working beautifully (using basically the same technique as jayq). For a lot of the libraries, it's not a big deal.
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.
Thanks swannodette, both for your work on ClojureScript and for the link to Conrad Barski's webfui. I had noted the dates for Clojure Conj 2012 and Conrad's talk but obviously time passed by swiftly. I look forward to the videos of Clojure Conj 2012 going up soon.
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...
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 don't think you have a good idea of what those frameworks do. KO - and this is visible in the example - binds values to DOM elements so you can update the DOM in real-time. How is that auto-solved in ClojureScript. (FYI: our backend is entirely clojure, our front-end is entirely JS using coffeescript, hamlcoffee, backbone and sammy.js).
Ok but that's kind of my point. You don't need Knockout to bind values to DOM elements so you can update the DOM in "real time", do you? There's nothing inherently special about KO or backbone or whatever, is there? It's just javascript.
Unless you mean something besides what I understand "real-time" to be, I don't think this actually happens.
Of course KO and backbone are just javascript. They are mature(ish), popular, well-known libraries that do very useful things. They aren't "code organization & maintenance enablers" (based on what I believe you mean by that).
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.
I don't know why part of my comment is in italics, I didn't surround it in asterisks or whatever. Sorry about the implied strenuousness of that part of my comment, it was unintentional.
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 agree that using it with existing frameworks is not that useful and probably a bad move.
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'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.
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.
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.
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:
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.
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.
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.
My gut feeling is that integrating with js components (http://www.github.com/component) is going to yield much better results than full blown "opinionated" frameworks.
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.
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.