

Marrying ClojureScript and JS Frameworks – Knockout Edition - Sandman
http://squirrel.pl/blog/2012/11/17/marrying-clojurescript-and-js-frameworks-knockout-edition/

======
swannodette
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.

~~~
pbiggar
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?

~~~
swannodette
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.

~~~
pbiggar
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.

~~~
pbiggar
Typo, too late to edit: s/coffeescript/clojurescript/

~~~
sgrove
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.

------
mattdeboard
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").

~~~
pbiggar
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).

~~~
mattdeboard
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.

~~~
pbiggar
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.

~~~
mattdeboard
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".

------
pelle
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

<https://github.com/lynaghk/reflex> <https://github.com/lynaghk/c2>

I'm still looking for good ways of doing routing in single page apps.

------
mischov
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.

------
josteink
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.

------
shaunxcode
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.

------
auggierose
All these frameworks are for people who do OO because they don't know better.
If you are working with Clojure(script), you usually do.

Just saying.

