I was under the impression that the primary reasons one would use the Closure Compiler is for:
1) Catching errors in your javascript code.
2) Mangling your code to protect your intellectual property.
3) Removing unused code from your download.
For item 1, we have switched to TypeScript and do not benefit from the closure compiler. But if we were writing in ES5, I could certainly see the benefit.
For Item 2, if you don't mind if all your exported functions and properties are not mangled when even used between libraries (i.e. not from a web page), UglifyJS does a fine job in my limited testing. If you want those exported functions and properites mangled also so that only functions and properties expected to be accessed from a web page (extern) are unmangled, then I am under the impression that UglifyJS does not handle this case. But I may not have looked close enough because Item 3 is the deal breaker for me unless I am missing something.
I have only performed limited tests with UglifyJS and may just lack the knowledge of how to use the tool effectively. But after reading https://github.com/mishoo/UglifyJS2/issues/743 , the following is the conclusion I came to. Is my conclusion incorrect?
For Item 3, I don't understand how your test did anything with testing code removal, which is the main reason I would be using this tool. Presumably you have left the libraries in tact and not removed any "new" unused code other than what UglifyJS and Closure Compiler can remove in the simplest cases (i.e. unreachable code). It is my intent to create my own libraries and use third party libraries and on any given project, have the tooling figure out what it can remove with the minimal amount of guidance from me. Some annotating of my source code and adding a few special function calls to allow this seems like time spent well to remove substantial parts of libraries for a deployment. In other words, I want to have a function I call in some applications and not in others and I want my tooling to remove the function when it is not required.
I am trying to get back into Javascript and my last production applications were pre node js, modules, minification, .... So I may be coming from a completely ignorant position. Any assistance you can provide so that I understand what I am missing either from your article or in my assumptions would be appreciated.
I am currently reevaluating our tooling. Our current tooling is:
1) TypeScript with internal modules (namespaces)
2) Some home grown merging, extern generation, and fixing files to preserve maps
3) Running the closure compiler in production.
I am evaluating something like:
1) TypeScript (external modules)
2) JSPM Dev
3) JSPM Bundle / UglifyJS?
4) Possibly using Closure Advanced on the final bundle (not there yet and don't know if it is even possible.)
I do not doubt that Closure Compiler has some better features when it comes to dropping things that aren't used. It just takes an age longer if that's not a key priority.
Note that in the issue you linked, the guy completely misunderstood how global scope works in JavaScript. I don't know why they don't just close the issue. UglifyJS can remove unused functions. As long has they're not defined on a global scope level.
Hmm... I wonder if that option was or wasn't used in this blog post.
Comment
Perhaps I am missing the point.
I was under the impression that the primary reasons one would use the Closure Compiler is for:
1) Catching errors in your javascript code.
2) Mangling your code to protect your intellectual property.
3) Removing unused code from your download.
For item 1, we have switched to TypeScript and do not benefit from the closure compiler. But if we were writing in ES5, I could certainly see the benefit.
For Item 2, if you don't mind if all your exported functions and properties are not mangled when even used between libraries (i.e. not from a web page), UglifyJS does a fine job in my limited testing. If you want those exported functions and properites mangled also so that only functions and properties expected to be accessed from a web page (extern) are unmangled, then I am under the impression that UglifyJS does not handle this case. But I may not have looked close enough because Item 3 is the deal breaker for me unless I am missing something.
I have only performed limited tests with UglifyJS and may just lack the knowledge of how to use the tool effectively. But after reading https://github.com/mishoo/UglifyJS2/issues/743 , the following is the conclusion I came to. Is my conclusion incorrect?
For Item 3, I don't understand how your test did anything with testing code removal, which is the main reason I would be using this tool. Presumably you have left the libraries in tact and not removed any "new" unused code other than what UglifyJS and Closure Compiler can remove in the simplest cases (i.e. unreachable code). It is my intent to create my own libraries and use third party libraries and on any given project, have the tooling figure out what it can remove with the minimal amount of guidance from me. Some annotating of my source code and adding a few special function calls to allow this seems like time spent well to remove substantial parts of libraries for a deployment. In other words, I want to have a function I call in some applications and not in others and I want my tooling to remove the function when it is not required.
I am trying to get back into Javascript and my last production applications were pre node js, modules, minification, .... So I may be coming from a completely ignorant position. Any assistance you can provide so that I understand what I am missing either from your article or in my assumptions would be appreciated.
I am currently reevaluating our tooling. Our current tooling is:
1) TypeScript with internal modules (namespaces)
2) Some home grown merging, extern generation, and fixing files to preserve maps
3) Running the closure compiler in production.
I am evaluating something like:
1) TypeScript (external modules)
2) JSPM Dev
3) JSPM Bundle / UglifyJS?
4) Possibly using Closure Advanced on the final bundle (not there yet and don't know if it is even possible.)
Replies
I do not doubt that Closure Compiler has some better features when it comes to dropping things that aren't used. It just takes an age longer if that's not a key priority.
Note that in the issue you linked, the guy completely misunderstood how global scope works in JavaScript. I don't know why they don't just close the issue. UglifyJS can remove unused functions. As long has they're not defined on a global scope level.
Hmm... I wonder if that option was or wasn't used in this blog post.