Taking the 'splitting' argument head on, I don't believe that having a planned split between 'front end' and 'back end' developers is a good idea at all. It wasn't a great idea way when we used to have dedicated DB specialists who would always write the SQL, or dedicated Ops specialists who would deploy our JARs, or dedicated QAs who would write the automated tests. We ought to see the act of handing over chunks of the application codebase to other agencies purely as a last resort, a devil's bargain only to made when we have no other realistic option.
When you have such a large split, there's the huge communication overhead with both parties having to meet in the middle, that prohibits a lack of sheer experimentation and rapid prototyping. Both sets of developers lose a degree of ownership of the entire solution, and with such a reticence they opt for the lowest common denominator path of least resistance. The debates range from how much HTML the server-side should serve, as to the contracts of AJAX requests, WebSockets and server-side-events. What really underpins such conversations - often unmentioned - is of which side should philosophically "own" the heart of the application as the commander in chief, with the other side being more servile. This jostling of positions leads to unwitting compromises being made, and becomes a tenuous foundation for developer relations.
Should developers be so prideful in their work? If you want a simple and elegant codebase, leading to a system with less bugs and less bloat, then pride is essential. Lovingly crafted aesthetics in a codebase is key, where beautiful code matters more than carving it up and fostering it out amongst a larger team. We need to be able to 'live' in our software, to inhabit it, not to treat it merely is a soulless workplace. As Richard Gabriel talks about 'Habitability' in his "Patterns of Software":
"Software needs to be habitable because it always has to change. Software is subject to unpredictable events: Requirements change because the marketplace changes, competitors change, parts of the design are shown wrong by experience, people learn to use the software in ways not anticipated... Habitability makes a place livable, like home. And this is what we want in software — that developers feel at home."
If you want a developer-led culture where developers are free to come up with the best UI possible, then we need to avoid having a preemptive split between front-end and back-end, and allow the situation to grow more organically.
Is ClojureScript Ready?
There have been a couple of recent game-changers.
First, the tooling has greatly improved. With
boot as two different options, we have an uncomplicated ability to reload ClojureScript changes on the fly, and this makes for a hugely fun and productive development experience. The ClojureScript compilation times have also sped up, to the point where there are hardly noticeable.
Second, we have React capability, with Om leading the way in allowing us to create React components. Along with
core.async to handle callbacks, we now have everything we need to build extremely rich single page front-end applications. There are other ClojureScript React frameworks offering different aesthetics to Om, but with Om we have an established and well supported forerunner, and there is an argument to made for staying marginally conservative in the choice of client side framework. On the client side at least, it is refreshing to have fewer options.
An Exciting Future
One gets the sense that ClojureScript is taking off, and there's a buzz starting to be generated that ClojureScript could well overtake Clojure itself, the parent language running on the JVM. The core team led by David Nolen are working on ClojureScript being bootstrapped from ClojureScript, essentially meaning that you can program ClojureScript without a JVM in sight. The reason for doing this, as Rich Hickey puts it, is 'Reach'. ClojureScript without the dependency on the JVM for compilation will reach into places far beyond the server-side origins of Clojure. Mike Fikes has recently capitalised on this to ship an iOS ClojureScript REPL.
React itself is also evolving and ClojureScript is keeping pace. David Nolen recently announced 'Om Next'; the future of Om. Om components will able to specify GraphQL like paths to the sub-tree of UI data the component needs. Om will then take care of ensuring the component gets the data, and that future data updates are synchronized.
This is the final reason why ClojureScript is becoming a compelling choice. It's keeping up to date with the latest advances to come out of the most powerful developmental institutions, and is adding a layer of polish and Clojure-like functional simplicity on top. This is happening because Clojure is a good fit for where web programming is going; the emphasis on functional code working with immutable data, which is what React is all about.
ClojureScript is ready for prime-time and is heading into a new make-or-break phase of popular usage. For existing Clojurians however, it allows us to follow the dream of building simple yet powerful software with smaller teams, where we can write as much code as we can in Clojure, preserving the benefits of immutability and of the bottom-up Lisp philosophy.
Discuss below or join the discussion on Hacker News.