Marrying ClojureScript and JS Frameworks – Knockout Edition

http://squirrel.pl/blog/2012/11/17/marrying-clojurescript-and-js-frameworks-knockout-edition/

by Sandman • 14 years ago

43 17 14 years ago

squirrel.pl

pelle• 14 years ago

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.

mattdeboard3• 14 years ago

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

pbiggar5• 14 years ago

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

mattdeboard3• 14 years ago

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.

swannodette2• 14 years ago

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.

pbiggar5• 14 years ago

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?

swannodette2• 14 years ago

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.

kinleyd• 14 years ago

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.

shaunxcode• 14 years ago

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• 14 years ago

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.

mischov• 14 years ago

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• 14 years ago

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.

Marrying ClojureScript and JS Frameworks – Knockout Edition

Related Stories