renaming.clj

;; Step 1) Produce a build with :advanced optimizations. Tell me the size of the .js file.

;; Step 2) Run `gzip` on your output .js file and tell me the size of the .js.gz file.

;; Step 3) Apply this monkey patch:

(in-ns 'cljs.closure)
(import '[com.google.javascript.jscomp VariableRenamingPolicy PropertyRenamingPolicy])
(def wrapped-set-options set-options)
(defn set-options [opts ^CompilerOptions compiler-options]
  (wrapped-set-options opts compiler-options)
  (.setRenamingPolicy compiler-options VariableRenamingPolicy/LOCAL PropertyRenamingPolicy/OFF)
  compiler-options)

;; Step 4) Re-run the advanced build. Tell me the size of the _new_ .js file.

;; Step 5) gzip it and tell me that size now.

Any results so far?

Before patch: 2.5M uncompressed and 644K gzipped. After patch: 5.5M uncompressed and 792K gzipped. @brandonbloom This what you're expecting?

Seeing this is a naming policy experiment and out of curiosity, I set :pseudo-names without patch: 7.6M uncompressed and 994K gzipped. A little surprised naming could effect asset size that much

Before patch: 0.67 MB uncompressed and 0.14 MB gzipped. After patch: 1.6 MB uncompressed and 0.18 MB gzipped.

Sorry, no notifications on GitHub gists, so I won't see/reply to further comments here. Ping me on Twitter if you want to chat.

Some other similar results were reported on Twitter. I expected disabling renaming to produce growth, but am a little surprised by how much: anywhere from 20 to 30% after gzipping. Still, I'm not convinced that the difference is worth the complexity of externs, etc. Even at 30%, we're only talking about a couple hundred kilobytes for self-described "largeish" applications. On today's web, the same cost is about the same as a small handful of profile thumbnails. So outside of bandwidth constrained users (where rich apps are already inappropriate), I'd be tempted to just turn renaming off and focus my complexity budget on code splitting if my application grew too large.