Kevin's company Keming Labs was one of the earliest adopters of ClojureScript and his talk at the second Clojure Conj focused on how they use it, how it helps them succeed, and some of its painful aspects. Specifically, he focused on the use of the D3 JavaScript data visualization library by way of ClojureScript interop. Kevin has contributed to ClojureScript itself by helping to spread the word about its advantages and to contribute fixes and libraries.

How did you discover ClojureScript?

ClojureScript came to my attention either through Hacker News or my Github activity feed. I used Clojure for the first time in 2010 with Ring to build the backend for a document annotation service. Most my work now is clientside data visualization, so when ClojureScript came out I jumped on it.

How are you using ClojureScript in your business

Right now the ClojureScript pilot project at Keming Labs is a hotel analytics dashboard. We've wrapped D3, Mike Bostock's data-driven JavaScript DOM manipulation library, and use it from ClojureScript to build statistical graphics in the browser.

Hotel operators get occupancy and pricing data every week as Excel spreadsheets; we scrape those data using JVM Clojure, throw it into PostgreSQL, and then serve it to the browser using Chris Granger's awesome Pinot + Noir projects. Pinot's "remotes" in particular are pretty cool---they let you make server side calls which return Clojure maps and vectors to the client. So far we haven't needed to muck around with JSON at all.

We have a lot of technical freedom on our projects: clients come to us with handfuls of data and just want a report or some dashboards for their iPad or something. Much of the time they could care less about the backend details. Most of us have mathematical backgrounds (I studied physics in university), and that community has historically had good relationships with functional, REPL-happy languages like R and Mathematica. Since so much of our work is data-oriented, Clojure and ClojureScript have been a great fit.

What are your general feelings about the languages that target JavaScript?

I think they're a good idea.

JavaScript has a lot of reach, but the language itself is half-baked.

Developing large applications and reusable components in JavaScript is very difficult. It takes a lot of discipline and experience to know all the tricks for encapsulating state, namespacing, dealing with multi-arity dispatch, &c. Either you spend a lot of time and mental energy learning this trivia, or you use a language where these semantics are baked-in rather than sprinkled-on "good parts".

An iOS and web developer friend of mine hates these kind of languages and says "you should just develop natively". I'm not sure what that even means, though. It's not like we're running on "JavaScript machines". There are probably a dozen layers between the code I write and what actually gets executed as little nibbles of god knows what on the CPU registers. There is a cost to the additional abstraction of languages, sure, but depending on the complexity of the project and your appetite for risk, the benefits can really outweigh raw JavaScript.

Things are new, definitely; it's the bleeding edge. Sometimes shit breaks, the abstractions leak, and you've got to dive into the JavaScript to really see what's going on. Ultimately I think many of these problems are just bleeding edge issues; fundamentally there isn't anything inherently wrong with building up abstractions. I've never had to dive into C++ to figure out a bug in my JavaScript DOM-manipulation code. Hopefully in a few years I'll never need to look at the JavaScript that gets emitted from my ClojureScript.

The biggest challenges with these kind of languages isn't technical, it's social. For many people, "frontend" means HTML+CSS+JavaScript, end of story. Plenty of folks don't even have a frontend build chain for concatenating and minifying assets, so it can be hard to even talk about languages that compile into JavaScript.

We've been going back and forth with a large scientific journal publisher on this very issue.

So far, things have boiled down to:

  1. We deliver minified JavaScript and you have to rely on us for all maintenance.
  2. We deliver source code in some crazy hipster language none of your people have heard of, and then train them to use some elaborate build process.

The biggest ClojureScript challenge is the same as that of JVM Clojure, or any new language. You have to be very upfront about the risks and benefits and figure out what best addresses the client's needs.

Did you try any of the other languages before settling on ClojureScript?

I moved over to CoffeeScript the summer of 2010 when I realized there are parts of JavaScript I just never want to know about (e.g. 0 vs. "" vs. undefined vs. null). I think CoffeeScript is the best thing JavaScript can be, as a general purpose dynamic language. CoffeeScript's syntax is very clean, and it basically files down JavaScript's rough edges while retaining the semantics. You can train a JavaScript developer to use CoffeeScript in a day or two, and automatically his or her code is just a ton better because the language keeps you from forgetting "var" or otherwise shooting yourself in the foot.

CoffeeScript is a great local maximum. Especially now that it's bundled into Rails, I think CoffeeScript will suffice for most developers on most of today's projects As people start building richer clientside applications, though, they will start feeling the limits JavaScript/CoffeeScript's semantics. I'm not sure how people are going to react to these limits. We're betting on Clojure, but I can easily imagine most developers dealing with JavaScript's language limitations by just building up more libraries and frameworks.

How/where can ClojureScript improve?

Right now stuff is pretty raw. You have to know a fair bit about Clojure and JavaScript tooling to use ClojureScript effectively. When ClojureScript first came out I killed most of a Saturday just trying to get it into my JVM classpath and have it spit out a console.log("hello world");

At the time there wasn't exactly a ton of example projects on Github I could rip off infrastructure code from.

(The complete state of our ClojureScript infrastructure understanding is in the cljs-d3 README.)

Right now all of our ClojureScript projects access the compiler via git submodules, which feels gross. Lein and Cake are awesome at managing dependencies, and it'd be great if there were an official ClojureScript build that integrates into that system (i.e., something you can just add to project.clj).

The browser REPL looks promising, but it is just different enough than the usual SLIME/swank workflow that I haven't really used it much. So far we've been delegating to D3 for DOM manipulation, which means most of our ClojureScript code is statistical / data transformation in nature, so I've been cheating a bit and just using the SLIME. I'm thinking about building a declarative visualization library like D3 in pure Clojure(Script), but before I get really deep into that it might be worth spending some time polishing up a browser REPL starter kit with nice Emacs integration.

ClojureScript the compiler itself is remarkable given its age; pretty much everything I've written that works in Clojure works in ClojureScript. What I'm most excited about is seeing more open source ClojureScript code. Clojure the language is just really elegant, and the community is full of freakishly bright early adopters who aren't afraid of the academic literature. I've learned a ton reading Clojure code, so I'm interested to see how Clojure folks handle the clientside---user interaction, asynchronous processing, &c. Callbacks get gnarly pretty quickly, and the Clojure community and language are powerful enough to explore and implement other approaches like functional reactive programming and state machines.

I'm just a guy who makes charts and graphs, so I'm expecting my mind to get blown as the Clojure community starts tackling the web.