
ClojureScript: Things That Might Worry You, but Shouldn't (2012) - m0th87
http://jasonrudolph.com/blog/2012/09/11/clojurescript-4-things-that-might-worry-you-but-should-not/
======
swannodette
For some deeper rationale of why ClojureScript over other neat compile to JS
languages like CoffeeScript, Dart (via dart2js), and TypeScript check out a
talk I gave recently at the Norwegian Developers Conference, ClojureScript:
Lisp's Revenge [http://vimeo.com/68334908](http://vimeo.com/68334908)

I think the arrival of core.async makes ClojureScript an even more compelling
option as it has the potential to eliminate an incredible amount of incidental
complexity.

~~~
adrianm
I'm already a big fan and advocate of both Clojure and ClojureScript, and
although I've had great success convincing friends and coworkers to give
Clojure a try (and even get excited about it), unfortunately ClojureScript has
been a different animal entirely.

Thus far, everyone I've taught Clojure concepts to really appreciates the
functional bend of the language, immutable values, and of course the elegant
sequence/collection abstractions/persistant data structures that Clojure
provides. But semantics are almost never a convincing argument (for most for
programmers I know) for spending the time to pick up another language.

What really pushes people over the edge in my experience from thinking of
Clojure as "just another Lisp" or a parentheses laden toy, are the amazing
concurrency primitives that Clojure provides out of the box. Once my
colleagues realize how trivial (and fun!) both concurrent and parallel
computation becomes with Clojure, they're hooked and want to dive in.

The talk you gave is probably the most concise manifesto I've yet to come
across of just how much better Clojure's semantics are for, well, pretty much
any complex problem I can think of. You did an absolutely fantastic job with
your assemblage of example functions which definitely shows off the language.

But I know that if I want to convince the company I work at to adopt
ClojureScript as a JS replacement for our client side applications, an
argument for superior semantics is almost never going to get very far.

Clojure (in combination with libraries like Incanter, JVM interop, etc.)
allows me to completely replace R & Python for both exploratory data analysis,
machine learning, and building a powerful backend for any distributed
application with a double whammy of awesome - I get a much better language for
expressing a lot of ideas AND it's fast as hell. I can scale my Clojure code
to a cluster of CPUs for training some model without a second thought. I can
write really powerful software and never feel limited in what I can accomplish
and in the end, project managers/execs just can't argue. Simply nothing else
exists in this class with this combination of agility, functional elegance,
and "enterprise" class power.

Okay, this comment began as a thank you for making a great appeal for
ClojureScript and has unexpectedly turned into... I'm not even sure.

So, TLDR? We need a killer feature that goes beyond semantics for
ClojureScript that fixes something broken and practical in JavaScript. Is this
a seamless and powerful Web Workers VM or abstraction that just works? Is it a
mature core.async in tandem with full featured promises? Is it a new core lib
that makes having to think about client/server interaction a problem of the
past? I just don't know.

~~~
pigs
Very well stated. A few months ago I wrote a post on my company's blog pushing
Clojure, and the ideas just seemed to flow. Now I'm getting around to writing
a specific post on ClojureScript, and even though I love writing cljs code,
I'm having a hard time making a convincing argument to others. There are
however a few things that still stand out about ClojureScript I think, but I
don't think they are mature enough to qualify as a killer app, but mostly just
something to pique the interest of a certain class of programmers.

One is the port of core.logic. AFAIK there is not a comparable Javascript
logic library, although the ClojureScript port does not have all the features
of the Clojure base.

Another novel feature is integration with nrepl via the piggieback library[1].
This allows you to evaluate ClojureScript code directly in your running web
app if your editor has nrepl connectivity. Again, I don't know of a way to do
this with current Javascript tools. But here again, the solution still feels
like it lacks maturity.

I don't understand enough of core.async to really comment, but the excitement
around it seems to point to another rather exclusive bit of ClojureScript
functionality.

[1]:
[https://github.com/cemerick/piggieback](https://github.com/cemerick/piggieback)

------
tieTYT
I went into irc's #clojure to ask if I should use clojurescript for developing
a html canvas based game. Most of the people in the chatroom dissuaded me.
Their main concerns were:

1) there's no source maps. IE: a browser stack trace does not map exactly to
your clojurescript code so it can make things hard to debug.

2) finding and fixing performance issues in your clojurescript would be very
challenging, especially if you're not an expert in javascript already (which
I'm not)

