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!
After the dojo there were some serious discussions about using Clojurescript in anger. The conversation turned eventually to GWT. In case you don't remember or have never met it GWT is essentially a browser client kit for Java developers. In London it gets used a lot by financial institutions that need rich UIs for small numbers of people. Javascript developers are unlikely to be hired by those organisations so just like Google they end up with a need but the wrong kind of skills and GWT bridges the gap. A Java developer can use a familiar language and off-the-shelf components and will end up with a perfectly serviceable rich client-side app.
There is no chance in hell that a Javascript developer is going to use GWT to build their applications.
Clojurescript feels like the same thing. Clojure developers and LISP aficionados don't know a great deal of Javascript, they can program in Clojurescript and Google Closure and it is probably going to be okay. Better in fact than if they tried to create something in an unfamiliar language with all manner of gotchas.
But there is no chance in hell that a Javascript developer is going to use Clojurescript to build their applications.
Why Coffeescript failed
The reason I say this is because Coffeescript, a great rationalisation of Javascript programming is still viewed with suspicion by Javascript developers.
I asked some at a recent Javascript tech meeting why some people didn't use it and the interesting answer was that they couldn't really understand its syntax and were effectively translating the forms into Javascript. The terseness of the language was actually off-putting because it made it harder to mentally translate what the Coffeescript program was doing.
Adding LISP and Google Closure into that mix isn't going to make that mental disconnect any easier. The truth would appear to be that Javascript developers are simply not that disenchanted with their language. Clojurescript is going to have to offer something major to get over the disadvantage of a non-curly brace language and machine-optimised generated code.
At the Clojure dojo post-mortem people talked about the fact that Clojurescript helped avoid pitfalls and unusual behaviour in Javascript. That might seem a rationale argument to a Clojurian. 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?".
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.
Clojurescript has the same advantages of code structure but doesn't really give more functionality over Javascript and still has a painful inter-operation story.
Javascript: the amazing evolving language
Javascript has a strong Scheme inheritance meaning that it already contains a lot of LISP inheritance.
Also unlike Java which ended up with a specification that was in the wilderness for years, Javascript has managed to keep its language definition moving. It's sorted out its split and with aggressive language implementers in the form of the competing browsers it is rapidly adding features to the core of the languages and standards for extensions.
Javascript is almost unique that when lots of people wrote languages that compiled into Javascript the community weren't stuffy about it but actually created a specification, Source Maps, that made it easier to support generated code.
Javascript has a lot of problem areas but it is also rapidly evolving and syntactic sugar and new language constructs are adding power without necessary creating new problems or complexity. It is expansionist and ruthless pragmatic, just like Clojure on JVM in many ways.
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.
Javascript developers are in the same sunk-cost quandary but there is nothing on the horizon that is going to force an external change. There may be better alternatives but Javascript is one of the easiest languages to learn. It's highly interactive and its right there in the console window of this very browser!
There's no lack of demand for good looking websites and browser hackery to differentiate one web product from the next.
Regardless of the technical merits of any alternative solution offers, and we are not just talking about Clojurescript, Elm offers a similar set of advantages, the herding effect is powerful. Your investment in Javascript is far more likely to pay off that putting time into one of the alternatives, none of which have momentum.
Sometimes there are real advantages to sticking close to the devil.
Node.js
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.
Polyglot developers are a familiar sight in the server side, knowing a variety of languages is advantage for the general programmer. Server-side Javascript is really only for those who are a one-trick pony.
It is still going to be a niche area but it is much more likely to happen than in the client-side.
Echo One 
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.
“But there is no chance in hell that a Javascript developer is going to use Clojurescript to build their applications.”
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
“But there is no chance in hell that a Javascript developer is going to use Clojurescript to build their applications.”
There seems to be a chance in hell though. In fact my day job is in Javascript and I spend basically all my free time with ClojureScript, writing my applications.
Okay, so I stand corrected of sweeping rhetorical assertions but if you use Clojurescript in your personal projects and Javascript in your week then you are actually proving the general point. Until you persuade your colleagues to adopt Clojurescript you aren’t changing the consensus in your community.
That’s the plan.
Also there’s Prismatic. They use ClojureScript extensively.
http://blog.getprismatic.com/
There is a single barrier to my adoption of ClojureScript: self-hosting.
JavaScript has horrid semantics that I can’t run away from it fast enough. CoffeeScript mostly changes syntax and TypeScript helps only a little in avoiding stupid JS semantics.
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 understand what you’re trying to say here but before Clojure the majority of LISPs were mutable. Clojure was able to use the JVM’s Atomic wrappers to implement STM which isn’t available within Javascript engines at the moment.
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.
I would acknowledge that porting Clojure’s immutable data structures to Javascript has provided obvious utility to Javascript developers. That didn’t require the whole Clojurescript framework though.
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.
core.async has a pretty solid concurrency model and I’ll certainly take that over callback hell any day of the week. While ClojureScript doesn’t have all of Clojure’s reference types, it does have atoms which are still useful (e.g. with add-watch), idiomatic to use, and make very clear what is state and what isn’t (outside of the JavaScript world).
> That didn’t require the whole Clojurescript framework though.
No, but it did help encourage the JavaScript community to take immutability more seriously (ImmutableJS, NPM, etc.).
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!
I don’t have any particular insight into stats and comparative performance but Clojure code is normally ahead-of-time compiled and it isn’t being dynamically interpreted so there is a “high-performance” mode. If you use type-hinted or type-dispatched code then it’s probably in the range of three times slower than Java code. Performance in Javascript is going to about the same because you’re actually running Javascript.
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:
“…Server-side Javascript is really only for those who are a one-trick pony.”
To some degree – Javascript is the “C” of the web platform. There is no reason to badmouth people who can acknowledge the merits of that.
I think I’m quite polyglot: Mainly doing stuff in Common Lisp, JavaScript, C#, Java, Python, C, C++ and having at least did some small projects in Prolog, Haskell, Scala, Dylan or Ocaml. As a language addict I have looked at nearly any upcoming “trendy” language (Including Clojure and ClojureScript 😉 ). I’m using mostly Common Lisp and C# in server side settings. To some degree even PHP (shudder) – but mainly because it is still the dominating “cheap” server side platform – but I do not really write much code in it. In the last years I switched many projects over to Node.js which in most cases means JavaScript. JavaScript has the biggest chance to play a similar role to what PHP is now. I think this would be a good thing.
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.
I’m using Javascript on web projects which sit within a DIY ratio around 50%, where I may have to write substantial code, but still want to be able to reuse other stuff.
I don’t really agree that Javascript is like web platform C. I think a more accurate analogy would be something like Visual Basic, it’s not a low-level language and its origins as a script language accounts for a lot of the weird behaviour.
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.
I suppose I should have seen it coming with JS too once Google released the V8. In a way it makes sense but make no mistake, we are here now due to fast js engines, not javascript itself. Java and C# certainly owe success to the JVM and the CLR respectively. The difference of course is that nobody really programs in IL JVM bytecode or CLR, whereas Javascript was created deliberately for high level programming. So the obvious question remains, will Javascript triumph over the newcomers and should it. The answer is no and no. It’s an awful language. I think the original creator, Eich, would role in his grave if after all the language renaissances we’ve had over decades of research across multiple paradigms, that plain old javascript (a language created in 10 days) should become the preeminent language for logical thought, finance, business process, and even science and engineering applications ubiquitously across the internet. I doubt it. Transpiling to js code is a duct tape solution but ultimately it works. I think we need to have variety of languages targeting it. There is certainly a place for Clojurescript, Typescript and the others targeting js engines. It would be nice to have a more sane generic intermediate web language akin to the JVM, or CLR, LLVm and frankly I think it should happen and supplant what we have now, but for now, it’s js engines.