I’m about to embark on a quest to understand the development for custom google-closure components (UI widgets if you will). Reading through the relevant section in “Closure – The Definitive Guide” makes me believe, it’s not all too difficult. But there are still a bunch of concepts which I need to familiarize myself with. This article briefly outlines my aim for this “learning trail”, and starts of with a tiny HelloWorld project using plovr. This article assume a minimal knowledge of google closure (you should know what “provides” and “requires”. “exportSymbol” should also not surprise you) Read the rest of this entry »
While cleaning up my build process using ‘closure’, I stumbled across plovr. After using it for only 20 minutes, I am convinced that this should be in the toolbox of *everyone* developing with the closure library!
While the documentation is still a bit sparse, you can have it set up in no time! There’s no need to regurgitate a basic setup example in this post. Everything necessary is readily availble over at http://plovr.com/!
If I had known about closure before, I would have used it instead of jQuery, because it makes it easier to structure the source code.
This made me more that curious. So the next thing I did, was read the closure tutorials, and also read the API top to bottom. I wanted to know what was in there before deeming it useful. And boy did it look interesting! The most interesting feature, as the author of said blog post pointed out, it the ability to easily structure your code. Using goog.provides and goog.require you can very easily split your JS files into multiple, well structured files, and the closure compiler will then re-combine them into one file, all properly ordered. To me, this feels a lot like writing Java or Python, which both allow you to structure your code very well. This also allows you to easily write modules which can in turn be re-used with ease in other projects (or, you could publish them).
For now, I am not missing anything from jQuery except the easy DOM querying from it. But I can happily live without it.
With my current experience, I can see the following benefits:
- Makes it easy to structure code
- The optional linter forces you to write proper/clean code. Especially with the --strict flag. Using it right from the start forces you to write in a uniform coding style, which makes code more readable!
- The compiler solves dependency chains with the help of goog.provide and goog.require, and can optionally minify your code.
- The library feels very professional. It’s even got a Logger loosely inspired by java.util.logger, and let’s you do exactly what you expect it to! This is awesome for debugging!
- The library source code is very readable
And some disadvantages:
- The community is much smaller than the one around jQuery. But so far I could figure out all I needed by reading the code.
- It does not seem to have versioned downloads. You have to checkout from SVN trunk. I would prefer to be able to say: “I am basing my work on version 1.0″ instead of “trunk”
- Instead of linking one CSS file (as in jQuery), you have to link multiple styles and figure out which ones by yourself. But given the filenames are self-explanatory, that’s not too difficult.
- There are no predefined CSS themes. Something jQuery’s theme builder would be nice. But, I assume that the closure-style-sheet project should help writing CSS files easily. I did not yet look into that one!
As I progress with the library I’ll post my findings…
Here are two related links I found while looking for the mentioned blog post: