A while ago I wrote about how Clojurescript was a square peg being hammered into a non-existent hole to complete indifference by everyone.
So has anything changed? Well Clojurescript has continued to be developed and it seems to have lost some of the insane rough-edges it launched with, it seems possible to use it with OpenJDK now for example.
Some people have made some very cool things by using Clojurescript as a dialect for writing NodeJS code. I was particularly struck by Philip Potter's talk on Marconi.
The appearance of core.async for Clojurescript is in my view the first genuine point of interest for non-Lisp fans. It provides a genuinely compelling model for handling events in an elegant way.
David Nolen, while being modest about his contribution, has also contributed some excellent blog posts about the virtues of Clojurescript. The most essential of which is the 101 on how to get a basic Clojurescript application going with core.async. This is an excellent tutorial but also is underpinned by hard work on getting the "out of the box" developer experience slick via the Mies Leiningen template.
Let's be clear about what a difference this makes. At the London Clojure dojo we once had a dojo about using Clojurescript, after a few hours all the teams limped in with various war stories about what bits of Clojurescript they had working and what was failing and why they thought it was failing. The experience was so bad I really didn't want to do Clojurescript as a general exercise again.
In the last dojo we did Clojurescript, we used Mies and David's blogpost as a template and all the teams were able to reproduce the blogpost and some of the teams were creating enhancements based on the basic idea of asynchronous service calls.
When someone pitches a Clojurescript idea in 2014 I'm no longer in fear of a travesty. That is a massive step forward.
And that's the good news.
Clojurescript! Who is good for!
Why Coffeescript failed
In both languages practitioners of the language are deeply aware of the corner cases of their language. Since they are constantly working with it they are also familiar with the best practices required to make sure you don't encounter those corner cases.
Clojure on the JVM brought power, simplicity and a model of programming that made reasoning about code paths simple.
Better the devil you know?
Visual Basic isn't the best language in the world, it's certainly not the best language for creating apps on Windows. However for organisations and programmers who have invested a lot of time in a language and a platform it normally takes a lot to get them to change.
Usually, it will take an inability to hire people to replace those leaving or the desertion of major clients before change can really be countenanced.
There's no lack of demand for good looking websites and browser hackery to differentiate one web product from the next.
Sometimes there are real advantages to sticking close to the devil.
For me the most interesting area of Clojurescript is being able to write Clojure and treat V8 as an alternative runtime.
People are already noticing some odd performance characteristics where some things run better on Node than they do on JVM, most particularly around Async.
It is still going to be a niche area but it is much more likely to happen than in the client-side.