I too come from a background of "before CSS" and hand-coding HTML. But I differ completely as to why we should use SASS/Less.
So addressing her misgivings in order:
1. Code bloat happens—whether hand-crafted or automatic bloat. A good designer will always fight bloat, and a preprocessor helps reduce bloat. Mixins can introduce bloat, and decrease bloat.
2. Clients should never edit the CSS. We've had folks claim that if we'd come up with the design, or even the template, and they'd use it. More often than not, they can't. They just don't know how to do it. The designs they want are just to complicated for them to edit the CSS to them.
3. Preprocessors do not introduce logic into the CSS, they introduce logic in how the CSS is created. By and large a normal site does not need any if/else/for-loop logic to the stylesheet.
The problems that inspired jQuery, SASS, Less are all based upon inconsistent implementations. If the browsers would all just play along and implement all the standards we'd just be okay, right? But obviously you need compatibility layers to handle all the inconsistencies... and so you get frameworks, preprocessors, etc.
The tone of the article made it seem that the author is resistant to this added complexity, and is blaming the tools that have been developed for managing it.
I guess the mixins and nesting are nice, but who the hell wants to compile their CSS before it goes live. Good font end devs know how to organize their own stylesheets and reduce duplication. Some things don't need the engineering/CS treatment. Some times it's ok to have to declare #fff more than once...
When using a preprocessor you don't have to minify your source for production. You can compile it minified with all @import rules processed. Some preprocessors contain helpers for CSS spriting, some let you directly inline the image in a data-uri.
A good tool like SASS/Less is not something to sneeze at without researching fully.
No, I don't mean minify--I mean the SASS has to be run through a preprocessor before you have usable CSS. If I write the CSS, I instantly have usable CSS. I like using minimal tools for web design--browser and text editor. I don't want things I have to compile before I can see them in the browser.
I also think the mixins and nesting are overstated in terms of increasing the efficiency of designing sites with CSS. I am not typically declaring colors 20 times, or doing nesting so deep that it becomes confusing.
The benefits don't outweigh downsides of dealing with SASS files and preprocessors.
May I enquire, have you used one? Your comments, and those within the article, suggest that you haven't and the writer of the article hasn't.
I run the Sass binary, it watches my files, when I save something it runs them through the preprocessor, sees if there are changes and then outputs CSS to a destination I specified (the public folder of the application, obviously). This takes less than a second, so by the time I've switched to the browser and pressed refresh and it's there, styling a web page.
I write in SCSS, which is a superset of CSS, so I can actually write the Sass file in CSS, have it preprocessed and minified automatically.
In other words, I put in one command to start the SASS binary running, and that's all the extra work right there. So you see, when people talk about extra work, compilation time, waiting around for things etc, they sound like they don't know what they're talking about.
Then if you take into account the time saved from all the functions you now have access to, the stuff that will work the same across several browsers, the grids, the sprite stuff, the typography helpers... (the list goes on and on) it can only save you time.
I hire designers for jobs and after the mess the last one made through only knowing CSS I've decided I won't hire one who doesn't know SASS. It wastes my time and everyone else's on projects now.
>I guess the mixins and nesting are nice, but who the hell wants to compile their CSS before it goes live.
Everybody. We no longer FTP the CSS into the production server like it's 1998. We also minify (a pre-processing step) and concatenate (a pre-processing step). LESS/SASS is just another preprocessing step.
>Some times it's ok to have to declare #fff more than once...
Yes, if you are working on some small / toy site. Being able to have logical names for colors and change them all at once is very valuable for anything larger.
7 comments
[ 2.6 ms ] story [ 14.1 ms ] threadSo addressing her misgivings in order:
1. Code bloat happens—whether hand-crafted or automatic bloat. A good designer will always fight bloat, and a preprocessor helps reduce bloat. Mixins can introduce bloat, and decrease bloat.
2. Clients should never edit the CSS. We've had folks claim that if we'd come up with the design, or even the template, and they'd use it. More often than not, they can't. They just don't know how to do it. The designs they want are just to complicated for them to edit the CSS to them.
3. Preprocessors do not introduce logic into the CSS, they introduce logic in how the CSS is created. By and large a normal site does not need any if/else/for-loop logic to the stylesheet.
The problems that inspired jQuery, SASS, Less are all based upon inconsistent implementations. If the browsers would all just play along and implement all the standards we'd just be okay, right? But obviously you need compatibility layers to handle all the inconsistencies... and so you get frameworks, preprocessors, etc.
The tone of the article made it seem that the author is resistant to this added complexity, and is blaming the tools that have been developed for managing it.
A good tool like SASS/Less is not something to sneeze at without researching fully.
I also think the mixins and nesting are overstated in terms of increasing the efficiency of designing sites with CSS. I am not typically declaring colors 20 times, or doing nesting so deep that it becomes confusing.
The benefits don't outweigh downsides of dealing with SASS files and preprocessors.
I run the Sass binary, it watches my files, when I save something it runs them through the preprocessor, sees if there are changes and then outputs CSS to a destination I specified (the public folder of the application, obviously). This takes less than a second, so by the time I've switched to the browser and pressed refresh and it's there, styling a web page.
I write in SCSS, which is a superset of CSS, so I can actually write the Sass file in CSS, have it preprocessed and minified automatically.
In other words, I put in one command to start the SASS binary running, and that's all the extra work right there. So you see, when people talk about extra work, compilation time, waiting around for things etc, they sound like they don't know what they're talking about.
Then if you take into account the time saved from all the functions you now have access to, the stuff that will work the same across several browsers, the grids, the sprite stuff, the typography helpers... (the list goes on and on) it can only save you time.
I hire designers for jobs and after the mess the last one made through only knowing CSS I've decided I won't hire one who doesn't know SASS. It wastes my time and everyone else's on projects now.
Everybody. We no longer FTP the CSS into the production server like it's 1998. We also minify (a pre-processing step) and concatenate (a pre-processing step). LESS/SASS is just another preprocessing step.
>Some times it's ok to have to declare #fff more than once...
Yes, if you are working on some small / toy site. Being able to have logical names for colors and change them all at once is very valuable for anything larger.