Earlier this year I decided to learn Clojure. It’s been a really interesting experience. Along the way I’ve stumbled, by complete accident, on development tools that could completely redefine the speed at which I cut apps.

Blown away

My background is in Java. (No, I’m not going to apologise; Java is a great language.) Due to various start-up adventures, I have stretched my back-end skills across into the browser. I get Javascript, CSS, and markup. I’ve used Meteor, a rapid reactive web framework, on startup projects. I’ve used Google Web Toolkit extensively for enterprise development and a bunch of other lighter Javascript frameworks.

One of the things I’m known for is super-rapid development of prototypes and greenfield projects. I get how to develop software fast. But what I have discovered in the Clojure eco-system has blown me away.

ClojureScript, Om & Figwheel

Clojure can be transpiled to Javascript, using ClojureScript¹. This means you can code your front-end in Clojure, a fully fledged functional language². As a result you can use super-cool things like Clojure’s Communicating Sequential Processes (CSP) implementation, core.async, in the browser.

React

On top of this, ClojureScript has some great libraries, like Om and Reagent, that enable you to program React apps using the Flux dataflow pattern. This means you can code reactive apps using straight forward tools and patterns.

Further to this, the development of React Native means that this development experience can be extended across to mobile and tablet devices. Now this is getting really interesting, right?

Figwheel

But it gets better. Really it does. Because Bruce Hauman, genius that he is, went and created the awesomeness that is figwheel. It’s a fantastic development tool.

Basically, as soon as you save the file you are working on (ClojureScript, HTML, or CSS) figwheel will load the changes into the browser, without you having to refresh. This on its own would be handy. But where it goes from being handy to being awesome is that, in most cases, figwheel will maintain your current in-browser state.

This means if you’re half-way through a wizard, or the like, you don’t have to enter all the data again from scratch, with every code change. You get a real-time, super-iterative, development experience that is light years ahead of other transpiling languages and frameworks.

Bruce did a great demonstration of figwheel live at Clojure West, below.

An honorable mention for Meteor

The only other framework I can think of that comes close to this development experience is Meteor. It’s a great framework. If you want to use MongoDB as your datastore it is awesome, and definitely worth checking out. If you don’t, you have a problem. It only supports MongoDB³.

Meteor also does not do code updates, on file saves, whilst maintaining in-browser state.

Let’s not forget Scala

Not to be outdone, Scala has its own ClojureScript equivalent in Scala.js. Plus its own figwheel in workbench.

Of course being Scala-based, and having static typing, you get better auto-complete and stronger compile time checks. However, the flipside of the coin is that workbench isn’t quite as auto-magical as figwheel, and can’t maintain browser state to the same extent⁴. But it is still very very cool.

It’s worth checking out Haoyi Li, the smart cookie behind workbench, demoing it live at Scala By The Bay:

I predict a riot

… such a catchy tune, it’s going through my head now. So where was I? Oh, yeah … I think the increased iteration speed offered by these newer transpiled frameworks is going to dramatically change the way apps are developed in the Enterprise.

Google Web Toolkit, Coffescript, even Javascript, you are so very yesterday. Move over, the future is here, and it’s real-time development. It’s a game-changer.