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:
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.
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:
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.