Closure Compiler requires authors to write code in a very specific static style. It's somewhat tedious, but for some libs worth the effort. In the case of ClojureScript we can of course automate the tedium for you through the compiler :)

For random JS libs Closure can't really do much better than Uglify.

> For random JS libs Closure can't really do much better than Uglify.

I wish I could use ClojureScript in my day-to-day, but for now it's out of the question. So, for us, AMD [1] has been a god send. We can defer loading other major parts of our UI until the user actually uses that functionality. Doing this on our own would be impossible, but using AMD has really worked well for us.

But, here's to hoping I can actually use ClojureScript at some future point :)

[1] -- http://requirejs.org/docs/whyamd.html

Yeah, I tried for a couple years to get Google Search to adopt JQuery, but JQuery without dead-code elimination would've doubled the SRP latency, and JQuery with dead-code elimination doesn't actually eliminate any dead code. The problem is that it's written in a style that dynamically assigns methods to the JQuery prototype, and so it's not possible to analyze which code actually exists in the library without executing the whole of the library.

You could build a custom jQuery copy that eliminated whatever methods you don't need. Since plugins use unknown parts of jQuery and Closure Compiler can't always detect that, you really need to do some manual labor to pull in what you need.

In the 1.8 time frame the jQuery devs made a call for people who wanted to use Closure Compiler's ADVANCED_OPTIMIZATIONS to participate, but just didn't get any community interest. CCAO style is not typical JavaScript and it doesn't seem that a lot of people use it.

At that point you're better off just writing the functionality you need from scratch - which was basically the coding standard when I joined Google Search in 2009. They've since moved to allow Closure, which was a big win for developer productivity, but OTOH the latency of the SRP has roughly quadrupled since I joined Google.

Anyway, I'm firmly in the "you don't need JQuery" camp now, since most of its functionality is trivially implementable in one-liners since IE9+. I'm unlikely to go back; I've been using vanilla JS for prototypes for the last 2 years and am using it for my startup now, and have yet to encounter a case where I really miss JQuery. It was a very different world in 2006 when I learned it, or even in 2009 when I joined Google.

Also, I suspect that the overlap of people that use Closure and those that use JQuery is near zero, hence why nobody in the JQuery community cared about CCAO. Both of them are highly non-typical Javascript, as is Angular. JS shows its Scheme heritage in that somehow every major framework results in completely different, mutually-incomprehensible code.

Not sure why you got downvoted. Thanks for the perspective on usage of Closure at Google.

From what I understand, it should work with any JavaScript you feed it. Though, for badly-written source, it may even produce a faulty output when used with ADVANCED_OPTIMIZATIONS. Yikes! (Example from the docs - "Inconsistent property names": https://developers.google.com/closure/compiler/docs/api-tuto...). So it's more about the Closure Library being "certified" to work with it. Someone with more experience feel free to shed some light on this.

Its just a more aggressive version of name mangling that Uglify also 'suffers'[1] from. The setting does say advanced with good reason.

[1] https://github.com/jadejs/jade/issues/298

Closure Library is certainly written in a way that takes advantage of the compiler to keep compiled scripts compact. Code that makes heavy use of goog.dom could look like:

  goog.require('goog.dom');

  var dom = goog.dom;

But that defeats dead-code elimination and makes the compiler include goog.dom in its entirety (the Compiler only goes so far when determining if code is "dead"). So, any use of a goog.dom function will be fully qualified:

  var el = goog.dom.getElement(id);

Practically, you might use goog.dom.DomHelper instead to keep code compact, and because it stores a reference to the document object you're using.

This surprisingly makes ClojureScript really nice for developing with the Closure Library (not that using any library that depends on mutable objects is particularly nice in Clojure), because you can write code like the following, and still benefit from dead code elimination:

  (ns whatever.ns
    (:require [goog.dom :as dom]))

  ;; ...

    (let [el (dom/getElement id])

The Closure Library is impractical without dead code elimination because it includes so much functionality, and is not meant to be used as a single script dependency.

Closure also has a goog.scope call that lets you locally alias various imports, but the compiler is aware of it and can optimize across scope boundaries. Pretty handy - besides dead-code elimination, variable renaming also works with goog.scope and so you don't have to treat each import as an extern and spell out the fully-qualified name in the generated code.