3 ms·

I work on Gmail/Inbox and not even our codebase takes 10 minutes. Closure Compiler does not need to be constantly run in optimized mode during development. Type

I work on Gmail/Inbox and not even our codebase takes 10 minutes. Closure Compiler does not need to be constantly run in optimized mode during development. Type-checking only mode is faster, and engineers at Google typically develop code in uncompiled mode, and let the continuous integrations server run the fully optimized build + integration tests. Secondly, this isn't about strictly speeding up runtime performance, but startup latency. The biggest use of Javascript compilers is shrinking download size. The effects of even a 10% code size reduction are readily apparent in 95%tile latency graphs. On mobile web, it's even more of a benefit. Third, on a large codebase, like Gmail, Docs, Maps, etc the type checking provided by Closure is invaluable. Forth, Closure provided a good module system for JS for far longer than any alternative, and like GWT, it's over 10 years old. That module system allows for cross-module code motion optimizations, that make it easy to structure your code for maximum readability and productivity, but to ship it down the wire in a way that only the code that is needed immediately is retained, and "dead code" is moved into late loaded modules. Have a look at https://photos.google.com/ https://photos.google.com/ Most of the files loaded are tiny. Why? They're globally optimized, uglified, and dead-stripped together, but code is moved around between fragments depending on when, not if, the code is needed. Soap Box Time: 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 fine if you don't have a lot of code, but if you have a big enough project that Closure would take a long time to optimize, you are exactly the kind of scale of project that needs a type checking globally optimizing compiler. Closure compiler is extremely practically useful. Without it, Gmail, Maps, Docs, et al would be far larger applications that consume more resources. It's simply the best Javascript optimizer on the market by far.

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

abritinthebay 11y ago

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

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