In the following section I will show an example of how the Closure compiler may rewrite the original application for better performance.
Let’s take a look at a very simple greeting application consisting of the following three files:
The application is simple enough, but it consists of several layers and objects. A standard bundler would go through and combine all three files into one file and minify the symbols, but not much more.
Now, let’s take a look at the Closure compiled output below:
The most interesting part is the array of greetings. The original code created greetings via a greeting service and a greeting object model, but in the optimized code, all this code is collapsed into a simple array. Basically the Closure compiler analyzed the application and determined that the output will always result in a simple array of strings. This is a perfect example of the types of optimizations the Closure compiler may make to your application.
Closure compiler optimizations are impressive, but this comes at a cost. Since the optimizations are so aggressive, there is a always the chance that you may end up with a broken application if you're not careful. The biggest challenges are usually with third party dependencies that were written without the Closure compiler in mind. However there are techniques (e.g. externs) that can be used to protect incompatible code from dangerous optimizations.
Colsure compiler integration with Bazel is supported through the rules in rules_closure.
I have added this sample to Github in case you are interested in trying it out yourself. In addition to the Closure application there is also a Node api in there to serve the application.