Closure Compiler for OpenLayers 3.x
The most important tool in the Closure set is the Compiler. All other tools are optional and are build around the features of the compiler. The compiler is usable from command line or as a web application. You can also HTTP POST your source code and get back the compiled code. The compiler can be utilized by the existing building scripts of OpenLayers easily.
- Documentation of the code with JSDoc Tags is important: the compiler reads it and you get warnings during compilation for typos in documentation, wrong use of a @constructor, wrong type of a variable, misuse of a field annotated with @private and @protected, etc.
- The end applications can be compiled together with the library - and then the unused parts of the library are removed from the produced code. Dependencies are solved automatically by the compiler.
- Compiler accepts constants to remove unwanted functionality - this allows compilation only for particular browser such as Mobile WebKit, for only one of Quirks mode or Strict mode, compilation without support of IE6, etc.
- Debugging with FireBug is possible even for the compiled version of the source code.
- Compiler supports generation of dynamically loadable modules, which can significantly speed up loading of the end application, because the code for advanced functionality can be loaded only when it is required.
Let’s go through these points one by one:
2. Documentation of the code with JSDoc Tags is important: the compiler reads it
The JSDoc set of annotations and type expressions which Google Closure compiler understands is described at http://code.google.com/closure/compiler/docs/js-for-compiler.html.
The introduced type system is powerful. OpenLayers can profit from possibility to define your own object types, for example the “OpenLayers.Location” object can be a new type which always must contain “.x” and “.y” with type float. Compiler can enforce this: whenever a function expects “OpenLayers.Location” as a parameter you receive warning during compilation if you use an object which does not comply.
3. Public API is formalized - the compiler needs it
4. The end applications can be compiled together with the library
The end-user applications can be programmed traditionally: So the OpenLayers library is used as a standalone OpenLayers.js script, which is included in the website in the HTML header. The application itself has a separate code base, and uses the public OpenLayers API. This approach is common with OpenLayers 2.x.
5. Constants defined during compilation to remove unwanted functionality
Variables annotated with the @define JSDoc tag can be redefined during compilation, and then the compiler can recognize blocks of code conditioned with such variables as unreachable. Because the dead code is removed automatically - such source code is completely stripped from the final result .js file.
Typical use case for this is a block of code executed only if some DEBUG variable is set to true, but there are also other use cases:
Similarly - if you are developing a mobile web application for iPhone or Android platform, you don’t really need in your application code which is specific for Internet Explorer or for older versions of Firefox or other browsers.
I saw at FOSS4G that for OpenLayers 3.x is planned closer interoperability with existing general libraries such as Prototype, jQuery or Closure Library for accessing DOM, operation on strings or other basic functionality - to not reinvent wheel inside of OpenLayers and eliminate duplicate code for the same functionality in final applications, which are already using one of these libraries anyway. The conditional compilation with constants supported by the Closure compiler can help in this case.
6. Debugging with FireBug
Closure Compiler comes with two handy approaches for debugging the code compiled in the ADVANCED_OPTIMIZATION mode:
First is the parameter “–debug=true”, which causes that the renamed variables which are normally shortened to one or two letters keep meaningful names - e.g. “OpenLayers.Location.prototype.setValue” becomes , instead of “aa” for example. This parameter is very often used with “–formatting=PRETTY_PRINT”.
The second option is usage of the final compiled code together with the Inspector extension for Firefox. Compiler then generate a mapping file between original source code and the compiled code and the extension simplifies debugging with Firebug, once such mapping file is loaded.
7. Dynamically loadable modules
Google Maps API V3 as well as other Google products are compiled to load only a small core (bootstrap) of the necessary functionality and later load extensions with more code. This approach can significantly speed up the first appearance of a web application, which is important especially on mobile devices.
The Closure compiler of course supports this form of compilation, with parameters on the command line.
The whole project can be compiled with a simple Makefile or custom merge and build scripts, but there are also several tools available for simplifying the compilation, module dependencies and handling of the code which is spread over several files - these tools are useful especially if you are using Closure Library or you need compilation into modules: Plovr, ClosureBuilder, or Closure Modules. With Closure library comes also closurebuilder.py and depswriter.py.
I am very keen to discuss with OpenLayers developers and the community the application of Closure compiler and it’s advantages and disadvantages.
We have used the compiler and Closure library already at some projects which are now in production use, so we have practical experience with these tools - for example from the development of the web interface for our MapRank Search product.
If there is an interest I can publish another blog post with a code of a simple project and step-by-step guide demonstrating the use of Closure Compiler and Library.
The Closure tools are definitively worth attention for any web developer. Please write into the comments what do you think about the subject of Closure Compiler and OpenLayers V3.
Author | Petr Pridal Published | 2010-12-02