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.
21 thoughts on “Clojurescript: is it any better yet?”
Excellent post mate. I totally agree with you on every thing. I’d like to add that on the server side (unless things have changed) if you target v8 you still need the ‘fat’ JVM. So again most of node coders will never give it a try.
Either I’m an exception or you are wrong. I’m going to use clojurescript for my personal projects and there is a good chance I’ll adopt it for my work.
Pingback: Why I’m finding Clojurescript underwhelming | Echo One
That’s the plan.
Also there’s Prismatic. They use ClojureScript extensively.
There is a single barrier to my adoption of ClojureScript: self-hosting.
My other hopes was. I disagree with enough in Dart to dislike it and it doesn’t have macros.
ClojureScript: (almost) a done deal.
Pingback: Links & reads for 2014 Week 3 | Martin's Weekly Curations
‘However it was never an argument used on the JVM. “Hey Java just has all these edge-cases, why not use a LISP variant instead?”‘
They actually did say just that. They wanted to solve issues involving mutability which are fixed by using the immutable data structures provided by functional programming.
I would say that Clojure’s initial appeal to developers was STM, a standard model for concurrency and non-strict inter-operation with Java and the JVM. This isn’t what is being offered with Clojurescript right now.
Interesting answer! Thanks for the insight into the reasons Clojure came to life.
Saying about ClojureScript I can agree with you now. The combination of browserify, baconjs and mori seems to solve most of the problems I was going to use ClojureScript for.
> This isn’t what is being offered with Clojurescript right now.
> That didn’t require the whole Clojurescript framework though.
Hi guys, may I know someone have any idea about performance of clojure/clojureScript apps on JVM as well as on Node.js vs eg. Scala apps?
Is it possible make compilation of clojure code?What about performance in this case?Great thanks!
All in all, I think most of the people hard at work on JS alternatives disagree there is no future in the replacements. From ELM, Clojurescript and many many others clearly most people disagree.
I’m personally hard at work at my future employer trying to convince the devs there of the merits of Scala.js. Same language on the front and back end is a compelling advantage.
Google’s NACL shows another way there. So the question isn’t if, but when and by what language will JS die. And I will be dancing on its grave!
It’s a bit of circular argument that because people are still working on JS replacements that they have a viable future. As long as Google pumps money into Dart there will always be a viable alternative; but by that logic Smalltalk is still a contender compared to Java and C#.
I think I can agree to most points in your post but one:
There is also a fine aspect to language selection, that comes down to a “DIY”-Ratio. If I have a project that is 90% DIY – I would most of the time start it in Common Lisp. But often server side projects can profit from the work of others and this is were the broad path sometimes pays off in real money. Even sticking with PHP on some customer server which only needs 1% customization of an existing package is clearly better thing than rewriting anything in Clojure. Life is to short to waste time.
As for the situation where it is the appropriate tool for the circumstances, well yes its hard to disagree there.
David Nolen’s React library, Om provides the main case for going with Clojurescript. Om adds significant value to the UI development model in terms of immutable data structures, structural sharing and faster diff-ing. React is catching on like wildfire, steering the UI development model towards functional programming which is where Clojurescript shines. Having the vast range of Clojurescript functions at hand adds significant value. Clojurescript is not mere syntactic sugar.
I cannot predict how widely ClojureScript will be adopted; although it’s a great technology, experience has shown than the web community usually makes poor technological choices.
I think ClojureScript already brings something major to front-end development with real functional programming. I’m willing to migrate to ClojureScript and not CoffeeScript, because unlike CoffeeScript, the problems that ClojureScript solve are *deep*.
Interesting post. I was originally (and still am to some degree) very skeptical about the amount of languages transpiling to js engines. And it is ultimately a duct-tape solution of the highest order – all of it. But that’s evolutionary soup in a way, mutations and all. I see it slightly differently now. Now, I see it as being similar to the Java story, and .NET. The CLR , LLVM, and the JVM were inevitably going to be platforms for a renaissance in language development because the back end is already done and only the front-end of the compiler needs to be developed. No need for assembly programming, and instead focus on lexical analysis and parsing, language design. It makes sense.