Project shift evaluation (Target: Closure library)

I have given another though on closure library + compiler + templates.

I have downloaded the source, the compiler and template utilities. The source is really well documented.

Unfortunately I have issues with the fact that the compiler understands only certain subset of the JavaScript language, which means that I as developer need to restrain my work to those limitations for the only purpose to be able to compile the code to a usable size once development is completed.

I have tried to compile some of code as it is - it mostly did not work:

if (!window.console.group) {...}

resulted in:

if (!window.console.a){..} 

which is actually pointless. To avoid this I have to write:

if(!window.console['group']){..}

which is then compiler to

if(!window.console.group){...}

I find this exercise to be tedious for the developer; if a statement is valid JavaScript compilation should NOT break it.

I likes the name spaces idea nice, however the module pattern is equally nice to me.

Now about the templates. Our design guys make the prototypes in plain html. It seem fairly easy for a developer to translate this in closure template. However the fact that I need to use it with closure compiler throws it under the bus. Indeed the generated JavaScript is fast and compact, but fast and compact javascript is generate for jade templates also (and probably other templates for the node platform, those can be 'browserified'. The overhead of translating the HTML markup to Jade markup is not that bug as the Jade is fairly simple.

As of the compilation always valid code with minification is produced by uglify.

I was hoping for some more advances when dealing with UI, for example loading the css, the template and the logic of widget on demand. Nothing like that, at least not at first glance was found in Closure.  Seems we will continue handling the css manually and loading the modules with our JavaScript module implementation.

Before anyone gets this personally and start explaining the numerous advantages of Closure, let me tell you, I even went as far as reading "Closure: The definitive guide". I did not found the answer to our problem there. So it might be the greatest of them all, it still relies on coding style, which we do not have and there is no currently plan to port 100000 lines of code to another coding style so that closure compiler can handle it. Maybe one day when it can handle any code we will move on.

Conclusion: The main motivation behind this attempt with closure was the fact it makes maintainability much simpler. For example if we rely on Google to update the core and keep the API, we can assure the longevity of our code.Our code base grew enormous for the last year and we want to support only that, forgetting about browser inconsistencies, we would want to NOT back-port new versions of libraries, we do not like libraries that alter/augment native and host objects and we want either the namespace pattern or the module pattern. We want to be able to minify. Still we have not found all those in one project.

Our current approach is:

• requirejs for module loading
• jade for templating
• css for styling - no processing
• simple build process that minifies all scripts and then runs the requirejs optimizer. We minify all scripts because most of them are dynamically loaded and the optimizer cannot see them. 
• documentation is built by an in-house developed script reading the source (comment based as with YUIdoc, however much simpler).
• development environments are created with scripts that produces the base of the library, the project structures and a test server with local and remote debug server that compiles the templates on the fly.
• deployment is created with script and is complemented by a build from the development 
• versioning is done with git flow