3 ms·

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/intr

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.

abritinthebay 11y ago
> 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.
fixermark 11y ago
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).
- cromwellian 11y ago
  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.

abritinthebay 11y ago

> 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.

fixermark 11y ago

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).

cromwellian 11y ago
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.