Google: Introducing Closure Stylesheets(googlecode.blogspot.com)
googlecode.blogspot.com
Google: Introducing Closure Stylesheets
http://googlecode.blogspot.com/2011/11/introducing-closure-stylesheets.html
9 comments
Your questions aren't a response to reality. Google has these tools that they use internally. They can either work to release them publicly, or not. I'd prefer they do.
Well, to be fair to Google, this looks very similar to the CssResource mechanism that has been in GWT for a while now, with the addition of mixins. If this is an evolution of the GWT version it's likely to be fairly mature "out of the gate".
Why didn't Google decide to instead contribute to Less or Sass
I'll see you and raise: why didn't Less contribute to Sass? ;-)
I don't see either question as being a problem in real life. You're going to have to have the build tools installed for any substantial web project you work on, and it's going to be less, sass, uglifyjs, closure, yuicompressor, the one I use that you've never heard of, or something else. Exactly which tools used is not particularly important.
And if you look at the Closure Stylesheets docs, it takes about 10 seconds (literally) to get it, if you're already familiar with similar systems. And if you're not familiar with them, you're riding the learning curve no matter what system you choose.
Finally, as to the observation, the argument is extremely compelling if you are deciding which toolset to use on your new project. Should I use Closure + Sass? Or should I use Closure? What do Less and Sass bring to the table that Closure does not?
(I'm not badmouthing these fine projects, and would not fault people for using any of them.)
I'll see you and raise: why didn't Less contribute to Sass? ;-)
I don't see either question as being a problem in real life. You're going to have to have the build tools installed for any substantial web project you work on, and it's going to be less, sass, uglifyjs, closure, yuicompressor, the one I use that you've never heard of, or something else. Exactly which tools used is not particularly important.
And if you look at the Closure Stylesheets docs, it takes about 10 seconds (literally) to get it, if you're already familiar with similar systems. And if you're not familiar with them, you're riding the learning curve no matter what system you choose.
Finally, as to the observation, the argument is extremely compelling if you are deciding which toolset to use on your new project. Should I use Closure + Sass? Or should I use Closure? What do Less and Sass bring to the table that Closure does not?
(I'm not badmouthing these fine projects, and would not fault people for using any of them.)
> When there are two very established solutions in the market, Sass and Less, you need to point out why these two come up short and why you are coming out with something new. Simply stating "we have a Google version of the tools you already use with the same feature set" isn't a very compelling sales pitch.
You need to understand that when an announcement like this is made, the development behind it happened over the course of years.
It isn't as if a few days before the announcement blog post is linked on HN, somebody made the decision "we can use Less, or Sass, or write our own. Screw those guys, let's write our own and release it open source!"
You need to understand that when an announcement like this is made, the development behind it happened over the course of years.
It isn't as if a few days before the announcement blog post is linked on HN, somebody made the decision "we can use Less, or Sass, or write our own. Screw those guys, let's write our own and release it open source!"
Next question: Why now? If this was being worked on for several years, why wasn't it released much sooner?
I have nothing against projects coming from Google. I'm all in favor of it. However I think Google acts as a much better open-source citizen when it adopts a posture like it has with HTML5. With HTML5, Google got involved early and publicly and one of their employees works as a benevolent dictator, which in the case of HTML5 is Ian Hixie.
When a project is released from some company, with no real defined ownership in the form of one human being or a small team at that company, it is a far less compelling project to get involved with, and the likelihood of a community being formed around it is low.
I have nothing against projects coming from Google. I'm all in favor of it. However I think Google acts as a much better open-source citizen when it adopts a posture like it has with HTML5. With HTML5, Google got involved early and publicly and one of their employees works as a benevolent dictator, which in the case of HTML5 is Ian Hixie.
When a project is released from some company, with no real defined ownership in the form of one human being or a small team at that company, it is a far less compelling project to get involved with, and the likelihood of a community being formed around it is low.
> Why now? If this was being worked on for several years, why wasn't it released much sooner?
Actually, the relevant question is "why at all?"
Google, like most companies, has lots of unreleased internal tools that others would find useful/have built for themselves.
Actually, the relevant question is "why at all?"
Google, like most companies, has lots of unreleased internal tools that others would find useful/have built for themselves.
I agree, I feel like they did the same thing with Dart which, imo, addressed the same problems that Coffeescript has already addressed.
Dart doesn't add much in the way of syntactic-sugar which is the only problem addressed by CoffeeScript.
I'm glad they did - if for nothing else because I find the Coffeescript syntax obnoxious to the extreme.
Redundant functionality to JavaScript is redundant. That being said I'm all for designers having baby steps they can use to simulate some of the functionality of JavaScript. After all the days of the one line of JavaScript that does that cool effect are over now that you aren't cool if you don't use prototypes and 'modules.' JavaScript is getting to the point where if you don't use at least 3 libraries to make your onclick event handler you get publicly lambast.
Also who says you need to copy the color every time you use it?
This is how it works. If you have one important property that you want to change everywhere then you use the most specific target class necessary for each of those classes in a comma separated list attached to only that property then you can change them all later or add new classes to them.
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
Also if you want to simulate if / then statements then you write your most general classes first followed by your more specific classes. So:
.blue {color:blue;}
.blue.darker {color:rgb(4,4,179)};
It's even better than a conditional. It's a switch.
Also who says you need to copy the color every time you use it?
This is how it works. If you have one important property that you want to change everywhere then you use the most specific target class necessary for each of those classes in a comma separated list attached to only that property then you can change them all later or add new classes to them.
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
Also if you want to simulate if / then statements then you write your most general classes first followed by your more specific classes. So:
.blue {color:blue;}
.blue.darker {color:rgb(4,4,179)};
It's even better than a conditional. It's a switch.
That's not the case for variables. The case for variables is when you have a set palette for the site, and you want the border of some elements to match the background color of other elements to match the text color of still other elements. Or you want to set padding on a set of classes, but then want to set the width of your left column to be some chosen value minus the padding of the center column. Or you want to flip your layout in RTL languages so that everything is reversed.
CSS won't let you do any of this natively.
CSS won't let you do any of this natively.
I think it's fair to say that people at Google do actually know this is possible.
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
That's no better, because you have to duplicate your selectors. You end up with stuff like:
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
.yetSomeOther .moreSpecificTarget {border: pink solid 1px;}
.anotherClass, .yetSomeOther {margin: 5px;}
.yetSomeOther .moreSpecificTarget {margin: 1px;}
Basically if you follow this model you have to have a line for every single property you want to style. It's unmaintainable, and increases the size of your CSS files.
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
That's no better, because you have to duplicate your selectors. You end up with stuff like:
.class, .anotherClass, .yetSomeOther .moreSpecificTarget {color:blue;}
.yetSomeOther .moreSpecificTarget {border: pink solid 1px;}
.anotherClass, .yetSomeOther {margin: 5px;}
.yetSomeOther .moreSpecificTarget {margin: 1px;}
Basically if you follow this model you have to have a line for every single property you want to style. It's unmaintainable, and increases the size of your CSS files.
I started out with sass. Then I started using twitter bootstrap, which uses less, so I switched to less because the mixin syntax is nicer / simpler (easy to switch since moving in that direction is syntactically very similar). Looking at the closure syntax, it doesn't seem like much of an advantage over less. I think I'll stay where I'm at.
If you want to compare that Java-ish syntax to some of the super-slick stuff you can do in NodeJS check out http://www.jaxcore.com/jxss/ which is a JavaScript/CSS hybrid stylesheet format I came up with recently.
The "Not Invented Here"-Syndrom at Google is absolutely baffling.
I can't wait until they port the entire Closure suite to Go.
I can't wait until they port the entire Closure suite to Go.
To be fair, the Closure suite has been around internally since roughly 2006/2007, and before then was extracted from working code within GMail & Google Apps that dates back to around 2003 & 2004. (I remember running across some of Paul Buchheit's code in Closure Compiler.) Prototype was brand new back then, JQuery didn't exist, SASS was several years off in the future. It doesn't really count as "not invented here" if it was invented here, and just not made public until somebody else independently reinvented it.
It's somewhat unfortunate that there're such long lead times between invention & publication, but also somewhat expected for a for-profit entity where basically everyone who works on open-source does so in their 20% time. There's also a strong desire on the part of many teams working on eventually-open-sourceable code to have it running in at least one production server, stably, with widespread adoption, to work out the kinks. I've worked on two projects that eventually plan to be open-sourced (and initiated one), but the teams involved don't believe them stable enough to be opened up quite yet. (This despite one of them being in widespread use internally, and the other one running in production in both Google Search and Google Maps.)
It's somewhat unfortunate that there're such long lead times between invention & publication, but also somewhat expected for a for-profit entity where basically everyone who works on open-source does so in their 20% time. There's also a strong desire on the part of many teams working on eventually-open-sourceable code to have it running in at least one production server, stably, with widespread adoption, to work out the kinks. I've worked on two projects that eventually plan to be open-sourced (and initiated one), but the teams involved don't believe them stable enough to be opened up quite yet. (This despite one of them being in widespread use internally, and the other one running in production in both Google Search and Google Maps.)
To me that tells me that they don't understand central aspects of open source, and/or are worried about losing control.
When companies take this approach, it dramatically lessens the value of what they release. Case in point: Your description above. If this had been released around 2006, it could've had a dramatic impact. Now there are plenty of alternatives.
When companies take this approach, it dramatically lessens the value of what they release. Case in point: Your description above. If this had been released around 2006, it could've had a dramatic impact. Now there are plenty of alternatives.
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.
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.
You don't get competition without redundancy.
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.
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.
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.
For renaming css class names, you explicitly call them out by doing goog.getCssName('class-name') in js and {css class-name} in soy.
http://code.google.com/p/closure-stylesheets/#Renaming
http://code.google.com/p/closure-stylesheets/#Renaming
Ah, yet another CSS extension that adds variables and mixins. At some point, shouldn't some of these projects come together, and say "we ought to standardize this?" I realize that the CSS working group is against adding variables and mixins to the standard, but given that there are now at least three prominent (and incompatible) implementations (Less/Sass/Google Closure), it seems like it's time to fork the standard (like the WHATWG did), standardize something, and then see if you can roll that back up to the W3C (or ignore the W3C if you can't get them to accept it).
Unless it's the standards group that's going to standardize it (which like you say is unlikely), what exactly is the advantage of the projects getting together to "standardize"? It may seem good to the average end developer, simply because there's fewer deliberation to be made, but I suspect the "competition" is probably a net positive for everyone.
The way most of these things go is that over time, either one of the projects becomes the de facto "best one," and the other projects eventually fade away, or two or more projects make some significantly different choices and thus branch off in multiple directions, each with its own community of contributors and users.
The way most of these things go is that over time, either one of the projects becomes the de facto "best one," and the other projects eventually fade away, or two or more projects make some significantly different choices and thus branch off in multiple directions, each with its own community of contributors and users.
I think at this point we really don't need more of these CSS supersets but more comprehensive CSS frameworks like Compass and web framework integration with these CSS frameworks, i.e middlewares and asset management tools. I for once would love to see Compass ported to Less.
Well, yes, that's my point. We don't need more CSS supersets, we need fewer; one standard one, that is called "CSS" (or "CSS4" or whatever). That, then, can be the target for frameworks like Compass, instead of them targeting CSS 2.1/3 or targeting only a single CSS superset like Less, Sass, or now Closure.
Honest question: Why would I use this over Sass?
Closure stylesheets have one feature that no other framework has--minification.
If you view source on a lot of google sites you'll see that style class names are obfuscated.
The one caveat is that you need a sophisticated build system to pull this off (though it's easier if you use the other closure tools).
If you view source on a lot of google sites you'll see that style class names are obfuscated.
The one caveat is that you need a sophisticated build system to pull this off (though it's easier if you use the other closure tools).
I was going to argue that Compass has :compressed output, but halfway thru, I realized you're right.
However, the beauty of Compass is that it doesn't rely on being intrinsically tied to the HTML it affects, whereas Closure stylesheets do.
All things considered, I'll stick to Compass/SASS.
However, the beauty of Compass is that it doesn't rely on being intrinsically tied to the HTML it affects, whereas Closure stylesheets do.
All things considered, I'll stick to Compass/SASS.
I guess if you already used one or more of the Closure Tools, you might want to use Closure Stylesheets over Sass, even if Sass was slightly better.
damnit, google. no nested selectors?
on a platform without javascript and where you're unable to even multiple class elements (some eBook readers), this makes a lot of sense over LESS.
Question #2: Why did Google come out with their own solution that has matured in the vacuum instead of involving the community earlier on? This approach at best fails and at worst fragments the market further.
Observation #1: When there are two very established solutions in the market, Sass and Less, you need to point out why these two come up short and why you are coming out with something new. Simply stating "we have a Google version of the tools you already use with the same feature set" isn't a very compelling sales pitch.