I took their advice but a personal issue I had along the way was, where the
hell is the "hello world" getting started guide!? I was never able to find
documentation that said, "write this simple file and type this simple command
and now you've just built your first clojurescript example". Keep in mind I
cut my research short, but I did put at least 2 hours into it.

So I decided to use coffeescript instead. I think it's closer to the raw
javascript but it's more concise. I haven't had any performance issues and
even though coffeescript is supposed to have source maps, I haven't needed to
use them yet.

It's giving me confidence to try clojurescript for my next project. I think
it'll be an even better experience than coffeescript. The ability to write
your program in one language, front and backend, is really appealing.

~~~
swannodette
We already had have rudimentary support for source maps - in fact it seems
people have already used it to successfully debug their programs. It's not
good enough yet for step-by-step debugging - we're getting there.

This is a fantastic tutorial - [http://github.com/magomimmo/modern-
cljs](http://github.com/magomimmo/modern-cljs)

RE: performance. I don't know who you talked to, but they are misinformed we
spend a ridiculous amount of time on performance. It's certainly possible to
do an HTML 5 canvas game in ClojureScript -
[http://swannodette.github.io/2013/06/10/porting-notchs-
minec...](http://swannodette.github.io/2013/06/10/porting-notchs-minecraft-
demo-to-clojurescript/). It is true that if you want to do a computationally
intensive game you need to know something about JavaScript performance - but
that's to be expected.

~~~
tieTYT
That tutorial link alone was worth me making my comment :)

Yeah I feel comfortable trying clojurescript next time. Thanks for the info.

------
jared314
Previous Discussion:

[https://news.ycombinator.com/item?id=4505168](https://news.ycombinator.com/item?id=4505168)

------
joaomsa
I wanted to try out ClojureScript a while ago, but found the tooling around it
very complex since I also didn't have any experience with Clojure and
Leiningen. Is there a straightforward starter guide around?

~~~
smrtinsert
ClojureScript Up and Running is actually pretty good. Lein I've gotten to know
simply by using it, getting snippets from blogs here and there. Once I get
better with it, I'm curious to see if I could use it for Java builds. It's the
build tool Java ppl have been waiting for I think.

~~~
dktbs
I'm going through "ClojureScript Up and Running" right now, and I'd also
recommend it.

However, for folks who just want to give cljs a try, lein-cljsbuild does make
it pretty easy at this point. Once you have lein and the lein-cljsbuild plug-
in installed, the basic information on how to get a project up and running is
here:

[https://github.com/emezeske/lein-cljsbuild#just-give-me-a-
da...](https://github.com/emezeske/lein-cljsbuild#just-give-me-a-damned-
example-already)

They also include example projects in the lein-cljsbuild repo that make use of
some of the popular clojure web libraries like ring and compojure:

[https://github.com/emezeske/lein-
cljsbuild/tree/master/examp...](https://github.com/emezeske/lein-
cljsbuild/tree/master/example-projects/simple)

------
leishulang
I am expecting the author to mention the single most important factor that
worries most cljs users: the interfacing problem with other JS libraries that
cause by google closure compiler. But apparently he does not use other JS
libs.

And yes, we need Closure advanced compiled mode when ClojureScript ships with
a standard library nearly 7500 lines long.

~~~
swannodette
Interfacing with other JS libraries isn't really a problem - that has been
relatively pleasant for a long time now (:foreign-libs compiler option allows
you integrate arbitrary JS libraries).

Also note that the most popular JS libraries like Underscore.js and jQuery add
little value to ClojureScript given the rich standard library and pure
ClojureScript solutions like Domina.

Integrating with functional frameworks like Angular.js isn't too painful as
evidenced by Weathertron - [http://keminglabs.com/blog/angular-cljs-weather-
app/](http://keminglabs.com/blog/angular-cljs-weather-app/)

~~~
smrtinsert
Not sure what angular buys you when the power of clj is available - way too
low level imo. I wouldn't mind a cljs version of seesaw though, I don't think
something like that is out there yet.

~~~
coolsunglasses
Getting out of the insanely dumb naive DOM smashing pattern is more important
than having macros in your frontend language. I am experimenting with Angular
+ ClojureScript via Clang right now, but if I am forced to make a choice
between the two, ClojureScript _isn 't_ going to win and I do Clojure on the
backend if I'm given a choice of what to use.

