Nathaniel Knight

Reflections, diversions, and opinions from a progressive ex-physicist programmer dad with a sore back.

Building Noughts-and-Crosses in ClojureScript

I've been experimenting with ClojureScript for front-end development to avoid the hype and chaos attendant to JavaScript. I've been particularly taken by Om, from David Nolen (whose blog, webinars, and conference talks are incidentally fabulous and highly recommended). Om has practical upsides like good documentation and an active community. It also enunciates a coherent picture of how to do front end development with immutable data structures, a virtual DOM, and the power of Clojure's core.async.

The Project

NAC is a simple noughts-and-crosses (or tic-tac-toe) game implemented in about 200 lines of nicely formatted and commented ClojureScript (and another ~100 lines of HTML and CSS). Adopting some of the tricks in David Nolen's core.async webinar, I settled on a design where the leaves of my DOM tree generated events when clicked which were propagated through core.async channels towards the app's top-level until they reached a scope where they could be effectively handled.

For example, clicking on a filled space in the board generates an event which is immediately squashed. A filled cell knows that nothing will come of that action, even with its narrow perspective.

By contrast, a click in an empty cell needs to propagate to the top level (where we track whose turn it is) in order to move the game to its next state.

This sort of architecture certainly has pitfalls, and I expect having to deal with more kinds of event and a more complicated app-state will require more careful design. ClojureScript provides lots of facilities for working with this kind of hierarchy; I used none of them, but it's comforting knowing they're there for when I want to build something less trivial. The broad strokes of the architecture felt suitably de-complected and scalable.

Some Headaches

The ClojureScript build process and ecosystem is (I hear) much-improved from the bad old days, but it's still by no means a straightforward and smooth process. The documentation for the cljsbuild Leiningen plugin is wanting,

Hopefully Chestnut, (a collection of best-practices and solid tools for interactively building and compiling front-ends with ClojureScript) will alleviate some of these problems. It's been very promising to work with, and I hope it goes some way to alleviating the worst headaches of developing interactive front-ends with ClojureScript.

The Virtuous Learning Curve

Om and ClojureScript are less intuitive, smooth, and approachable than front-end frameworks with bona fide beginner-friendly tutorials (such as Ember or AngularJS) and vanilla JavaScript with its vast community and extensive tool set. However, I expect the extra ceremony to be more than work the benefits of real modules and dependency management alone, and the payoffs of using pure functions on immutable data-structures aught to increase with use.

The extra work put in to get from zero-to-sixty with ClojureScript isn't arduous, and it feels like laying good groundwork for further acceleration.