The Silent Llama of Doom

Thoughts from a quiet Llama.



Choosing Clojurescript

Mon 06 March 2017 by A Silent Llama


I have, quite unintentionally, become a web programmer. I never wanted to be. I’ve always preferred doing systems programming - especially system stuff that does not involve GUIs. However there are some distinct advantages to building systems available via a browser - things like deployment, upgrades and availability - and since I work in a small development team I guess it was inevitable.

So I learnt javascript. Not particularly well, mind you. I’m one of those hapless souls who knows jquery more than he knows javascript. The thing with javascript is that, for the most part, it’s perfectly fine. Need to show or hide a part of your webpage? No problem. Click handler on a button? Javascript is easy and jquery is easier. Full complex component with state, validation, ajax, timeouts, access control and who knows what: not so easy anymore.

Javascript, as a language, doesn’t cater for ‘big’ projects. Well - that’s not entirely true - a lot of work has been done to modernize javascript and frameworks like Angular and Ember have come along to fill in the gaps. Things like commonjs help for structuring things. All in all Javascript isn’t nearly as bad as it was. The thing is I, personally, don’t like the language enough to want to become an expert in it. It’s really just a personal preference. I don’t mind it. I just want something else.

So - why Clojurescript in particular? Why not Scala.js? Or Elm? Or even Coffeescript?

Well - for some reason I’ve never clicked with Scala. It seems to be one of those languages I should really like but we keep missing each other. I can’t even give a good reason for it. Similar for Coffeescript - I tried it out but we never became friends (and it’s basically died out - looks like no one uses it anymore).

As far as Elm goes it looks fantastic but I had some trouble getting going with it - the tooling doesn’t seem to be good enough yet. It makes me think of clojurescript actually - when I first tried clojurescript I dropped it because it didn’t seem to be mature enough. So I’ll review Elm again in a while. (Edit: I’ve managed to get everything working now with Elm - looked like I was having issues with an older npm install. I like the design a lot and will definitely review at some point).

There are probably lots of other options. The thing is Clojurescript circa 2017 is a very different animal to the one I first saw back in… 2012 was it? The tooling works. I don’t need to fiddle for hours to track down some strange dependency or mismatched Java version or whatever. You can create a project and be productive in minutes (seconds even). The library eco-system is flourishing. There are some remarkable technologies that Clojurescript has now that makes it a compelling option (Reagent and core.async being two that immediately come to mind).

Clojurescript provides some nifty features for complex web applications: namespaces, immutability, core.async, protocols, property based testing, core.logic, schemas and even monads if you’re feeling that way inclined. If you want to use the latest fashionable javascript framework - you can! There are lots of options for interoperating with javascript and it’s easy (for the most part). All this comes pretty much ‘out-of-the-box’ (if you define ‘out of the box’ as ‘plus one or two dependency lines in your project.clj file’).

I recently went all in on clojurescript on a project where I work. I had some complex components that I had already built in javascript using Handlebars.js. Now I really like Handlebars - it can get you pretty far and I still use it for less complex work. But for this I realised I needed something better. Just using Handlebars meant I was managing all the complexity myself. This was the use case for things like Angular and Ember. There were a few options but I decided to take a risk - I rewrote everything in clojurescript. It took me less than a day to get a result that was more stable and had more features. (To give you an idea - the component had an editable grid, calculations based on the values entered, a graph that updated dynamically based on the calculations/values, the ability to load old data and save new data and validation for all of the above. All that in less than a working day. The only thirdparty code I used was highcharts for the graphing and I’m very tempted to rip it out in favour of d3).

So that’s why I’m using Clojurescript. I still have a lot to learn about it but I managed to be productive pretty quickly despite having known javascript for much longer.

Having said all that I would be remiss not to mention the downsides. There are a few. Error messages are the perennial bugbear of the new clojure programmer. The problem with being a hosted language is that all errors come from the underlying host (i.e. java or javascript) which results in long stack traces of a lot of stuff that you aren’t interested in. For the most part I’ve managed to survive these but it is tricky. The second issue is that clojure has a steepish learning curve for programmers who may not be used to a) lisp or b) functional programming. This might make it difficult to introduce to development teams bigger than 1. Also Lein (the clojure build tool) is pretty slow so you end up relying on tools like figwheel to mitigate the long build times (Figwheel is pretty awesome though).