Introduction to google-closure with plovr

September 1st, 2013 by exhuma.twn

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 »

Posted in JavaScript | No Comments »

More convenient development with the closure library

August 23rd, 2012 by exhuma.twn

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/!

Posted in Coding Voodoo, JavaScript | No Comments »

First steps with the closure library

March 1st, 2012 by exhuma.twn

I recently switched work, and now after a lot of JavaEE development for the past 5 years, I am finally back home: Web-development. During my Java time, I did some small web bits here and there. Mainly to keep up with evolution, and followed the massive move towards more JavaScript heavy development. During my free time I took baby steps with a couple of JavaScript libraries, starting with Prototype, then script.aculo.us, MochiKit and MooTools to get some visual effects done. Without doubt, I preferred MochiKit because of it’s similarity to Python. I also dipped into Dojo because of it’s nice HTML Form widgets, fooled around with backbone.js. But eventually I ended up with jQuery, simply because it currently has the backing of The Community. All I’ve done in all of these libraries can only be summarized as “wetting my feet”. At some point I consumed all the Crockford material I could find, and boy was that eye-opening. I realized I was not aware of the most important aspects of JavaScript (especially: “Everything is global! Use Namespaces!”)!

The next thing that caught my eye, was CoffeeScript. It allowed me to write pythonesque code, and compile right down to proper JavaScript.

So what has this to do with the closure library? Well, recently (as stated above) I started web-development again. And some parts of the project made it obvious, that a good dash of JavaScript would help the project a lot. So I needed to take a decision on what library I would base my work on. My first reflex was jQuery. But out of sheer coincidence I stumbled across a blog post from someone discussing jQuery and closure. Unfortunately, I don’t have the link anymore :( The TL;DR of that blog post was however (paraphrasing):

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:

Posted in JavaScript | No Comments »

Pages

Recent Posts

Categories

Links


Archives

Meta