Closure Compiler: a tool for making JavaScript download and run faster

with haxe you can have the same effect but with:

- a better dead code elimination thanks to Static Type System,

- code generations with macro functions,

- inlining of functions, constructors, and objects

- static code analyzer

all this things for all the haxe targets(javascript,flash,php,python,java,c#,c++,neko and work in progress lua)

If you just want minification/obfuscation (not dead code stripping), sure, CC is overkill. But if you've got a 3.6M LOC shipping to consumers and not a B2B/intranet app, I can't believe you wouldn't care about an extra 10-20% dead code stripping, that's a non-trivial improvement.

Also, have you tried it recently? AFAIK, there was performance work done on it over the past year or so, speeding up the type checker and other parts of the compiler.

My view is generally, it's better to spend time at compile time. Even if a fully optimized build took 10 minutes, it's not a big deal. Even in an uncompiled mode, presumably your integration tests on a large app can take minutes to run anyway, and with such a large app, you may have a Q/A process as well. That is, your releases will be gated by other factors, not compile times, and so a few extra minutes to save 100k downloads * number of users is a big benefit for your user base and a few minutes of your time.

I would say that if you have any deferred loading, CC's cross module code motion is a fear that all of the other existing tools lack and it can get you far far more than 10% reduction of your initial load depending on how your app is written. Generally the larger the app, the more likely transitive dead code will be pulled into the initial download without something like CC.

> I can't believe you wouldn't care about an extra 10-20% dead code stripping, that's a non-trivial improvement.

Care? Sure, we do, but honestly we can probably get that by being smarter with our code atm. Like I said - it's pretty legacy in many (most) areas.

And to be fair - it was much closer to the 10% figure most of the time than the 20. Sometimes less.

Given our kind of unoptimized dev flow (for JS anyhow, we're pretty good overall) it meant that Closure was just... more of a pain in the ass (for many reasons, the JVM didn't help either, yet another moving part).

So we chose dev productivity over it. When our codebase is more streamlined and modern-looking I think we'll re-evaluate and trust me Closure will be on that list.

> have you tried it recently?

About 6 months ago. Was better, just not as smooth a flow and fast as Uglify was. Glad to hear that it's an ongoing effort though.

> My view is generally, it's better to spend time at compile time.

Generally I'd agree... if it wasn't that our dev flow often had to include compiles (due to... reasons I can't get into here). This is a problem we're working to fix on our end but it did make Closure a lot more annoying, unfortunately. We did used to use it, so I'm not talking from a position of not having used it here :)

> Generally the larger the app, the more likely transitive dead code will be pulled into the initial download without something like CC.

Generally agree. However we have a LOT of strange orphan code (that we're clearing up) which means our dead-code was surprisingly low across the project while perhaps still dead code at some specific point of access.

Annoying? Yes. Edge case? Perhaps. I think it's more common in large old projects than any developer would like unfortunately.

Thankfully there is roadmap and we WILL be evaluating Closure when we get further along. Like I said - I used to be the main cheerleader for it here.

Different beasts. A direct comparison is unfair to either of them.

Uglify does minification and dead code removal. That's really it.

Closure does a lot of type checking, code rewriting, and has a very specific subset of JS that you'll have to use if you really want to get the best performance out of it... and does minification and dead code removal.

If you just want minification/dead code removal then Uglify is waaay faster, javascript native, and almost as small (105-120% of the size of Closure compressed code, depending on the code). It also doesn't use the JVM so that can make dep management/ops simpler if you don't already have java in your stack. YMMV.

If the advanced stuff sounds like something you'd want/need (if you have a large project and don't mind writing to the Closure optimizations) then Closure is certainly worth looking at. It's very good at what it does.

Choose the right tool for the job and all that.

Check out plovr http://plovr.com/