[dojo-contributors] Fwd: Using Dojo 1.6 with Closure -- document attached
Stephen.Chung at intexact.com
Thu Mar 3 03:47:20 EST 2011
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
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
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
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
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
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
- 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
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 --
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.
> -------- 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.
> - 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