Closure Stylesheets are good but not great.

Closure Stylesheets are a good effort from Google. Unfortunately, they released after Less, SCSS and SASS (see discusson on HN). In defense of that argument, I would say that the tool has been in use for a while, it was only the public release (and the process that it entails) what took longer than these other solutions.

But that's not actually what I'm rabbling about today. I won't get into the details of what syntax or implementation is better either.

They miss the point

Development tools are very helpful, but they also stint the ability to learn how to use a language more efficiently. Of course, what matters is to get things done, but in the long run it will make a big difference to those who put the work (or were inspired) to do it better.

For example: using variables in CSS makes sense when you think about re-using colors here and there. Could this be better addressed by using a separate stylesheet that deals with colors (and non-layout modifying rulesets)?

The point is that the inconsistency of content format makes a developer (or is it the other way around?) write a ton of rules to undo all the badly-inherited ones. The complexity of the current codebase makes it near impossible to even figure out what is reusable and how to use it —and frankly, most often things are not designed with reusability in mind: shocking, right?

So the problem about reducing code size is not about how big your code is. As we move into the future, the target market will increasingly be represented by higher bandwidth consumers, since those are the ones with the money to spend. —I understand there is a long tail and it is irrelevant here. As devices download faster and richer media is served, your CSS, HTML and JS will be puny compared to the number of images and HD videos that you're serving. Ever-increasing compression, bandwidth and client-side storage and caching will increase this trend, no matter at what rate. Given enough time, code size will be irrelevant.

What does matter is how maintainable your code is. Code size does become increasingly important but because there will be exponentially more time invested in fixing bugs and building new features as a direct result of the lines of code and people involved.

Another example: What about calculated dimensions? Isn't it a pain to keep track of what the paddings and width add up to?

You are missing the point

The future is bringing a diversity of devices: apps on phones, tablets, laptops, desktops and TVs. The more anyone is developing a pixel-perfect layout, the more it will look stupid on all other devices but yours. Adaptive layout requires thinking about how the content will flow and accommodate the available screen size and pixel density. Pixel-perfect layouts are perfect for making your work look like that spiffy mock, but it won't look so great on most devices by the end of next year, if not sooner.

This jewel from 2006, Switchy McLayout on ALA, explained it well a long, long, long, internet time ago (seriously, look at an internet meme timeline. That was the same year as ICHC!). But the point is not to talk about how great adaptive layout is.

The point

Tools that make you lazy are bad for you, but not as bad if you truly suck. Take the time to love and learn your trade or step aside.

Still here?

I'm glad. Let's build a better web. Check out these resources

• Transmedia Design for the 3 Screens (Nielsen)
• Chrome/mobile share on the rise