Those who don’t see any use for pre-processors such as Sass often use the “bad code” argumentation. It creates too specific selectors due to nesting, huge sprites and they hate the way Sass enforces an architectural approach that doesn’t work. And it’s all true. If you’re a poor developer. You know, one who would handcraft too specific selectors, 15MB sprites and doesn’t know how to cleanly structure a project.
Articles on Sass and Compass
Our Articles editorial section is where we will post more subjective, opinionated content. Expect us to ruffle feathers, state opinions, “rebound” someone else’s blog post, and everything in between.
If you have questions or suggestions, please contact us to let us know!
The rise in popularity of CSS extensions, such as Sass, in recent years has not gone unnoticed by the people who work on proposing and standardizing modules for CSS3 (and CSS4).
What is it about Sass that turns me into a fanatic? How is Sass like your favorite TV show? And why am I often alone at parties?
Since the creation of Sass, it has been plagued by many levels of controversy. It billed itself as “a better CSS” and added brand new features unheard of to CSS authors such as variables, nesting and mixins. Sass also introduced an entirely different indentation-oriented syntax and a brand new perspective on how to author CSS. Then the SCSS syntax (Sassy CSS) was introduced …
In a recent tweet exchange with fellow Sass-lover Nathan Smith, he had said “SCSS was my ‘gateway drug.’ I now prefer Sass to SCSS. Less typing, stricter indentation.”