Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

developers.google.com

Post reply on HN
Print view View original

71–77 of 77 posts

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

#71

Post by fixermark »

cromwellian wrote: post #54
abritinthebay wrote: post #51

Earlier quoted context omitted.

> I work on Gmail/Inbox Hi there, love the work you guys do. For perspective: I used to be the Closure cheerleader in our company. You don't have to sell me on it, I know it has very good features. > not even our codebase takes 10 minutes It's probably better than ours. Not going to argue that. I think if our codebase wasn't a giant legacy beast it would perform better. It doesn't though :( > engineers at Google typi…

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 o…

Since we're reasoning about a concrete case (abrinthebay's codebase): Wouldn't the amount of code-stripping benefit be directly proportional to how much unused code the codebase has?

It's possible in abrinthebay's scenario, they simply haven't crammed in so many Javascript libraries that the code-stripping can find 10-20% unused code.

(I'm also having a hard time avoiding calling "the code stripper yanks 10-20% of my code" an indicator that one's choice of libraries is wastefully large, but that's a separate thread of debate).

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

#72

Post by klibertp »

sa_su_ke_hx wrote: post #52

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)

But, for what it's worth, without a "seamless JS interop" - and without Haxe being JS.

For me these are of no concern and I'd probably use Haxe had I the right project for it, but for most JS-and-only-JS people it's a deal breaker. I will never be friends with one of those programmers.

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

#73

Post by cromwellian »

fixermark wrote: post #71
cromwellian wrote: post #54

Earlier quoted context omitted.

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 o…

Since we're reasoning about a concrete case (abrinthebay's codebase): Wouldn't the amount of code-stripping benefit be directly proportional to how much unused code the codebase has? It's possible in abrinthebay's scenario, they simply haven't crammed in so many Javascript libraries that the code-stripping can find 10-20% unused code. (I'm also having a hard time avoiding calling "the code stripper yanks 10-20% of my…

It's unavoidable in a large project unless your build dependencies are down to the method level. Typically library targets don't supply a single method, they supply a file which has a number of methods, and not all of them are used.

But even in the case where you don't get dead stripping, you'll still get deferred code motion. And even if you don't get deferred code motion, you'll still get better renaming, because with type analysis, you can know which properties are disjoint from others.

At some point the argument gets into the "I don't need a C compiler, because I already write fast, efficient ASM code" territory. If your code base is perfectly gardened, ok, you don't need any compiler tools. The statistically likelihood of that situation remaining stable as your project ages and adds more developers approaches zero IMHO.

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

#74

Post by abritinthebay »

swannodette wrote: post #64
abritinthebay wrote: post #38

Having used both this an Uglify... I can't recommend this. It's slow. Like... really slow to build. Uglify takes ~10seconds on my code whereas CC took around 10 minutes. Plus the performance benefits - while real - provides very little useful speedup that the V8/whoever JIT won't do anyhow. Even in tight loops. It's VERY cool, but will add minutes to your deploy/compile time for very little practical benefit. If you'…

I'm very curious how you're coming up with your Uglify performance claims on this thread for a near 4MLOC JS codebase. I just tried Uglify on 6mb of ClojureScript generated JavaScript (it's nowhere near 4MLOC) and it takes nearly ~34 seconds on 3.5ghz iMac. That's 3 times slower then your 10 second claim for your own code base which sounds orders of magnitude larger! 3-4X slower than Uglify I could believe, but sayin…

I wish I knew what to tell you.

I've never seen more than a minute on our codebase for Uglify. It could also be we were doing something stupid with Closure and slowing it down (like stopping then spinning up the JVM for each package for example) which is certainly possible.

However if we add in some of the more computationally heavy Uglify options it will go up somewhat.

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

#75

Post by paulddraper »

I have used the Closure Compiler for years (and contributed too!).

It is really a fantastic tool (along with the Closure Library and other members of the Closure family) for anyone that values maintainable, solid JS.

I can understand why it's not more popular; it feels a lot like Java -- industrial strength, non-flashy, and perhaps a little boring. It's also a little hard to setup for a real project (tutorials could be better).

It has been around since the creation of Gmail, and will be around to stay for years to come. (Though it has improved substantially over the years.)

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

#76

Post by eschutte2 »

Shebanator wrote: post #27
eschutte2 wrote: post #23

Earlier quoted context omitted.

I wish there were a better way to indicate which properties were renameable, because I need this too and I'm not willing to go as far as you did.

there is a much better way to deal with this: https://developers.google.com/closure/compiler/docs/api-tuto...

Thanks - I remember seeing that when looking through the docs, but I don't really like that either, unfortunately. I'm using Uglify right now, and I was thinking of adding a pre-minify step that walks the AST for a JSDoc-style annotation on either the properties themselves or a containing object, and pulls out the list of property names to preserve that way.

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

#77

Post by hellofunk »

abritinthebay wrote: post #49
hellofunk wrote: post #44

Earlier quoted context omitted.

There is definitely something amiss with your setup if you had a Closure compile take ten minutes. That is absolutely not the norm. On an old laptop processing thousands of lines of JS, I've never had it take more than a minute.

I'm not saying our code base is particularly small or well suited for CC, just that in my case it was pretty poorly performing.

After seeing you have millions of lines of code, now I understand how 10 minutes could be possible. You should have led with that :)
Post reply on HN