Login

Google’s Closure Compiler Service API: Additional Features

In this eighth and final part of a series that explains the various features of Google’s Closure Compiler Service API, you’ll learn about a few features that didn’t fit neatly into the discussions in the previous parts.

If you’re in search of a friendly guide that teaches you in a step-by-step fashion how to work with the most relevant features that comes included with Google’s Closure Compiler Service API using PHP, then look no further because you’ve come to the right place.

Welcome to the final installment of this article series. As the above title suggests, through its various parts, the series illustrates how to programmatically optimize custom JavaScript files via the new web service that the popular search company has released in the last few weeks.

In earlier articles in this series I went through the development of a respectable number of code samples, which hopefully provided you with the right tips to start consuming the Closure Compiler Service API from within your own PHP applications. In this case, I decided to create from scratch an object-oriented back end to interact with the API and pass different parameters to it; however, it’s possible to get the same results using a procedural approach or even a different programming language, as long as it’s capable of triggering and handling POST HTTP requests.

So far, I’ve covered distinct facets of the API, ranging from applying different levels of optimization to supplied JavaScript snippets, to returning compiled code in a range of formats (text/JavaScript, XML and JSON). In addition, I also discussed how to work with the API’s built-in debugger, which allowed you to send to the client the warnings and errors that might have been generated during the compiling process.

With all of these topics already discussed in depth, it might seem like there’s nothing left to talk about the Closure Compiler Service API. In reality, the API offers a few additional features that are worth looking at, since they’re quite useful when you need to apply a “printer-friendly” format to optimized JavaScript or to retrieve compiling statistics. So, in this final chapter of the series I’m going to show you how to use these miscellaneous features, thus concluding this educational series on Google’s Closure Compiler Service API.

Now, it’s time to learn a few more useful things about this web service. Let’s go!

If you’re anything like me, you’ll want to see how effective the Closure Compiler Service API actually is when it optimizes JavaScript snippets. Fortunately, the API provides a straightforward method to get this information via its “output_info” argument. What’s more, if the value “statistics” is assigned to the argument, the compiler will return to the client a summary that includes detailed data about the results of the compiling process.

The following example shows how to accomplish this task in a simple manner. Check it out:

As the above example depicts, simply passing the “statistics” argument to the API will cause the compiler to send information back to the client about the optimized JavaScript code, including its original and compressed sizes. This demonstrates that the API is not only capable of optimizing JavaScript snippets in a truly effective manner, but can be used for getting a full summary of the whole optimization process as well. That’s pretty helpful, indeed.

So far, so good. Now that I have explained how to instruct the compiler to return statistics about the compiled code, it’s time to explore a few extra features included with the API. Thus, in the following segment I’m going to show you how to pass an additional argument to the API called “formatting,” which can be used for serving compiled code in a printer-friendly format.

Now, to learn how to use this new argument, jump ahead and read the lines to come.

Aside from the four arguments that you learned in previous tutorials, the Closure Compiler Service API accepts a few optional ones, which can be used for performing some useful additional tasks. That’s exactly the case with the “formatting” parameter, which is used for applying a specified format to compiled JavaScript code.

To show you a bit more extensively how to use this argument, below there is an example that assigns the value “pretty_print” to it. This process adds line breaks to the optimized code before it is sent to the client. Here it is:

If you were looking for an approach that will let you format your compiled JavaScript snippets to be printed or to preserve their readability, the “formatting” argument is definitely the option you want. As the above example shows, once this argument has been passed to the API, the optimized code is returned to the client in a “printer-friendly” format.

I’d like to stress that the functionality of this argument isn’t limited to adding line breaks to supplied JavaScript. It’s possible to use it for including delimiting comments when compiling code fetched from multiple files. Therefore, in the final part of the tutorial I’m going to build another basic example, which will show how to include the mentioned delimiters in the JavaScript file used previously.

Go ahead and read the following section.

Building a final example: working with the “print_input_delimiter” option

As with other arguments of the API discussed in this series, it’s possible to assign different values to the “formatting” parameter discussed previously. You already saw how to generate readable compiled code via its “pretty_print” option, right? However, assigning the “print_input_delimiter” value to the argument will cause the compiler to include several delimiters in the code when it’s been gathered from multiple JavaScript files.

To understand the functionality of this option more clearly, I suggest you look at the following example. It adds a single delimiter to the compiled JavaScript code, since in this case it’s been retrieved from a unique source file:

As you can see from the previous snippet, the compiler has effectively added a comment with the string “// Input 0” at the beginning of the optimized code. This is due to a simple reason: only a single file has been passed to the API. However, if the output had been generated from several files, multiple comments would be added in the form of “// Input 0”, “// Input 1”, “// Input N”, which permits you to easily keep track of what portion of code belongs to a given file.

As I said before, the “formatting” argument is entirely optional and should be used only when it’s necessary to make the compiled code a bit more readable, either to be printed out or to meet other requirements.

And with this final example, we’ve come to the end of this tutorial. As always, feel free to tweak all of the code samples developed in this series. This process will let you arm yourself with more experience in using Google’s Closure Compiler Service API.

Final thoughts

Everything has an end, and this series certainly isn’t the exception. But hopefully, the experience has been instructive and perhaps even fun, as you learned through some approachable examples how to optimize your JavaScript files using the powerful compiling service just released by Google.

Even though the concept is obvious, it’s worth recalling here, at least for the sake of completeness: no matter how efficiently you compile, minify and compress your JavaScript snippets, if you don’t cache them properly once they have been dispatched to the browser, the optimization will be of minimal help at best. So, make sure to implement an efficient caching mechanism before you start thinking about what type of web service you’re going to use with your client-side scripting files.