CopperLicht 1.3.0 released and why Google Closure sucks

Posted on:October 29 2010


I just released the JavaScript WebGL Library CopperLicht in version 1.3.0. It includes several new features and major changes, for example enhanced shader support (callbacks for shader variables), better debugging support, possibility to clone 3D meshes. But the major change is that the whole library is now included in it's own namespace, CL3D, which makes it easier to use it together with other libraries, for example jQuery.

In previous versions, CopperLicht was optimized and minificated using the Google Closure Compiler, shortening lots of function and variable names, and cluttering random new variables all over the global namespace. Since the Closure compiler is quite popular, other libraries usually do the same, and when two such libraries get included together in one website, the generated new global variable names usually collide. Which basically sucks. There are (painful) workarounds for this, but honestly, they were a pain in the ass.

Additionally, once I put CopperLicht into it's new namespace, the closure compiler totally stopped behaving: It would put out invalid warnings and strip out symbols. Especially after updating to the latest compiler versions: Instead of improving the compiler, the developers obviously decided to include lots and lots of random warnings into it. (Come on, you want to force your coding style on me? No thanks. I think I know where I want to use the 'this' keyword and where not myself.) Reading the user forums and documentation, it seems Google Closure now is not intended anymore to be used by library developers (if it was ever, but it worked before for me). It is only useful in this case: Write an application, include all your libraries, and run the compiler over all code together to produce the end result. This works perfectly with Google closure, and produces excellent results.

Of course this isn't nice for my use case. So I tried out the alternative, Yahoo's YUI compressor. And interestingly, this is exactly what I needed: The compressor simply renames local names to produce a javascript code wich still does exactly the same, without any side effects. Perfect for developing a library. Nicely, ycompressor also does this quite fast, since it doesn't really analyze any code in depth for this.

So summarized: I probably should have named this blog post "[...] and why Google Closure sucks for libraries" instead, because it still is a useful tool. There are a lot of Closure vs. YCompressor comparison articles on the web, probably they also should note that those two can be used for totally different areas as well.





Comments:


Somehow gives the impression you try unscrew with a hammer and complain that it doesn't work alright, because you always break the screw...
xaos
Quote
2010-10-29 10:41:00


hm... how does a javascript compressor know what variables/methods should be renamed and what variables/methods should be left alone because they are part of an api?
horace
Quote
2010-10-29 14:25:00


It probably only renames the local variables.
niko
Quote
2010-10-30 13:39:00


CL3D['function_name'] = function () {
...
}

Strings never get shortened.
Stani
Quote
2010-11-23 19:01:00


This got lost, first define:

var CL3D = window['CL3D'] = {}
Stani
Quote
2010-11-23 19:03:00


Add comment:


Posted by:


Enter the missing letter in: "Inte?national"


Text:

 

  

Possible Codes


Feature Code
Link [url] www.example.com [/url]
Bold [b]bold text[/b]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]

Emoticons