

ClojureScript Unraveled - macco
http://funcool.github.io/clojurescript-unraveled

======
lawry
I've read On Lisp by pg, and I'm passionate about using emacs (still depend
too much on vim for productivity), so I'd love to start using Lisp-y languages
everywhere. But it seems it's not _main-stream_ [1] enough to have tons of
tutorials, books, tools, employees that would appreciate it.. yet.

But I'm getting more hopeful every time I see a new post surface with a new
language or tool that is _lisp-y_.

Btw, this is not the first time I'm wondering this, but could I start using
something like ClojureScript instead of Javascript and be able to use the
libraries I currently use, like I would with coffeescript?

[1]: No something does not have to be main-stream or widely used/acknowledged
as good to be good, but you can't deny it helps. I just don't want to spend my
time learning something that could become obsolete, (in the eyes of
coworkers/employers!)

~~~
grayrest
> [C]ould I start using something like ClojureScript instead of Javascript and
> be able to use the libraries I currently use, like I would with
> coffeescript?

Clojure has an opinionated idea about how data should be handled and changed
over time. This interacts very poorly with data binding so if your current
libraries are Ember, Angular, Knockout, or the like then the answer is no. You
can call into any JS library fairly easily so if you want to use jQuery, d3,
three, or whatnot then it's doable but not in the "it's just javascript" way
of coffeescript.

On the other hand, Clojure fits into the React model like toothpaste in tubes
and the community has switched almost universally (save the Hoplon guys) to
one of the React wrappers. I recommend starting with Reagent [1]. Om has more
mindshare but Reagent's model is considerably simpler. If you need more
structure around the app, check out Re-frame [2]. In either case you want to
set up your project with figwheel [3] (lein new figwheel <project>) and add
reagent/re-frame as a dependency.

[1] [http://holmsand.github.io/reagent/](http://holmsand.github.io/reagent/)
[2] [https://github.com/Day8/re-frame/](https://github.com/Day8/re-frame/) [3]
[https://github.com/bhauman/lein-figwheel](https://github.com/bhauman/lein-
figwheel)

I encourage you to give the langauge a try but I don't really recommend
Clojurescript at work unless you're already working at a Clojure shop. The
language is nicer than Javascript and I care enough about that to take a job
working in cljs full time but the language isn't mature nor enough of a
productivity boost over js (especially babelized js) to justify saddling your
company with a niche language maintenance burden when you leave. If you're
going to evangelize, I recommend starting in Clojure where the win over Java
is much, much bigger.

P.S. I use Vim for everything non-lisp but I use Emacs with Evil mode for
lisps. Evil mode is bar none the best vim emulator I've used and is the only
one I can stand to use on an extended basis.

~~~
MrBuddyCasino
Thanks for the writeup! I'm currently experimenting with Ring/Liberator on the
server side and Mithril on the client, and was unsure whether I should just
use ClojureScript or plain JS. I chose plain JS for simplicity, but damn,
reagent and figwheel look like a killer combination. To me it seems client
side Clojure is a bit harder at first than server side, since most of it has
to do with mutating DOM state - do you think thats true?

~~~
grayrest
It is difficult, which is why Clojurescript adoption didn't really take off
until React (via Om) showed up. The whole point of the virtual dom model is to
avoid stateful DOM manipulation and instead have view code that is an
idempotent (and generally pure) transformation from app state to virtual dom.
This is a great fit for any functional programming language and makes keeping
the DOM in sync mostly a solved problem.

I haven't tried Mithril in cljs personally but it fits the model so you should
be fine with just writing a wrapper function or macro to save some boiler
plate on the cljs to js data structure conversion.

The challenges in the cljs app I'm working on are the same challenges you run
into any app: how do you separate concerns, where does state reside, how do
you keep it in sync with the server, etc. A problem that's unique to React
based apps is how to get data from your app state to a component without
higher level components needing to be changed.

My main annoyance with cljs is that rethrowing errors in Chrome swallows the
stack trace and core.async wraps everything in a try/catch block. This means
that you need to debug by breaking on error, typing `ex.stack` in the console,
and reading compiled JS frames to find the source.

------
TazeTSchnitzel
This could really do with having someone copy-edit. The constant spelling and
grammatical errors make it quite hard to read, unfortunately.

~~~
dkersten
The authors said on the mailing list that they're not native english speakers
and would love if somebody would help them with that.

------
manishsharan
How big are the generated js files for clojurescript applications compared to
say coffeescript or Dart ? The last time I tried it-- when it was still new ,
the files were too big to be useful for 3G Mobile devices. Has that changed?

~~~
swannodette
If you've been serving jQuery (~30K gzipped) to mobile web applications,
ClojureScript has always been a fine alternative. ClojureScript applications
start at around 20K gzipped and go up from there.

