At the beginning of 2006 Erik and I started a 20% project to write a JS library for Google. Today it is used by many projects within Google and was recently open sourced.
On its own, the Closure Library isn’t very compelling for the average web developer. The dynamic loading is intended for unit tests and development, and using it in production would cause users to download masses of unused code.
Luckily for us, the Closure Compiler was open sourced at the same time. The compiler knows about a lot of the idioms used in the Closure Library and does a really good job of removing dead code and optimizing what remains. The team also launched a web service with a RESTful API so you don’t even have to run the compiler yourself.
Even with the web service, the development-debug cycle isn’t ideal. So when I found myself wanting to use some of the Closure Library for my new photo site I hacked together a PHP class that provides a convenient interface to the compiler web service, caches the optimized code, and recompiles when the sources have changed. Pretty basic, but quite useful I think.
I know PHP is looked down upon by many programmers, but it is easy, convenient, and widely available. If you have a PHP based site and want to use the Closure Library and/or the Compiler, it might be worth heading over to the project page and seeing if it might be useful.
PHP is fine. Sometimes a good selection is not about the superiority of language features and other minutia but the "momentum"… e.g. how appropriate it is within team members. For example, if someone asks if Python vs. RoR is better, then you can go down the list of pros and cons, but in the end it's so similar in both ends that a good choice is simply the one that your team has most mastery with. It is for the reason of momentum, that jQuery is kicking ass even though Google Closure is pretty darn nice to use. Sometimes good enough, is good enough.
I see great values with the Closure Compiler and Closure Library, but I have a hard time finding a compelling reason to use the Closure Template system (soy). Can you explain why soy is even released with Closure?
This comment was originally posted on Google Buzz.
jQuery is great, but they're not directly comparable. They fit different roles. Also, I believe jQuery is using the Closure Compiler now.
Regarding Soy, there are several reasons for templating in large web apps:
- It can be more efficient than sending all the HTML from the server.
- HTML building and innerHTML is much faster than DOM building.
- Templates are much easier to maintain than HTML strings embedded in the code.
This comment was originally posted on Google Buzz.
I'm all for templates and I agree with all of the points, esp the 2nd and 3rd one.
Please correct me if I'm wrong but my initial 5 minute trial with soy tutorial was that everything in soy required dom building.
This comment was originally posted on Google Buzz.
Well, if you're rendering a template after page load you need a node to render it in, but that could be as simple as:
document.getElementById('canvas').innerHTML = mysite.templates.photoPage(photos);
Or you could create a menu something like this:
var menuEl = document.createElement('div');
menuEl.innerHTML = mysite.templates.menu(items);
document.body.appendChild(menuEl);
You could also use soy.renderAsFragment:
document.body.appendChild(soy.renderAsFragment(mysite.templates.menu, items));
This comment was originally posted on Google Buzz.
Ah, thanks for the clarification. I didn't look into the implementation of soy and erroneously assumed everything was dom manipulation (since it required a root node).
This comment was originally posted on Google Buzz.
@Tim Finley Tim, you might be interested in this?
This comment was originally posted on Google Buzz.
Very Useful!
I’m thinking of developing a Django/Python based auto-compiling for Soy Templates to JS – its really painful when I make a few UI changes to test in a browser and have to run a batch script that compiles all .soy files.
Yeah, that would be very useful as well.
i’ve a totally different view on php: “its a really powerful language for quick web dev”
is there a possibility that we’ll be seeing a “code_url” option in this php code, since the closure compiler seems to have a higher file size tolerance when files are sent to it via code_url.
I think there are also some php warning given out on some of the variables that are evaluated in the switch case scenarios. I’ve added this in my own code just to initialize those variables.
$code
= $errors
= $warnings
= $code
= $originalSize
= $originalGzipSize
= $compressedSize
= $compressedGzipSize
= $compressedGzipSize
= $compileTime
= $node = null;
I just realized my code had duplicates.
@mo : I don’t run with E_NOTICE so probably missed them, it seems overly persnickety. I’ll try and clean them up.
Yeah : )
Btw hacking in the code_url option was pretty easy, I’m trying to make a more standardized way of implementing it using your structure now. My Javascript file was just over the 195.3Kb limit so I needed to have that option.
@mo : Try checking out the latest version and let me know if it still has problems for you.
And mo, if you want to send a patch for the code_url support I’ll happily take a look.
The patch for code_url isn’t really pretty but sure I’ll send it your way. I’m kind of stuck at the recompile check, it seems to always recompile my code for me. I’m trying to see whats causing it and I’ll get back to you afterwards : )
seems that the recompile only messes up on my local server, it seems to work fine online.
it was the filemtime($_SERVER["SCRIPT_FILENAME"]) check, since i had included the script and as you warned above the code it would cause the script to repeatedly recompile since my original php file was under heavy editing.
I’ve send over the code_url addition as soon as I can. : )
@Dan, I’ve sent you my altered code : )