I’m fully aware of that. In fact lots of projects use the Closure Compiler or at least give you the option of doing so because it is so good at what it does. However a year or so ago a lot of the ClojureScript resources available (not related to Reagent or Om) would showcase code that goes straight to goog.events and goog.dom for the usual interactions with the browser, making the Closure Library seem to be the de facto standard. And there is some incentive to use the Closure Library because:
The Closure Library is server-agnostic, and is intended for use with the Closure Compiler.
“Modern ClojureScript” actually balked that trend by using a forked version of Domina instead of goog.dom and goog.events - only later succumbing to using features like goog.Uri and goog.net.XhrIo. Even back then Domina was essentially dormant so I can only speculate at the reasoning behind the choice. Maybe because Modern JavaScript: Develop and Design (the book the tutorial is based on) uses jQuery or maybe because more frontend developers are familiar with jQuery than the Closure Libraries. “Modern ClojureScript” also bypassed Hiccup which seems to be the de facto Clojure(Script) standard for expressing HTML.
While the Gmail beta was launched in 2004, Closure Tools didn’t become available to the public until 2009. By that point in time jQuery had already been fueling the a lot of frontend development since 2006. I just fail to see what “the Java mindset” embodied by Closure Tools had to contribute to frontend development - Google had the resources to develop tools to abstract away the cross-browser differences while building on the “Good Parts” of JavaScript. Now obviously Google can do whatever it wants.
In 2009 I happily used jQuery so I didn’t have to deal with cross-browser issues. But now in late 2017 I view jQuery as much less relevant - in fact it seems that projects now often have to remove any dependency to jQuery in order to continue to attract new adopters (and contributors). So when it comes to adopting ClojureScript in late 2017 it’s typical dependencies (even when they are optional) need to stand up to similar scrutiny. Now it makes sense for Google to stick with Closure Tools given how heavily they have invested in it - but that doesn’t mean it’s a good idea for non-Google entities to adopt it or something that potentially depends on it in late 2017.
ClojureScript was introduced in 2011 and back then it made sense to leverage every bit of existing technology to move forward. For Clojure it’s easy enough to accept the “JVM/Java” shining through because it has to run on the JVM anyway. But I found for that for ClojureScript these “ties to Java” get annoying rather quickly (which was more pronounced when I was referencing the Closure Libraries). In an isomorphic/universal full stack situation this may be a minor issue as you are tied to the JVM for Clojure anyway. But I remain unconvinced of the “isomorphic/universal advantage” - backend and frontend development are very different and as such probably benefit from different languages, each more suited for their particular target environment. ClojureScript’s persistent data structures are nice but in the absence of Clojure(Script)-style frontend libraries (maybe there are some now?) writing LISP Flavoured JavaScript (like (.-value (.getElementById js/document "email"))) or fiddling with Java-style JS libraries didn’t really create a compelling case for using ClojureScript on the frontend for me.
