[dojo-contributors] Fwd: Using Dojo 1.6 with Closure -- document attached

Stephen Chung Stephen.Chung at intexact.com
Thu Mar 3 03:47:20 EST 2011

Hi Rawld,

You've raised very valid questions, and I think you're absolutely right. 
The Closure Compiler is not for everybody.  Its restrictions, pain and 
limitations must be counter-acted by huge benefits; if there are no large 
benefits, then it is really not worth to use it on a project.

Currently, I think that the compiler is worthwhile to use only on projects 
that require very small, very tight JavaScript code (e.g. for use on a 
mobile device).  With more CPU and RAM on mobile devices in each new 
generation, in a year or two even this need may go away.

Regarding some of your points:

1) Properties renaming: my opinion is that it is really valuable only for 
obfuscation purposes, not actually saving bits, although I did get a roughly 
1/3 smaller file after running through the compiler than with the regular 
build (compress with closure in simple mode).  I expected the gzipped 
difference to be minimal, but strangely the difference is again roughly 1/3. 
I suspect that is more due to elimination of not-used functions than due to 
variables renaming.

2) Dead code removal: Dojo is already very modularized so there is much less 
to gain.  Moving to AMD format should make it even better.  However, even 
for highly modularized code, I remember based on Google's analysis (that I 
have read somewhere) that roughly 1/3 to 1/2 of library code is typically 
not used -- not every application calls every function.  For example, it can 
potentially reduce the essential Dojo core portion to, say, to 50K from 89K, 
depending on what functions are used.  That savings of 40K really is not 
much of a benefit, especially when the web app is 500KB and up...

* Note: Due to the particularities of the language, I believe that any 
dead-code removal algorithm for JavaScript must eventually come up with the 
same roadblocks faced by the programmers of the Closure compiler and will 
require similar restrictions, so my point is that in *any* dead-code 
elimination scenario, we'll have to do similar things to make sure that the 
code is easy to analyze.  Therefore, the learnings from using the Closure 
compiler will be beneficial regardless.  Now, it may not be that we'll 
always *need* to remove dead-code...

3) What I find beneficial is flattening of namespaces and virtualization of 
prototype methods.  These have great performance benefits, especially on 
slower mobile device.  However, with fast mobile CPUs and better browsers, 
or with the move to AMD format (which eliminates namespacing), namespace 
flattening will be superceded.

4) Virtualization of prototype methods currently cannot be done with 
dojo.declare'd classes.  However, it can be done for third-party libraries 
though.  I refactored a library that I use (LINQ.js) and Closure largely 
eliminated the performance penalties from using LINQ by virtualizing entire 
call chains.

5) Function inlining -- currently this has great performance benefits when 
it happens (though the restrictions are so severe that it rarely happens). 
It is great for single-trace code that is written in a way that makes it 
flexible to re-configure with different options but automatically inlined 
and have all these abstractions unwrapped by the compiler -- something like 
dependency injection which can produce an optimized build for each config. 
In fact, this is how Google handles i18n -- an optimized build for each 

6) Code rewriting -- can probably be done by any build processor with a 
JavaScript parser.  I notice that Uglify already does much of what Closure 

So, as much as I like the Closure Compiler, I must admit that you are right 
in many aspects.  Especially that, when we move to the next few generations 
of mobile devices, and Dojo moving to AMD, there may not be a need to remove 
dead code, flatten namespaces, virtualize prototype functions and etc. 
Renaming of properties is only valuable for obfuscation (although for many 
commercial web apps, this is a great benefit).  Inlining only valuable for 
making optimized builds based on a settings file.

So, to wrap up my long rantings, improvements to mobile hardware/browser and 
to Dojo will render the Closure Compiler less useful, except for several 
potential areas:

    - Very small projects that require the smallest downloads (where savings 
a few KB's on dead code elimination on the library actually makes sense)
    - Using Dojo with non-Dojo third-party library code (that is written in 
a style to take advantange of prototype virtualization)
    - Obfuscation of application logic
    - Making optimized builds based on a (large) set of settings that 
permeates throughout the application

- Stephen

-----Original Message----- 
From: Rawld Gill
Sent: Thursday, 03 March, 2011 3:30 PM
To: dojo-contributors at mail.dojotoolkit.org
Cc: Kris Zyp ; Stephen Chung
Subject: Re: [dojo-contributors] Fwd: Using Dojo 1.6 with Closure --  
document attached

Hi Stephen,

Thanks for sharing this excellent analysis (and Kris for bringing it to the
list); I know everybody is aware of the amount of work that goes into
something like this.

I've been doing some research/dev/thinking about optimization for a while 
Here are a few observations about optmization in general and closure's
advanced mode in particular...

re the advantages of renaming to short names:
Since symbol renaming causes lots of problems, it may be wise to ask, "is it
worth it?" The answer may be surprising. We've already has a discussion on
this list about the futility of renaming "dojo" to "d". Bill even prooved 
it *made the gzipped code larger*!!

I did an experiment last year where I renamed all the variables in a medium-
sized project to 2 chars. The different between long/short name versions 
both were  simple-mode-compiled + gzipped was very close to zero (I don't 
remember which was smaller).

My feeling (no hard data to prove) is that lexical renaming (as in simple
mode) is worth the cost (zero). Complex renaming w/in the dojo lib for
versions intended for general use (e.g., something on a CDN) is probably not
worth it; complex naming for a built project *may* be worth the effort.

re elimination of dead code:
Dead code is just one kind of advanced optimization that can be made if the
optimizer does real data flow and control flow analysis. (btw, you mentioned
that closure did not handle aliases correctly...this causes me concern for 
good it really is). Some of these optimizations are localized (e.g., common
subexpression elimination); some global (e.g., elimination of a function
that's never called). So...

  * given the quality of dojo, I doubt there'll be a huge gain by applying
aggressive local optimizations to the dojo/dijit library
  * aggressive optimizations sometimes introduce obscure bugs
  * simple dead-code branch removal does not require these kinds of
optimizations; it's already planned and being used with has.js, the 
optimizer, bdBuild, and, even ye-olde dojo 1.x build/programa system
  * global optimizations (like eliminating never-called functions) may be
doable using safer/simpler methods than advanced closure.

So, the key economics question is which has higher value: building tooling 
that advanced closure does something useful or tooling our own optimization

I don't have an answer...only the question:)


On Wednesday 02 March 2011 05:38:43 Kris Zyp wrote:
> Stephen Chung has been researching the possibility of using Closure's
> advanced mode on Dojo to create highly compressed builds that eliminate
> dead code, and shorten property names. Attached is a document detailing
> his results. This could be very helpful in guiding our decisions about
> how to achieve extremely compact Dojo applications.
> Thanks,
> Kris
> -------- Original Message --------
> Subject: Using Dojo 1.6 with Closure -- document attached
> Date: Tue, 1 Mar 2011 13:06:57 +0800
> From: Stephen Chung <Stephen.Chung at intexact.com>
> Organization: Intexact Technologies
> To: Kris Zyp <kzyp at dojotoolkit.org>
> Hi Kris,
> I have put together a TODO document (attached) detailing how to use Dojo
> 1.6 with the Closure Compiler.
> Please help take a look, and perhaps put in on somewhere that people who
> wants to know how to do this can get some references.
> Thanks!
> - Stephen

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3478 - Release Date: 03/03/11 

More information about the dojo-contributors mailing list