4 ms·

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 1

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're doing a ton of data processing on the client (WHY??) then I guess it might be useful... maybe. That said - I'm glad it exists. It's a technological benefit even if it's not practically that useful. Those who compare it to the C++ optimization flags are being hyperbolic however: C++ isn't a JIT compiled language so it's Apples to Oranges.

hellofunk 11y ago
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.
- abritinthebay 11y ago
  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.
  - hellofunk 11y ago
    After seeing you have millions of lines of code, now I understand how 10 minutes could be possible. You should have led with that :)
swannodette 11y ago
10 minutes? I'm sorry this is just FUD. I've seen very large ClojureScript projects that generate nearly 100,000 lines of JavaScript and even with advanced optimization (the slowest mode by far) I've never seen it take longer than a minute and a half. As far as Uglify compression performance, in my experience it consistently generates a final production file twice as large as Closure if you're following the Closure conventions. And Uglify doesn't do the fancier things like code splitting + code motion.
- abritinthebay 11y ago
  Not FUD - you just clearly don't have a large enough project. I'm dealing with a lot more JS than you. Like.. a LOT more. I wish I had only 100k lines. As for twice as large - never seen that. Uglify routinely gets to between 10-20% larger than advanced optimized CC in my experience. I mean if you're writing directly for CC you might get better but that's because a lot of that will directly make it harder for most other minifiers (go figure) Like I said tho CC is great, I'm glad it exists. It CERTAINLY does more than Uglify... I just don't see any practical benefit. It's an awesome technological achievement though.
  - cromwellian 11y ago
    100k lines? You think that's a large project? The closure library itself has 500kloc. 10-20% is a huge difference. On an 1M JS app, that would be an extra 100-200k of JS downloaded. That will seriously increase latency, especially for those in developing countries.
    - abritinthebay 11y ago
      No, I don't. That was my point. I wish I had only 100kloc to deal with. I have 3.6 million to deal with. Different scale entirely.
      - Kiro 11y ago
        May I ask what kind of project you work on?
        abritinthebay 11y ago
        A large media organization.
cromwellian 11y ago
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.
fixermark 11y ago
> If you're doing a ton of data processing on the client (WHY??)... ... because that's the future. https://cloud.google.com/solutions/angularjs-cloud-endpoints-recipe-for-building-modern-web-applications?hl=en https://cloud.google.com/solutions/angularjs-cloud-endpoints...
- abritinthebay 11y ago
  er... that's not in the client. That's in the cloud. ie - on servers. That's just a fancy way of distributing data across services. It's not client-side processing of the data: it's server side.
  - fixermark 11y ago
    Read it more closely; the document I linked is specifically about pushing functionality into the client. "MVC frameworks, such as AngularJS, have been developed that enable client-side developers to build powerful and compelling UIs." "This paper provides best practices and guidance to web developers who are interested in AngularJS or other client-side MVC technologies and want to optimize their server backend for these technologies." "The growing popularity of client-side MVC frameworks such as Backbone.js and AngularJS is representative of this shift to the client. These frameworks help reduce complexity and increase reuse in even the simplest of applications... As the UI moves to the client, the server becomes simpler."
    - abritinthebay 11y ago
      Yes, I'm quite aware of what Angular, Backbone, etc do. I'm also quite aware of what MVC is thankyouverymuch. But I was specifically referring to data processing on the client and while those frameworks obviously can do that the page you linked describes where they farm it out to other cloud services. This is obviously faster than doing it on the client.. and is exactly what I was talking about. The future you linked to is the exact opposite of doing data processing on the client. So why you'd call client-side data processing the future with that link as evidence I don't know. ... unless you don't actually understand what "client side" means I guess. Client Initiated Processing !== Clint Side Processing.
swannodette 11y ago
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 saying Closure is 60X slower and claiming compression performance I cannot even reproduce with a code base that's 40-50X smaller. What???
- abritinthebay 11y ago
  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.

hellofunk 11y ago

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.

abritinthebay 11y ago
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.
- hellofunk 11y ago
  After seeing you have millions of lines of code, now I understand how 10 minutes could be possible. You should have led with that :)

swannodette 11y ago

10 minutes? I'm sorry this is just FUD. I've seen very large ClojureScript projects that generate nearly 100,000 lines of JavaScript and even with advanced optimization (the slowest mode by far) I've never seen it take longer than a minute and a half. As far as Uglify compression performance, in my experience it consistently generates a final production file twice as large as Closure if you're following the Closure conventions. And Uglify doesn't do the fancier things like code splitting + code motion.

abritinthebay 11y ago
Not FUD - you just clearly don't have a large enough project. I'm dealing with a lot more JS than you. Like.. a LOT more. I wish I had only 100k lines. As for twice as large - never seen that. Uglify routinely gets to between 10-20% larger than advanced optimized CC in my experience. I mean if you're writing directly for CC you might get better but that's because a lot of that will directly make it harder for most other minifiers (go figure) Like I said tho CC is great, I'm glad it exists. It CERTAINLY does more than Uglify... I just don't see any practical benefit. It's an awesome technological achievement though.
- cromwellian 11y ago
  100k lines? You think that's a large project? The closure library itself has 500kloc. 10-20% is a huge difference. On an 1M JS app, that would be an extra 100-200k of JS downloaded. That will seriously increase latency, especially for those in developing countries.
  - abritinthebay 11y ago
    No, I don't. That was my point. I wish I had only 100kloc to deal with. I have 3.6 million to deal with. Different scale entirely.
    - Kiro 11y ago
      May I ask what kind of project you work on?
      - abritinthebay 11y ago
        A large media organization.

cromwellian 11y ago

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.

fixermark 11y ago

> If you're doing a ton of data processing on the client (WHY??)... ... because that's the future. https://cloud.google.com/solutions/angularjs-cloud-endpoints-recipe-for-building-modern-web-applications?hl=en https://cloud.google.com/solutions/angularjs-cloud-endpoints...

abritinthebay 11y ago
er... that's not in the client. That's in the cloud. ie - on servers. That's just a fancy way of distributing data across services. It's not client-side processing of the data: it's server side.
- fixermark 11y ago
  Read it more closely; the document I linked is specifically about pushing functionality into the client. "MVC frameworks, such as AngularJS, have been developed that enable client-side developers to build powerful and compelling UIs." "This paper provides best practices and guidance to web developers who are interested in AngularJS or other client-side MVC technologies and want to optimize their server backend for these technologies." "The growing popularity of client-side MVC frameworks such as Backbone.js and AngularJS is representative of this shift to the client. These frameworks help reduce complexity and increase reuse in even the simplest of applications... As the UI moves to the client, the server becomes simpler."
  - abritinthebay 11y ago
    Yes, I'm quite aware of what Angular, Backbone, etc do. I'm also quite aware of what MVC is thankyouverymuch. But I was specifically referring to data processing on the client and while those frameworks obviously can do that the page you linked describes where they farm it out to other cloud services. This is obviously faster than doing it on the client.. and is exactly what I was talking about. The future you linked to is the exact opposite of doing data processing on the client. So why you'd call client-side data processing the future with that link as evidence I don't know. ... unless you don't actually understand what "client side" means I guess. Client Initiated Processing !== Clint Side Processing.

swannodette 11y ago

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 saying Closure is 60X slower and claiming compression performance I cannot even reproduce with a code base that's 40-50X smaller. What???

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