ClojureScript Is Not CoffeeScript
We’ve all felt the pain of investing time and energy into learning some tech or library, only to later abandon that choice in favor of the Newer, Better, and Faster™. We’re lucky if it’s only a new library, practically starting over if it’s a new framework, and probably looking for a new job if it’s a new language.
With the stakes that high, it’s certainly a foolish decision to choose an “obscure language” like ClojureScript, right? Why would we expect ClojureScript to be any different than CoffeeScript?
ClojureScript is a Lisp
ClojureScript has Clojure
If anyone were to create a language to supplant ClojureScript, they would simultaneously need to overcome the value provided by Clojure and ClojureCLR. In other words, to convince me to choose some new (or old) language over ClojureScript, you’d also have to provide an equally compelling story for Clojure and ClojureCLR.
Additionally, each community benefits from the existence of the other. If David Nolen et al. decided to abandon their work on ClojureScript, it would be in the interest of the Clojure community to continue the work. The existence of Clojure makes the death of ClojureScript much more unlikely.
ClojureScript is a Stable Language
Part of Lisp’s value is that the language is tiny. “Many of the core constructs of Clojure are not built-in primitives but macros just like users can define.” That means that there just isn’t much to the core, so there isn’t a large surface area for things to change.
Most of the innovation occurs in libraries. Because of that, ClojureScript developers are free to choose if and when to adopt a new thing. They’re also free to implement new features that would be core changes to other languages (e.g. core.async). And if we make a bad choice, it’s a library that can be deprecated instead of a core language feature that we’re stuck with forever.
ClojureScript has a Stable API
Rich Hickey talks about breakage vs growth as a more precise way to think about change. Relaxing requirements is growth, i.e. change that is safe for our users. Stricter requirements and removal is breakage, i.e. change that breaks what we provide for users. Having this design philosophy means that we’re not constantly abandoning code due to incompatible new features. While frameworks and libraries change, even in the ClojureScript world, code written from today looks very similar to code written years ago.
As professionals, we are obligated to make decisions based on the needs of our customers and stakeholders. When it comes to explaining ClojureScript and the risk of ending up with a dead language, we have a very good story to show it’s a low risk decision.