I noticed r15005 turns on more renaming in dart2js with --minify so I thought I'd see the impact on Pop, Pop, Win!

The last time I did a build and deploy of PPW was on r14873.

Here are the sizes of game.dart.js

dart2js	617,201 bytes
closure compiler	621.07KB
gzip (via http)	107.7KB

Notes:

• dart2js is running with the --minify flag
• I'm using the closure-compiler with default settings. Build from 17 Sept, 2012
• Notice how the output is bigger from closure? This is because output is optimized for gzip. Not intuitive, until you see the network panel in Chrome Dev Tools.
• gzip is the size Chrome sees over the wire. Most servers gzip payloads. It's critical to pay attention to this number and not just the size on disk.

Now with the bleeding edge build r15005

dart2js	451,183 bytes	~33% smaller
closure compiler	388.71 KB	~37% smaller
gzip (via http)	90.2KB	~16% smaller

Notes:

• The output from dart2js is substantially smaller. This is just the work from the dart2js guys recently. Amazing.
• This time the output from the closure is smaller than the input (~12%). I can only speculate why. Perhaps the new minified output is more optimizable?
• The gain with gzip is not as big (~16%). I'm not surprised by this. PPW is a pretty big game. The json that stores the texture data alone is huge.

Keep in mind, the Dart source for the game is 1.5 MB as reported by dart2js.

info: compiled 1576654 bytes Dart -> 451183 bytes JavaScript in web/game.dart.js

Is it fair to say we're getting ~94% smaller output? It depends on how valid one considers the the Dart code size reported by dart2js.

But I certainly don't feel I need to justify the javascript output size for non-trivial apps anymore.

Great work folks!