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 typically develop code in uncompiled mode
Well we did that too, but when we had to bundle everything and compile.. it sucked. We managed to get it down to about ~3 minutes with less advanced options but at that point Uglify was on par with it size-wise so... shrugs
We took development time over a minor (basically insignificant) startup latency improvement.
> on a large codebase [..] the type checking provided by Closure is invaluable.
I don't disagree with this but I find it best to separate the two out (for example, with something like Flow, etc) rather than have the whole bundle/compile step fail. But it's a good feature.
> Closure provided a good module system for JS for far longer than any alternative
True, but if you're using ES6 you get a better one now so I can't really say this is a plus anymore. If anything it's bloat now.
> The way your message goes over the top reminds me of a frequent irritation I have with part of the JS community, I guess I'd call it the "tools derangement syndrome". People who chafe at any structure imposed, be it optional types, syntactic-sugar Classes in ES6, IDEs, build processes, dismissing the benefits, or overplaying the downsides.
That's not what I'm doing. I'm saying in my experience and on our codebase it's not been worth using. I'm sure it will be for many people but I can't recommended right now. That's a personal perspective sure; never claimed it wasn't.
Ironically I'd say you're doing the exact thing you're arguing against - getting massively riled up over criticism of your favorite tool chain.
> That's fine if you don't have a lot of code,
Yeah, I do. A lot. Like... a lot. Like... over 3,600,000 LOC. It's just it's clearly not the kind of code and/or project that CC is fast at optimizing right now. That's on the project: it's very legacy and bloated tbh. I'm working to fix that as we speak ;)
> Closure compiler is extremely practically useful.
For projects that it's useful for, yes. It's a tautology. However for my project: wasn't at all. For projects that really just want minification and obfuscation: it's also total overkill.
I'm not saying its bad, GOD NO! Not at all, just that it was - for the large codebase we have - really not the best choice. That may change as our project gets cleaner, better organized, and less legacy. Right now though we're not there.
I'm not attacking that CC exists, I was providing an alternative perspective from the love-fest in here: where I've found it lacking. Blind devotion isn't good for any project. It's a good project but it doesn't help everyone.
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.
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).
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.
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 typically develop code in uncompiled mode
Well we did that too, but when we had to bundle everything and compile.. it sucked. We managed to get it down to about ~3 minutes with less advanced options but at that point Uglify was on par with it size-wise so... shrugs
We took development time over a minor (basically insignificant) startup latency improvement.
> on a large codebase [..] the type checking provided by Closure is invaluable.
I don't disagree with this but I find it best to separate the two out (for example, with something like Flow, etc) rather than have the whole bundle/compile step fail. But it's a good feature.
> Closure provided a good module system for JS for far longer than any alternative
True, but if you're using ES6 you get a better one now so I can't really say this is a plus anymore. If anything it's bloat now.
> The way your message goes over the top reminds me of a frequent irritation I have with part of the JS community, I guess I'd call it the "tools derangement syndrome". People who chafe at any structure imposed, be it optional types, syntactic-sugar Classes in ES6, IDEs, build processes, dismissing the benefits, or overplaying the downsides.
That's not what I'm doing. I'm saying in my experience and on our codebase it's not been worth using. I'm sure it will be for many people but I can't recommended right now. That's a personal perspective sure; never claimed it wasn't.
Ironically I'd say you're doing the exact thing you're arguing against - getting massively riled up over criticism of your favorite tool chain.
> That's fine if you don't have a lot of code,
Yeah, I do. A lot. Like... a lot. Like... over 3,600,000 LOC. It's just it's clearly not the kind of code and/or project that CC is fast at optimizing right now. That's on the project: it's very legacy and bloated tbh. I'm working to fix that as we speak ;)
> Closure compiler is extremely practically useful.
For projects that it's useful for, yes. It's a tautology. However for my project: wasn't at all. For projects that really just want minification and obfuscation: it's also total overkill.
I'm not saying its bad, GOD NO! Not at all, just that it was - for the large codebase we have - really not the best choice. That may change as our project gets cleaner, better organized, and less legacy. Right now though we're not there.
I'm not attacking that CC exists, I was providing an alternative perspective from the love-fest in here: where I've found it lacking. Blind devotion isn't good for any project. It's a good project but it doesn't help everyone.