This is like releasing an incompetable jQuery competitor just because it's been used internally for years.
This just creates more legacy code in a world full of legacy code. (By legacy I mean code that will stick around for a long time.) It doesn't really matter that Google has been developing this for years.
It would have been nicer and smarter of them to adopt Sass or Less (or at least the syntax), thereby eliminating yet another source of redundancy. It looks like it would be easy to do an automated translation of Closure CSS to either Sass or Less.
Competition on merit isn't even a question here, imho. Closure does less than Sass at the expense of a less elegant syntax.
The world of IT is full of these sorts of redundant projects. Competition is good, redundancy is not. In situations like these, people need to do is reach consensus on standardizing on one great tool, or at least compatibility.
Anyway, if I were founding a startup today, I would use the Closure suite over Sass/JQuery/random templating engine/etc. Despite having worked quite extensively with JQuery & random templating engines before Google (I even wrote a JQuery plugin that's in use at a dozen or so different companies, judging from the support emails I get), and still using them occasionally to prototype with at Google. Why? Because it's an integrated set of web tools that's better than the competition, because:
1. There's still no alternative to Closure Compiler. It type-checks your JavaScript, checks your dependencies, globally renames properties and variables, strips whitespace, replaces expensive constructs with shorter ones, and does this all basically transparently.
2. There's no alternative to Closure Templates if you want to fill templates on both the client and server sides (alas, if only the server side weren't Java-only). This opens up a lot of possibilities for rich AJAX apps, having an efficient JS templating language.
3. It can globally optimize your CSS classes across JS/HTML/CSS, something that no individual library could ever accomplish. Sass will minify your CSS, removing whitespace. Closure Stylesheets will minify your CSS, and then rename all your CSS classes to the shortest possible identifier.
4. All of this is easily debuggable, with development mode flags to give you the original names, so that you can use meaningful names in your source code and get fast output code that doesn't make your users wait.
5. Closure Templates are trivially internationalizable, and it's not hard to extract all text in them for translation.
6. Closure Stylesheets can Bidi-flip the entire page for RTL languages, so that when you want to launch in Arabic, you don't need to worry about changing all your Sass rules to include a $left variable that's 'left' in LTR languages and 'right' in RTL ones.
7. Closure Library has a wide array of UI widgets, including some pretty esoteric ones.
I'd argue about Closure doing less than Sass. It does less syntactically. But that's not the point; syntax is rarely the bottleneck when programming. Closure lets you completely avoid thinking about several things that are a pain in the ass to get right if you have to do them manually. Like making your JS tight and optimized so your site doesn't take forever to load. Or internationalizing - heaven forbid your users want to use a language other than English to read your site. Or creating separate debug & release versions of your code so you can understand what's going on and still release something lean & mean. Having worked in another corner of Google where many of these things are still handled manually, I guarantee you that you'll lose more productivity on them than on not having nested selectors.
Interesting points. I would never use Closure because of many of the stated points, since I would never want to risk being stuck with such a monolithic set of tools. Same reason I don't want to touch GWT with a barge pole. Sass and Less, on the other hand, are particularly elegant because their stated scope is very small.
There's still no alternative to Closure Compiler.
Mozilla Rhino and the YUI JavaScript compressor both do the same thing (AST parsing, analysis and rewriting) and have existed for a longer time. We used Rhino exclusively for several years until Closure came along. Closure produces a little more compressed code, but Rhino had fewer bugs for a while.
There's no alternative to Closure Templates if you want to fill templates on both the client and server sides
I believe there are several templating solutions that allow the same templates to be run server- and client-side. Mostly based on Node, if I remember correctly.
It can globally optimize your CSS classes across JS/HTML/CSS
That's interesting and useful. How does it correctly identify JS code that uses CSS classes? Does it look for $() and .addClass() and so on? Sounds potentially brittle. Does it work with, say, Rails or Sinatra apps?
Closure Templates are trivially internationalizable
I18n is a solved problem outside templates, surely. Eg., look at Rails i18n.
This just creates more legacy code in a world full of legacy code. (By legacy I mean code that will stick around for a long time.) It doesn't really matter that Google has been developing this for years.
It would have been nicer and smarter of them to adopt Sass or Less (or at least the syntax), thereby eliminating yet another source of redundancy. It looks like it would be easy to do an automated translation of Closure CSS to either Sass or Less.
Competition on merit isn't even a question here, imho. Closure does less than Sass at the expense of a less elegant syntax.
The world of IT is full of these sorts of redundant projects. Competition is good, redundancy is not. In situations like these, people need to do is reach consensus on standardizing on one great tool, or at least compatibility.