2011.11.09

The problem with CSS pre-processors

This post is very polemic, I thought a lot before publishing it, please try to be open-minded and read the whole thing before commenting, it is not supposed to become a flame war. Please read the about page to understand the objective of this blog and the way I think about it.

I’ve been considering to use a CSS pre-processor like SASS, LESS, Stylus, etc, for a very long time. Every time someone asked me if I was using any of these tools/languages I would say that I’m kinda used to my current workflow and I don’t really see a reason for changing it since the problems those languages solves are not really the problems I’m having with CSS. Then yesterday I read two blog posts which made me reconsider my point of view so I decided to spend some time today studying the alternatives (once again) and porting some code to check the output and if the languages would really help to keep my code more organized/maintainable and/or if it would make the development process easier (also if they evolved on the past few years).

It takes a couple hours for an experienced developer to learn most of the features present on these languages (after you learn the first couple languages the next ones are way easier) but if you have no programming skills besides CSS/HTML and/or don’t know basic programming logic (loops, functions, scope) it will probably take a while, the command line is another barrier to CSS/HTML devs… But that isn’t the focus of this post, I’m going to talk specifically about overused/misused features. I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.

Mixins

What are mixins?

Mixin is a common name used to describe that an object should copy all the properties from another object. To sum up a mixin is nothing more than an advanced copy and paste. “All” the famous pre-processors have some kind of mixin.

Dumb code duplication is dumb

Following the SCSS syntax (sass), a mixin can be described and used as:

@mixin error {
    color: #f00;
    border: 2px solid #fc0;
}

.error-default {
    @include error;
}

.error-special {
    @include error;
    background-color: #fcc;
}

Which will compile to:

.error-default {
    color: #f00;
    border: 2px solid #fc0;
}

.error-special {
    color: #f00;
    border: 2px solid #fc0;
    background-color: #fcc;
}

Note that the properties are duplicated, which is very bad, file size will increase a lot and overall performance will also be degraded if not used with care. – Imagine that on a large project with thousands of lines of code, the amount of duplicated code will be unacceptable (by my standards).

This problem isn’t specific to SASS, it is also present on LESS and Stylus and any other language/pre-processor which supports the same feature, by having a new layer of abstraction the developer won’t realize he is creating code that has lots of duplication… ALWAYS gzip CSS and JS files!! gzip is really good at compressing duplicate data, so this problem might be irrelevant/nonexistent in production code, just beware that the generated CSS will get harder to maintain in case you or future devs for some reason decide to stop using a pre-processor and simply update the generated CSS (maybe they don’t have access to the source files or have no experience with a pre-processor).

Extend

LESS and Stylus doesn’t have support for anything similar to an extend, that’s why I picked SCSS (Sass) to write the code samples. A extend is like a “smarter mixin”, instead of copying and pasting the properties it will set the properties to multiple selectors at once.

.error {
    color: #f00;
    border: 2px solid #fc0;
}

.error-default {
    @extend error;
}

.error-special {
    @extend error;
    background-color: #fcc;
}

Which will compile to:

.error, .error-default, .error-special {
    color: #f00;
    border: 2px solid #fc0;
}

.error-special {
    background-color: #fcc;
}

Way closer to what a normal person would do manually… “Only” use mixins if you need to pass custom parameters. If you see yourself using the same mixin multiple times passing the same values than you should create a base “type” that is inherited by other selectors. - Compass (nice SASS framework) have a lot of mixins which I think should be base classes instead.

Extend isn’t enough

Note that extend avoids code duplication but it also causes other problems, the amount of selectors can become an issue, if you @extend the same base class multiple times you may end up with a rule that have thousands of selectors, which won’t be good for performance either and can even make the browser to crash.

Another issue is that every class you create to be used only by @extend is going to be included on the compiled file (even if not used) which can be an issue in some cases (name collisions, file size) and makes this process not viable for creating a framework like compass.

I really wish that SASS improves the way that @extend works (and that the other pre-processors also implements a similar feature) so we could create many base classes for code reuse but don’t necessarily export them. Something like:

@abstract error {
    color: #f00;
    border: 2px solid #fc0;
}

.error-default {
    @extend error;
}

.error-special {
    @extend error;
    background-color: #fcc;
}

Which would compile to:

.error-default, .error-special {
    color: #f00;
    border: 2px solid #fc0;
}

.error-special {
    background-color: #fcc;
}

PS: I know this kind of feature was already proposed before.

Another problem is if you mix nested selectors with @extends it might also cause undesired side-effects.

Extend and mixins can be bad for maintenance

Contrary to the common knowledge, extending other classes and creating mixins can degrade maintenance. Since the place where you are using the properties is far away from where the properties are being defined there is a bigger chance that you will change properties without noticing you are affecting multiple objects at once, or not realizing which elements are being affected by the changes. This is called “tight coupling”:

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

  • A change in one module usually forces a ripple effect of changes in other modules.
  • Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
  • A particular module might be harder to reuse and/or test because dependent modules must be included.

(source: Wikipedia)

I prefer to group all my selectors by proximity, that way I make sure that when someone update a selector/property they know exactly what is going to be affected by these changes, even if that imply some code duplication.

Avoid editing base classes as much as possible, follow the “open/closed principle” as much as you can. (Augment base classes, do not edit them).

Nesting

Another feature that a lot of people consider useful is selector nesting, so instead of repeating the selectors many times you simply nest the rules that should be applied to child elements.

#content {

    table.hl {
        margin: 2em 0;

        td.ln {
            text-align: right;
        }

    }

}

Compiles to:

#content table.hl {
    margin: 2em 0;
}

#content table.hl td.ln {
    text-align: right;
}

By abstracting the selectors it becomes very easy to be over specific and specificity is hard to handle and a bad thing for maintainability. I’ve been following the OOCSS approach and I don’t need child selectors that much so I don’t think that typing the same selector multiple times is a real problem (specially with good code completion), I know a lot of people don’t agree with that approach but for the kind of stuff I’m doing it’s been working pretty well.

Call me a weirdo but I also find nested code harder to read - since I’ve been coding non-nested CSS for more than 7 years.

Sum up

These tools have some cool features like the helper functions for color manipulation, variables, math helpers, logical operators, etc, but I honestly don’t think it would improve my workflow that much.

My feeling for these pre-processors is the same feeling I have for CoffeeScript, nice syntax and features but too much overhead for no “real” gain. Syntax isn’t the real problem in JavaScript for me the same way that it isn’t the real problem in CSS (and most of the languages). You still need to understand how the box-model works, specificity, cascading, selectors, floats, browser quirks, etc… you are just adding another layer of abstraction between you and the interpreted stylesheet, adding yet another barrier for future developers and increasing the chance of over-engineering. Markup may become simpler (with less classes/ids) but it comes with many drawbacks.

For me the greatest problem are developers that code CSS without the knowledge required to build a maintainable and scalable structure. A stylesheet full of mixins, if/else, loops, variables, functions, etc, will be as hard to maintain as a bloated hand-crafted stylesheet, if not harder. Developers have an inherited desire to be “clever” and that is usually a red flag.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” – Brian Kernighan

Mixins are popular nowadays because of browser vendor prefixes, the real problem isn’t that CSS doesn’t support mixins or variables natively but that we have to write an absurd amount of vendor prefixes for no real reason since most of the implementations are similar and most of the features are only “cosmetic”. The real issue isn’t the language syntax, but the way that browsers are adding new features and people using them before they are implemented broadly (without prefixes). – This could be handled by a pre-processor that only adds the vendor prefixes (without the need of mixins or a special language) like cssprefixer. Try to find what is the real problem you are trying to solve and think about different solutions.

“It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.” – Peter-Paul Koch

I’ve been following the OOCSS approach on most of my latest projects, and probably will keep doing it until I find a better approach. For the kind of stuff I’m coding it is more important to be able to code things fast and make updates during the development phase than to maintain/evolve the project over many months/years. I find it very unlikely to make drastic design changes without updating the markup, on the last 100 projects I coded it probably only happened 2 or 3 times. - css zen garden is a cool concept but not really that practical - Features like desaturate(@red, 10%) are cool but usually designers already provides me a color palette to be used on the whole site and I don’t duplicate the same value that much, if I do duplicate it everywhere than I can simply do a “find and replace” inside all the CSS files and call it a day, by using a function that generates a color (which you have no idea which value it will be) you can’t simply do a find and replace since you don’t know what is the value you are looking for on the source code - I prefer to simply use a color picker…

I know my experience is very different from most people so that’s why my approach is also different, your mileage may vary… If I ever need to use any of these tools it won’t be an issue (I have no strong barrier against them), I just don’t think they will save me that much time right now that would outweigh the drawbacks. Pick the tools based on the project and your workflow, it isn’t because I listed a couple issues that you should discard using a pre-processor, for many cases it would be an awesome way of generating stylesheets, just think about the drawbacks and be responsible.

“With great power comes great responsibility.” – Uncle Ben to Peter Parker

PS: I love CSS, for me it’s one of the most rewarding tasks on a website development, it’s like solving a hard puzzle…

Further Reading

Edit 2011/11/09: added link to “The law of leaky abstractions”, small tweaks to the copy and formatting.
Edit 2012/02/04: add link to “LESS Sass. More OOCSS.” to the further reading.
Edit 2012/07/06: added info about the open/closed principle.
Edit 2012/10/24: added info about undesired side-effects caused by @extend


Comments

Really good. Have been thinking the same for a while - since i switched back to css in the 3 later projects. I just cant agree with the latter topic - i find inline css really horrible to read.

But the fact is that CSS lacks the ability to declare variables (got used to dem colors like $blu and use functions like darken or lighten) and calculate random values you might want, i.e grid measurements and em %'s and dynamic base font sizes.

Hey This is a good summation of the dangers of using these preprocessors - the fact that they are easy to misuse. But I would argue that a professional CSS writer can avoid them quite easily. For example, on your mixin example - you don't need extend either - CSS is modular - you can simply append another class to the same element. It is also much more semantic. (eg:

<span class='error special'>

On the other hand, being able to wrap modules together in the same scope can help make the code much clearer, and the various cross-browser mixins not only save time but also make the code much more readable and easier to maintain since you write them all in one line instead of maintaining a full list of syntaxes (which can become a real nightmare in instances like gradients).

@arieh, that's exactly how I've writing my css, I add multiple classes to the same element instead of copying and pasting properties, it has many benefits. About the crossbrowser mixins we don't need a new language, just a compiler that adds the prefixes like css prefixer. Cheers.

Hey 1. This isn't just about prefixing - there are multiple syntaxes (shadows and gradients for eg) 2. I find an automated tool like compass to be much easier to use than going to an outside site. 3. On the issue of maintainability, using a tools like compass is much easier for the testing phase than a web tool, since you don't need to go back and forth.

These are obviously my opinions - I'm not trying to start a contest - my point was that it isn't about writing a new language. What I love about scss (not sass) is that it is just extended CSS. It offers me a very wide range of tools for me to pick. You can choose only to use the mixins and variables, or you can choose to use nestings. If you use compass, you don't even have to worry about compiling it, since it's done automatically. For me it added a lot more organazation and clarity to my code, w/o affecting my workflow.

But like any tool - it's very important to know how you can missuse it, and it is easy to forget that the end result does not look like what you wrote - so I would say that you should learn it's quirks just as you would any other.

@Arieh CSSPrefxer is a python tool, the site is just a convenience, just need to use a file watcher like watchdog and you will be able to run it at each file change... to be honest I never really used CSSPrefixer on a real project since my editor snippets and macros are enough to avoid typing all the prefixes (I use Vim with Snipmate and I created snippets for the most common prefixed properties) but maybe I will try it on a future project.

I totally understand that these languages can make the source code more succinct and that some of the helpers can be useful, that's one of the reasons why I considered using some of these tools - compass spritting utility is a killer feature, so much better than doing it manually or using other tools just for it - I just don't think it overcome the drawbacks...

We could avoid some of the issues if we want to, as you said, you can simply use it as if it was CSS with a couple extra features.. but since I think it may become harder for other devs (which may not have basic programming knowledge) and the benefits aren't that many, I think it is a better idea to avoid these languages altogether... - The post about CSS "variables" by Bert Bros gets into details about how new features can become a barrier to other devs.

Like @desandro said on twitter: "at the end of the day, it's a preference." - if you are working by yourself or with a team of developers that understands the technology and don't care about the drawbacks, than it's totally fine to use it... But since I'm working with multiple teams and sometimes I don't even know who are the people that are going to maintain or be part of the project I can't commit myself to this kind of tool.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - Martin Golding

Cheers.

I really enjoyed your article. Excellent overview of preprocessor features. I have often thought that tools are never a substitute for good architecture, but you said it better here.

Somewhat valid statements, as I dislike coffeescript as well :) however, CSS is a different beast. It's not like we're taking an imperative language and just changing the syntax, we're taking something 100% declarative and making it a bit more flexible with some scripting capabilities.

If CSS didn't involve all of the vendor issues that we have today I would completely agree, but it certainly does not stop at prefixes, and most people wont want to use something like prefix free on the client, just as they should not be using LESS on the client (in prod).

With Stylus I really enjoy the little things, for example the transparent mixins allow you to generate your own properties. Where I would normally write:

logo {

position: absolute; top: 5px; left: 5px; }

I can now just write:

logo {

absolute: top 5px left 5px; }

or:

logo {

absolute: top left; }

This really helps with abstracting away browser vendor garbage that the designer(s) would otherwise have to manage.

I find that for instance compass helps my workflow a lot, especially the functions/variables. Using pre-written code provided by compass, mixins or by extension also prevents me from accidentally introducing bugs. And the code stays DRY, is shorter, easier to read, easier to work with. I agree that stuff like CSS Zen garden is not exactly how I work, but having flexibile and readable code during the construction of a site helps the process along nicely.

For instance when working with a baseline grid, then using for instance rhythm(), leader() and trailer() to work in line-height units, is really sweet. If you want to change the typography and baseline grid, for instance in responsive designs, this is very useful. Writing values as a product of X and pi() or $golden_ratio just feels sweeter ;) SASS is also easy to configure to make it use a higher precision (more decimals), which is just… more precise :) And instead of using a calculator when calculating my ems or percentages, I just write the divisions in the CSS directly.

Another thing is file structure. Processors make it easy to maintain multiple files which divides the CSS into more edible chunks of code, while it can still combine them to one finished file so you don't do too many HTTP requests. It can also compress/minify on the fly, no extra tools needed. Also great for readability and especially nice when we're multiple people working on a project together.

@TJ : I agree partially with your comment about imperative/declarative, this kind of feature can be nice after you get used to it but there is an overhead of learning them and memorizing it. Stylus is a nice language and flexible but it also implies that the person who is going to maintain the project (even yourself few months latter) will need to remember the proper syntax and notice that some properties have different behavior from what you would expect, the feature is one of the greatest benefits and drawbacks at the same time (like many things in life). Since I'm already very familiar with CSS syntax and CSS is hardly 20% of the time I usually spend coding my projects I think that there is not that much gain in writing less code, I'd rather focus in making the other 80% more productive.

@Torkil : I've been splitting my source files into many CSS files and run the RequireJS optimizer to combine the CSS for deploy, it merges all the @import rules and compress the files. Tools indeed help you to DRY but they don't remove the need of a good architecture, the post was more a heads-up about possible pitfalls.

I'm not repeating myself that much even without variables, mixins and loops (multiple CSS classes on the same element helps that)... Cheers.

Like many frameworks/tools, with great power comes great responsibility :) It's up to the developer to know the tool well enough so that he knows what is good practice and what is not. Frameworks usually don't stop developers from writing poor code that will have a bad effect on, let's say, performance. In this case with CSS preprocessors, like you did during your experiment, it's important to look at the CSS output and to learn what each feature of the tool does. Great article!

I keep finding posts about why LESS, SASS, coffescript are sooo great. Hardly any showing the problems. Maybe I have seen too many Java programmer fail (not me, I keep clear of the mess) with their stacks on stacks. Like them all the preprocessors are just each a new level of possibly problems and bugs.

I need to admit I did write a kind of CSS preprocessor myself which has support for variables only but also does minifying. Even with this tiny subset of possibilities I noted the extra problems that can occur.

And the interesting point you made about the possible hugeness of the generated CSS reminded me of OM-mappers which seem a good idea but may lead to massive performance issues which seems like the programming equivalent...

thanks, finally I don't feel so lonely ;)

Thanks for the quick overview on CSS preprocessors. Reading your objective analysis from a code designer's perspective answered a few questions and saved me several hours of, in all likelihood, drawing similar conclusions as yourself. I find it easier to implement this sort of dynamic preprocessing if needed with a couple lines of server script than to ingest and differentiate between a whole new set of acronyms...

Since it's not mentioned here the CSS Crush project is based on a similar reaction I had.

No nested syntax or mixins. Aliases handle the vendor prefixes seamlessly.

Thanks for the article - I've recently been looking into SASS and have felt uneasy with the way it solves the problems I have with our current CS workflow. This article nicely articulates some of those problems, you saved me many hours!

I think if you find yourself requiring a CSS preprocessor you're probably better off refactoring/rewriting your CSS instead.

It is annoying when you have to repeat yourself in CSS but if you use a system that handles duplication for you then you're more likely to make the situation worse.

As always, a 100% handcrafted solution is the best (but maybe not the quickest to produce).

@Matthew James Taylor "As always, a 100% handcrafted solution is the best (but maybe not the quickest to produce)."

If that were true then no-one would be using JS libraries. And no one wants to live in that hell.

@OP

Whilst I agree pre-processors aren't for everyone I feel like a lot of the flaws in this post can be avoided if you actually know what you're doing. Just as it's possible to write bad JavaScript with jQuery it's also easy to write bad CSS with something such as LESS.

You need to understand your tools and how they work, and use them correctly instead of blindly applying all the features it allows.

Personally I've found LESS to increase my efficiency and enjoyment of writing CSS in droves. But this is only from keeping a close eye on the final code it outputs and how the pre-processor actually works best.

Ultimately we don't need IDEs or JS libraries either but once you know how to use a tool properly it is indispensable.

I too have been crafting CSS for a very long time. Over the years you learn how to write concise CSS that inherits properly, as well as how to create base classes that are extended.

I work in an enterprise environment and many of the CSS pre-processors are outside of our stack. For our UI group I have been working with CSS pre-processors in an effort to evaluate their value. I can say that it's not looking good for the pre-processors. It creates another layer that just isn't justifying the addition of complexity to our CI system.

For now, we are sticking with handwritten CSS and JavaScript (not Coffee Script).

Great post, I had thought about blogging about my experiences, but you have already done an excellent job.

I'm with you all the way, especially with your comments about the current trend towards multiple abstraction layers.

There's a a couple of extra problems with CSS preprocessors - and indeed other abstraction layers such as HAML - you don't mention:

1) They produce a cognitive disconnect between what you have written and what you see in the web inspector, which slows down development.

2) Unportability. You can't simply drop the file into a little development stack and test it, because it requires compilation. It makes CSS harder to move between projects - and that's something I do all the time using the OOCSS method.

I was also dissapointed by the fact that LESS (which I have used) has no "smart shorthand" creation when it compiles. That and also the fact that using a JS on the site to compile "on the go" when you're working on a remote server. Actually I felt slower on developing the stylesheets then if I was using regular CSS.

As a tip, just remember to use. the JS in dev mode, so you wont be deling with awful browser cached stylesheets that wont ever refresh. That almost drove me to insanity.

In my case I try using sass whenever I can. I find it interesting because it saves some development time and also lets me build libraries of styles and use different files which are 'transformed' into one when processed.

I agree with some of the comments above,.

I thing preprocessors is a tool like any other and it depends on how it is used. The same generated code can be written by someone using plain css, but the improvement is in knowing how and when to use one of the preprocessors to achieve gains in coding speed.

It all depends on the skills and I think people should try to find the good things and use those and avoid the bad ones, but not quit using such or such tool just because in certain cases it generates non optimal code.

Besides, you the generated code with theses preprocessors is generally one to one with css so one can have quite a lot of control.

Pablo

Paul Steffens

I still haven't picked up preprocessors precisely because of the reasons you mention. However, lately I have been thinking they might be very usefull for generating a boilerplate for every new client. Change font, baseline grid whathaveyou for that new project, generate the css and work from there with your customized framework. I have to look in to this...

Another interesting use I don't know enough about is what the BBC seems to be doing with LESS and responsive design. I don't agree with their take on DRY; dev code is, but production code most certainly is not DRY and will impact performance. But it is an interesting use nonetheless (no pun intended :))

As with any language (or preprocessor), the more APIs you have available, the more potential for error, ambiguity and complexity. Your arguments are weak and focus on the misuse of the features rather than the features themselves.

Of course if you use @extend all over the place you are increasing redundancy. This is not any more wrong than copying and pasting CSS properties across element selectors. This is why classes exist in the first place.

The contents of a @mixin should only contain selectors that depend on the variables passed in. All other static properties should be in a separate class that is used for the elements the mixin applies to. This will ensure you are only "mixing-in" non-redundant code. Likewise if you are reusing a mixin with the same variables, create a single class for that case.

Regarding over nesting, this can be easily misused when writing vanilla CSS as well. The preprocessor nesting is merely syntactic sugar and is way faster to write for complicated page layouts. If a developer does not understand how CSS selector precedence works then they are in for a bag of hurt regardless if they are using a preprocessor.

I couldn't agree more, Miller.

I think the quotes (especially the debugging one) sum it up perfectly. The fact that developers are trying to be clever is actually going to hurt the industry as a whole.

The biggest issue, however, is that of working in teams. If you are a solo developer then I don't care how you write you CSS, but if you're part of my team and you hand me a SASS file instead of a regular CSS one it directly impacts my ability to make changes or debug.

People constantly stress how important it is to write semantic code, leave comments throughout your application and format code properly. CSS pre-precessors fight that ideology.

Lastly, find and replace can change all instances of a colours or fonts in seconds. Tried, tested and true.

Good post. The reason why I haven't used CSS Preprocessors on a real project is pretty simple. Some like SASS, some like LESS, some prefer CSS. It's hard to get everyone on the team to agree on something and be happy.

Thoughtful article, Miller.

CSS architecture is the most important part of building a stylesheet library for any web app or large website (80% of sites probably don't need too much thought put into CSS architecture — they just need to work (ducks)).

But I didn't care about CSS architecture until I started using SASS. Before SASS, I did a lot of work in a small amount of stylesheets, doing my best to make my structure obvious for anyone else who would come along and edit it. But thats nowhere near as good for maintainability as breaking up your stylesheets into multiple files. Then when it came time to go live, good front end dev practices says you should concatenate and minify those styles into one file. In my world, that was only possible sometimes — for many reasons — so when I knew I couldn't do it, I did my work in a few files.

But with SASS, I have total control on how my styles, which are now spread across dozens of files, can be concatenated on the fly. I can use dozens of files to organize my styles however I want and augment them with the features you mention in this post. Every time I save a file, SASS does the hard work of compressing it all up. I can also rearrange and organize my work as I go, breaking of chunks, optimizing for maintainability or whatever I feel is best to maintain good architecture, and SASS will instantly let me know whether what I just did worked or didn't (SASS, like most ruby-based apps, has very verbose errors).

I've been the solo stylesheet author for many projects, and I've gone from dreading maintaining a few stylesheets of 2-4k lines of CSS to enjoying maintaining dozens of stylesheets of hundreds of lines each, which compile into 10k lines of code.

SASS works for me. I encourage everyone who hasn't tried it to do one project with it, start to finish, and then you'll be able to make up your own mind.

Great post, and these are absolutely issues with CSS preprocessors. It is easy to write overly verbose code with preprocessors and CSS helps developers fine tune arguments to be as refined as possible.

That said, preprocessors are incredible for frameworking. I have been using Sass for about 1.5 years now and wouldn't be able to do the work I do with out it. My job requires me to rapidly prototype and develop advanced layouts and manipulating CSS is just too time consuming. I developed a framework for this code, Seasons, and it has a configuration file that does most of the heavy lifting for me.

You are correct, mixins should never be used without passing unique arguments through, but they can be useful when building grids. They can streamline code by containing chunks of a framework to be called upon as needed, reducing file size when a feature is not needed.

Custom functions are much more valuable as a tool and creating lean stylesheets. Complex arguments can be compiled down to a single value you can use anywhere. I use the modular scale function in every project to help me generate values and layouts. Instead of going outside of my stylesheets to do these complex calculations I can stay within my code and change things on the fly. Not only do these functions help in writing values, but they also help in converting units. I recently made the switch from a pixel based grid to one based on ems, this conversation was as simple as changing the base-size of my modular scales to 1em.

OOCSS has its problems, especially when moving towards responsive design and things become flexible. The need to write properties based on the semantic value of an HTML object become more important. For example, when using classes for layout, the OOCSS approach would be to create classes like 'width-3-cols' or 'col-3' but the grid is in flux in responsive designs. With a CSS preprocessor you can move the object to a function or mixin. Under different @media events the location on the grid can be calculated differently without layout classes in the HTML keeping things fixed.

These are some advanced techniques and my ways of solving some of the issues you outlined with precompilers. My opinion is that precompilers add a huge array of tools for CSS developers to take advantage of. They have their problems but when used correctly they have great advantages. That said, none of these tools (should) show up or matter to the end user, it is all about what you are comfortable with and if it is straight CSS then thats fine by me.

Thank for the article, I have been thinking about these same drawbacks. still not convinced about preprocessors and their usefulness.

I use LESS and I enjoy it very much. However I also take a look at the end result from time to time to make sure I understand how it's processing things. I usually like what I see, but it's also because I'm careful to only use LESS in a way that ultimately improves things. I only nest as deeply as I normally would without LESS, but LESS just makes my code shorter. I also like it because I can start with exactly CSS, and OCCASIONALLY sprinkle some things in, like a reused color, or maybe some math. These two things make my code 100% more readable and maintainable with 0 drawbacks.

Without LESS, I've found that one dev will write rules for an area of code, and another dev will fail to find that area when making other changes and put it in another area of code, which actually makes that whole problem of what you need to see being far away WORSE in normal css. I know this isn't always true, but for when it IS true for my project, LESS has made things better.

I think it's like any tool, ultimately it's still YOU using the tool, so be mindful of what you're doing and try to be mindful of what you're doing with it. I can write bad css, and I can also generate bad css with LESS. I try not to do either of those things. I think that all of the bad things this article has mentioned can be entirely avoided by just taking care with what you write. Don't go trigger happy with any fancy features just because they exist.

I totally understand the concerns you have with CSS Preprocessors. Using one requires some self control and experience. Just to put it out there, I'm a LESS user.

I like the fact that I can nest, use variables and include other stylesheets/less files without the extra HTTP request. Also, minification is super simple too with LESS.

I think that LESS really improves my organization with the use of namespaces and the way I structure my LESS files. You claim that single line is much easier to read for you, but I want to rip my hair out when I see single line CSS.

I think your article is a great summation of what some of the, maybe, unforeseen issues with using a CSS Preprocessor creates. In the end.....it's whatever the developer is more efficient using.

[...] The Problem With CSS Pre-Processors (millermedeiros.com) [...]

[...] mit sich. Und nur weil man einen Pre-Processor wie SASS verwendet, schreibt man nicht automatisch besseres CSS. Es muss schon ein gewisses Verständnis von CSS vorhanden sein, damit SASS, LESS, Stylus, Closure [...]

[...] from Instapaper: Master Research The problem with CSS pre-processors | Blog | Miller Medeiros [...]

The real problem is the traditional way of writing CSS is slow and hard to maintain. You've already tackled this problem by adopting OOCSS. I did a couple projects that way, and I agree, it's a very fast way to build a large product.

What I've found is LESS solves the problem in cases where you can't just put classes all over the place. For example, I work on a large Django environment that frequently shares templates between products, and uses Markdown all over - which generates classless HTML all over the place.

In that situation, you find yourself writing:

.somemodule {...} .somemodule p {...} .somemodule ul {...} .somemodule li {...} .somemodule a {...}

frequently. With that alone, smart use of nesting speeds up the process a lot.

Can you run your specificity through the roof? Well, yes, but you can do that without a preprocessor.

On the other hand, you're right: if you abuse this stuff, it'll screw you. Like anything else, you need to come up with and stick to a consistent set of best practices so you don't find yourself with performance or readability problems down the road.

I was never very impressed with the existing CSS preprocessors because of the friction involved, so I wrote my own called JXSS, it's kind of a hybrid of CSS and JavaScript. It has seamless integration into a new nodejs server framework, so no compilation stage is required, just write your code and reload:

http://www.jaxcore.com/jxss/

Excellent Article! I have been reading a lot about this Frameworks and I strangely couldn't find the: "yeah! This is amazing! Let's start using it now!". But a lot of people are all talking about it for being so great...That is when your article comes up giving me another point of view and I think it is great!

I agree completely with you!!

Thanks for sharing it! =) Regards,

For small projects I steer away from it. Great article and yeah, I also sort of agree with you.

[...] duplication and the performance hit associated with over-specific selectors[1]. Be sure to read the full article first, then come back if you [...]

[...] CSS pre-processors and why you need to be careful with them. [...]

I use Sass (SCSS) on all my projects and I completely agree with you.

This might have something to with the fact that I rarely use mixins or extends and almost never use nested selectors.

I do, however, use functions, variables and colour helpers (from Compass) and of course built in concatenation and compression, basically all the dynamic things that don't mean repetition just nice-to-haves. Otherwise I write exactly like I would CSS.

That's the nice thing about sass (et al.), you can pick and choose the features you use and it's possible to end up with something that gives you the best of both worlds, the simplicity of CSS and the convenience of preprocessors.

Great article, and very important issues to consider. I agree that compiled CSS can lead to performance and maintenance issues. Developers need to have a strong grasp of CSS and code patterns/architectures before trying to create patterns/architectures through a pre-processor framework. For large-scale projects I use OOCSS and a very light subset of SASS/SCSS's "CSS superset" to handle vendor prefixes, spriting, and variables for colors and font stacks.

I also agree that the CSS Zen Garden was an amazing exercise that really pushed standards, the web & web design forward, but the ideals break down quickly at larger scales.

[...] The problem with CSS pre-processors - I’ve been considering to use a CSS pre-processor like SASS, LESS, Stylus, etc, for a very long time. Every time someone asked me if I was using any of these tools/languages I would say that I’m kinda used to my current workflow and I don’t .. [...]

Shane Shelley

I agree that tools should not replace a solid (or at least honest effort at) understanding of best practices; but as with everything else I think there's a middle ground here.

For example, variables for color values, sizes and positioning, along with color helper formulas, positioning and sizing arithmetic are all quite useful and not at all difficult to debug later.

Mixins, extend, etc. are a black hole right now and should be used with great care. But if you know how to write solid, clean CSS right now there's nothing wrong with leveraging a few of the nice shortcuts that these frameworks provide.

This post really got me thinking. I've spent a lot of time over the last couple of days researching both sides of the argument. While I do think the points that you made are big problems that come from using pre-processors, I also think that they can be a really valuable tool if used properly.

From my experience, I think that is the main problem. A lot of people don't use them properly, and that leads to terrible stylesheets. It seems to me that the people who do the most damage with pre-processors are the same people who aren't that great at writing plain CSS. A friend of mine recently said "...people who suck in CSS suck even more in Sass" and I think he had a really good point.

Like you said, they key is using tools like Less and Sass responsibly, and I think that's where a lot of people go wrong. Personally, I've switched back from Less to pure CSS and I don't think my workflow has suffered in the least.

I think another huge factor in this is whether or not you're working with a team. The company that I work at has been growing steadily and we're starting to see how it could cause problems when one developer starts a site using Sass and then passes it off to another developer who may not be familiar with Sass or doesn't even realize that Sass was being used. It gets even worse once the site goes live. It becomes impossible to make quick CSS changes straight on a live site. Instead you need to make the change locally, compile it, and then deploy it to the live site.

Very nice article to address a problem that I recently realized...

After developing websites for the last 16 years, I have come to find the never-ending quest for shortcuts quite amusing because I almost always come to the same conclusion. The funny thing is that developers put so much time into researching software, scripts and tools (I'm as guilty as anyone) that we fail to realize that spending the same amount of time learning to do things correctly typically ends with a better result all the way around. Responsible development means more than how fast things can get coded. What ever happened to proudly claiming the use of Notepad to code sites???

Over the past 3 months, and after exhaustively testing many different coding methods/styles, I have come to conclusion that after a couple adjustments, I wasn't so far off to begin with. More than anything, I am a speed junkie. I truly believe that a slow loading page can kill itself no matter how on target the design is. Not too mention that have now been reinforced by Google's ranking adjustments.

To me, it's simple. My stylesheets now include "constants". I define color, borders, radiuses, backgrounds, etc. I usually try to address most of my vendor specific stuff in here too. If you think about it, you are only going to have several different styles of each (ie. background colors, borders, text colors, etc.). My HTML comes out looking like this:

<button class="small blue center radius">My Button!</button>

My button!

As you can see, defining a handful of constants in your style sheet upfront gives you the ability to add it into your HTML...no need for mixins at that point. This is faster, sementic, easier to maintain and most importantly, very lightweight code.

Funny thing about all of this is that I find my dev time cut in half (or better) now because I simply take my template and modify all of the constants (colors, typography, backgrounds, borders, etc.) Once I'm done I find I am writing 25% of the code I used to complete the site and I have never been to perfectly consistent without any effort.

One last note: I will say that about a year ago I switched from EditPlus, which I used for years, to Komodo IDE. I have to say that I love it for a number of reason but my favorite has to be that I save all of the code snippets that I frequently use and, with the technique above, I find myself writing less and less code all the time. Heck, I have now even started saving entire code blocks such as HTML5 and jQuery scripts in the code library, Once I slice a psd, I am no more than a good hour or two before I have my entire site framed up and I'm starting to add the custom elements.

[...] there’re some criticisms you can find on the web, but they’re getting better and reach much more developer every [...]

[...] and start talking about CSS Preprocessors, specifically SASS, LESS and Stylus, also we talk about this specific post about some issues people have with using CSS [...]

Anthony Delorie

You can still write bad code with a preprocessing same way you can still write bad code with jQuery.  You don't seem to grasp the power of mixins, vendor prefix for gradients is pretty lengthy and with mixins they can accept variables and you can assign variables a default. SASS also great for validating your CSS and utilizing say a grid system without tightly coupling your presentation and content. If you get into responsive design you'll see the power of a SASS. @joe the class names you assign to your button are basically assigned in your HTML not your CSS which makes it bad semantics. If you have 1000 pages that have a button with class blue that don't use a template that's a 1000 search and replaces you have to make on content files which violates the practice of separating content and presentation. Your methodology prevents a redesign with CSS only.

[...] turns out that not everybody likes CSS pre-processors. For some people, it’s a philosophical point (a bit like purist photographers who still insist on [...]

Joe Conlin

This is just inline styling defined some place else, it describes the styling but not the button purpose. It should be something like .btn-submit-mv, thereby style agnostic and to which you could apply any number of stylesheets without touching the markup, sigh:

My Button!

Interestingly I find this is an argument for a preprocessor, i.e. .btn-submit-mv { @import blue @import small @import center @radius }

Anyway, not here to highjack the article topic..

Great article, 14 years of CSS for big and small and I couldn't agree more. Search and Replace is your friend and generally is enough if your CSS is well written. Understanding context and keeping overrides to a minimum works for me in a team situation. We've dabbled with dynamic css over the years but in the end have always come back to pure CSS and S&R, it's simple, we all understand it and it works everywhere for everyone..

As for vendor prefixes, what a shame hey, not sure we should be creating tools to encourage more of them..

I only just started to "get" CSS. You know, that "ah!" moment. I'm autodidactic, and basically just kept messing around with CSS and HTML, with each in separate files (*.css in the /css folder and */index.html). Also, Javascript in a special /js folder. I haven't yet touched the javascript and jquery codes.

To cut a long story short, I can type at a fair rate in wpm I type, without too many mistakes (proof: http://i.imgur.com/mC9oC.png) :p

Nah, I can type between 40 and 75 wpm, with almost 100% accuracy. So, coding by hand is not really a problem for me... in fact the more I do it, the better I get at it. I don't like these SASSy, autocompleting things because I don't know what the computer did exactly; what algorithm was used to permutate. I don't want to know either - it's like typing English sentences out. I never use autocomplete, in fact it irritates me. The only exception is phones without T9 numeric keypads.

What is the likelihood of a preprocessor changing the CSS such that it will cause a varianced style output - even if near-negligible?

Have you ever considered about adding a little bit more than just your articles? I mean, what you say is valuable and all. Nevertheless just imagine if you added some great visuals or videos to give your posts more, "pop"! Your content is excellent but with pics and video clips, this site could definitely be one of the most beneficial in its niche. Terrific blog!

It's a bit odd to write to write an article about how CSS pre-processors don't bring any value, and then not mention the most valuable function in them—variables.

Being able to tie all of the site colours, for instance, to an @primary-color or @secondary-color variable is consistently useful—especially when implementing on a dynamic front-end framework. It's useful when a client rebrands but doesn't want a total redesign too—simply change @primary-color and @secondary-color and recompile!

c

Superb blog! Do you have any suggestions for aspiring writers?

I'm planning to start my own blog soon but I'm a little lost on everything. Would you recommend starting with a free platform like Wordpress or go for a paid option? There are so many options out there that I'm totally confused .. Any ideas? Thanks a lot!

[...] My biggest issue was that I wanted to ensure that the quality of my compiled CSS was not degraded by the misuse of @extends, @mixins, and nesting. [...]

Miller,

I'm totally agree with you. I use webkit (chrome) to create/edit my styles or sometimes use dreamweaver to see all the changes in real-time. But if you use these compilers, you will have no chance of look-and-feel.

This is also an obstacle if you interested in responsive design. You have to compile css and reload the page each time which is waste of time.

Another thing is css3 properties are being changed day by day so vendor prefixes will be removed in the beginning of 2014. This means any of sass, less generated code will be waste of space since we won't longer need these prefixes.

I have doubts about learning any of these pre-processors so after that, I decided not to prefer to use. Thanks.

I was ready to tear this article apart, but I read it, and I can't disagree with you. I just recently had a nightmare situation with the nesting in an scss file where it was difficult to identify which of all the closing brackets was closing what.

As Arieh said:

"Hey This is a good summation of the dangers of using these preprocessors - the fact that they are easy to misuse. But I would argue that a professional CSS writer can avoid them quite easily."

It's just a matter of using it, learning how it behaves and adapting your workflow to it. It becomes a very powerfull tool. i switched 2 years ago and pure css makes me nervous now.

Extend is a very powerfull feature and it helps a lot improve maintenance in my experience, once you (and the working team, if applies) find when to use and the best way to use it, in each case.

Nesting stuff too deep is a very common problem, but easy to overcome. We learned to get over that when we were CSS intermediates afraid that one class properties would interfere on another (and used to create 8 levels CSS rules).

Mixins are misunderstood. It's misuse is much like that "font-size-16", "font-bold", "color-red" classes that bad CSS frameworks and CSS starters use to "enhance code reuse". Well, stuffing your HTML with classes is a way more serious problem than stuffing CSS. CSS was borne to take the "stuffing" part, to make HTML be the purest and reclaim it's original objective, wich is MARKUP. Yet, mixins can me very powerfull when combined with variables.

Another great point on using pre-processors is the possibility of using CSS partials, wich is great for maintenance, reading, organization, blabla.

I don't know exactaly what kind of sites you guys work on, but for large sites css and html pre-processors are really helpfull, epecially if you work on ruby enviroments. One of the sites i work on has arround 800k users a day. HAML and SCSS improved its front end performance a lot, made maintenance easier, and the creation of new features and pages much faster.

I guess it's worth varies from case to case.

I have not read past mixins, but I have to say you got the wrong idea. You're taking a feature and completely misusing it. You took a mixin and decided it's there to replace CSS native selector stacking, which is not the proper way to use it, and then you define that feature as bad.

It's a tool, use the tools as you like, you can also just type CSS without using all the extra tools using Stylus. I cannot find anything bad about having a hammer in the house unless it's being misused.

Unfortunately for those hating CSS pre-processors, your destiny is to conform. Hand-crafted CSS is primitive and pre-processors are the first step in the ladder to the future of CSS. Get used to it, you better do.

Wow, dumb usage of sass is dumb? Thank you for enlightening me, I did not expect that.

Here's my criticism of regular CSS: if you hand-write a file that is 10 megabytes with 90000 selectors, it will not be good for your performance and will not work in browsers from the midle-ages.

"Developers have an inherited desire to be clever and that is usually a red flag" - without intelligent developers there wouldn't be a world wide web; think before you start throwing insults.

JavaScript, JavaScript, JavaScript. If we create a language to compile CSS it should be done in JavaScript or have JavaScript syntax. JavaScript should remain the official language of the browser to help the world be MORE efficient not 'less' efficient. This is just another abstraction that was created to skirt around allowing front end developer to any programming. Rather than make the world a more complicated place, and full of bad bloated compiled CSS, we should teach people how to write efficient CSS and use JavaScript to do dynamic things.

Also one more thing I would like to write is that the whole point of CSS in the first place was to make coding easier and more flexible. I believe it has made it more flexible, but not necessarily easier. These new languages need to make this easy or add something to be valuable and so far they aren't making anything easier and they have simply replaced the CSS syntax with their own. If you LEARN CSS you know how to do everything except variables already. Comma seperated lists and non-specific classes are the way CSS was intended to be used. That get's rid of your duplicate code. Furthermore these systems completely ignore the actual HTML. By adding and removing non-specific classes to the DOM elements themselves using JavaScript you can create much more interesting dynamic behavior than any of these pseudo-programming languages can achieve.

The point is we already have all the tools we need to create anything we want. Front end web developers just need to learn JavaScript and we can get rid of more Rube Goldberg devices. RIP. Oh wait, but that wouldn't add job security... sorry what was I thinking.

I use SCSS/Compass, and tbh I don't want to go back. A few things are very important to know/bear in mind however:

  • SCSS makes some stuff easier, but it makes some stuff harder. It should be used in situations where the easier > the harder

  • Nesting is useful, but always keeping in mind what will be compiling is very important. I stick to a rule of never having selector chains of more than 3 selectors, and I'd encourage anyone else to do the same. With SASS/SCSS/Compass, it's easy to accidentally wrap a whole block of selectors in a parent without really noticing, and this makes code less reusable.

  • Although you can pick SASS/SCSS up in a few minutes, you should get to know it very well before you use it for a huge project, or be prepared to rewrite and edit a lot. I did the latter, and tbf, it was good learning.

  • SASS/SCSS is great, but a good move is to optimise the actual CSS file afterwards too. AIUI, SASS is in the process of building such functionality in to the system, so two declarations of one tag will be declared together if possible etc. Until this is in place, optimisation afterwards is an almost essential step for big projects, and can be done automatically or manually, depending how much time you have.

That's it, my two cents. I've found some great ways to work with SASS, but it ISN'T the universal solution it sometimes gets made out to be - you still need to be good at CSS, and you should remember what CSSLint taught you. Also, knowledge of compiler design is good.

[...] Lee Corso would say, not so fast my friend.  Just as I am thinking I have found salvation, I read http://blog.millermedeiros.com/the-problem-with-css-pre-processors/.   I realize that I still have a great deal to learn about preprocessors before I make any [...]

I appreciate the article and agree with a lot of what you brought about... "Pick the tools based on the project and your workflow" - sometimes its very easy to get carried away by the availability of options such that it stifles both logical thinking and having a creative way to modularize your workflow.

I personally determine my own mixins infrastructure and use "extend" sparingly putting the goal at the forefront and determining how repetitive code or flexible it should be to replicate. I have used LESS before but started to learn and use SASS with a completely different perspective and respect for the tool. I even use it for Wordpress so already you can imagine the challenge in dealing with frameworks, outputs and such.

So it makes significant sense to understand the goal or objective of the project at hand before determining how to approach the use of such pre-processors. I believe SASS is going to increase my productivity 100 times but if I'm not careful, I could create more bloat than necessary. But then again, that depends on my experience, my knowledge of programming and my idea of modularizing my styles.

I trimmed off about 6k of "bloat" because of the tips in this article/comments. I still use SASS, but I use it better now by being selective about my nesting and by inspecting the output code after compilation. Thanks everyone!

[...] the other similar CSS meta languages it has it’s share of detractors and it’s [...]

although i do agree with this article, what i don't agree with is people being afraid of change. are we to be stuck on old technology forever? would you use a radio or tv from the 70's in your house or apartment? the answer to that is no. you would use one from this year or at most a few years old. things are constantly evolving and changing and we can't be afraid of it. sometimes change is bad, but sometimes it's good, and other times it's probably just best to band-wagon and do what most everyone else does. this way there is a larger community of people that can help each other out and provide tips and advice to problems that might arise.

Hello,

I think that the major concern against using preprocessor is always PEBCAK related. This post should be named "The problem with people who misued CSS-preprocessor" but for sure, it will not be as much controversy.

Nesting is bad if you do it wrong but for writing a lot of css, I can tell you that it is really handy and it allow to visually group selectors (reflecting html nesting) wich help identify / memorize it.

Also, the main concerns of what you describe in mixin/extend (dumb code / abstract) is already adressed in Sass with placeholder. http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholder_selectors_

Sass (and compass, stylus, ...) are all open source. Why not try to discuss these problems with their own communities ?

Lionel

I'm glad you wrote this because now I know where to send people who think I'm a crazy for not using pre-processors... Nice post.

I think the way you structure CSS and the ability you have to produce a smart CSS code are more important that the preprocessors themselves : they are a tool, nothing more.

I think preprocessors fans should spend more time to learn CSS instead of saying that "Sass/LESS/etc is THE thing to use, if you don't you're a dumbass".

Anyway great article. :)

I think this is an article where you can see bad examples to use preprocessors, isn't objective if you write only how to use wrongly a tool is obviously that you can say "This tool isn't good" the preprocessors are basic for modular css I always use: reset.css buttons.scss header.scss etc. and styles.scss which import the others and it is compiled to styles.min.css also the preprocessors are useful for determine 2 or 3 colors for your template and only you need to do things like: $base-color: red; $text-color: #F1F1F1.... and in your css h1{ color: $text-color} h2 {darken($text-color,20%} ... the preprocessors are bad? They have problems? No a tool like this don't have problems the people have probems.

I believe that preprocessors like SASS - which is the one I have been using for a while - are extremely helpful. I use it mostly because it allows be to make my code more modular and really easy to maintain, one of my favorite features are the partial files, which allow me to write all my media-queries, ie styles, slider specific styles in different files - SASS compiles them all into one files without adding the extra http requests. You would say that it is not much, but believe me it is if you're dealing with a huge website and you have to go back and forth within the same CSS document. It will save you plenty of time.

Yes, SASS or Less or.. can be bad if used wrong, but I assure you that it does make your life easier. It took me almost 4 years to finally switch over but it was well worth it.

[...] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they [...]

[...] Bert Bros escreveu um ótimo artigo com o nome de The problem with CSS pre-processors. Lá ele cita alguns pontos interessantes, que pra mim já são suficientes para não [...]

[...] Bert Bros escreveu um ótimo artigo com o nome de The problem with CSS pre-processors. Lá ele cita alguns pontos interessantes, que pra mim já são suficientes para [...]

[...] A Response To: The “dark sides” of LESS (and probably SASS) Reason: I refuse to Disqus it! Further Reading: The problem with CSS pre-processors [...]

trying to understand what you described in above post. I'm new in webdesign and web development. I would i like to ask does gzip compression decreases page load time or not ??

LESS does have an "extend" feature. I don't know if it's called that exactly, but it works the same.

Example:

.someStyle {width: 50px; height: 50px;}

.someOtherStyle { .someStyle; }

this will make

.someOtherStyle { width: 50px; height: 50px;}

[...] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they [...]

[...] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they [...]

What precisely honestly stimulated u to post The problem with CSS pre-processors | Blog | Miller Medeiros? I reallycertainly liked the post! I appreciate it -Carlo

[...] a no-brainer nowadays, LESS or Sass should maintain everyone’s tool belt. While not without criticism, these tools help way a lot more than they [...]

[...] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they [...]

[...] moderation. Nesting your CSS selectors and using lots of mixins are great ideas in practice, but as many people in the community have pointed out, they can lead to a few problems if not used [...]

[...] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they [...]

Well here we are in 2014 and I was just wondering if you are still CSSing pre proc free. I personally agree with just about every thing in this post. When I talk to people about why I have yet to get on board with pre processors, I feel like a jerk. I am basically telling them why, in my opinion the thing they like is stupid. : (

[…] H. Borges Medeiros (designer och utvecklare, CSS/JavaScript), vars blogg nämns i boken CSS3 Punshing the limits, pratar om problemen med CSS pre-processorer i ett […]

I'm more of the philosophy that good css writing starts with good design mockups. I'm also of the belief that is better to mix things in html for example

<

div class="button red small"> rather than mixing things in css. A lot of problems with css coding can be avoided during design mockup, because it is during that early stage of design where you should start recognizing what it would take to build this or that in css. Many folks that rely heavily on mixins probably made poor design choices during mockups.

Secondly, poor css writing happens because we tend to write from top to bottom. We start from the header and move down the page. What we ought to do rather, is build our site like builders build the house. You code the html/css structure first, then apply more specific styles, and finish off with detail. Because when you go with the top down approach, you may nest elements resulting in duplicate code.

[…] http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ […]

[…] 在现时的开发界,每个人都应该使用 LESS 或 Sass。虽然这类工具也有争议,但利大于弊。 […]

[…] das nossas referências, apontam as suas considerações sobre o tema. O Miller Medeiros, em um post mostra alguns pontos negativos na utilização de pré processadores. O Jean Carlos Emer em um […]

[…] Sass can be abused, bloating your code and complicating your workflow (See some problems in this critical article). It is a syntax with its own best-use standards to be mastered and bug-fixed. It is important to […]

YES!!!! You stated EXACTLY how I feel about CSS preprocessors and coffeescript! I'd rather just program the code, why add another layer! I don't really feel it helps much and just separates me from the real CSS. Like you said, may as well just write it correctly and you won't get most of these problems.

[…] Explica muito bem muitos dos perigos e problemas que essas ferramentas podem trazer. http://blog.millermedeiros.com/the-problem-with-css-pre-processors […]

[…] http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ […]

[…] a no-brainer nowadays, LESS or Sass should maintain everyone’s tool belt. While not without criticism, these tools help way greater than they […]

[…] a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they […]

FrontEnd Ninja

It is horrible to work with the code from my co-mates they working with less. its looks like, this people started to code with html and css. its overloading the css file, they never heard from the rumor of the great love of overflow:hidden and float, its looks like, they will never master html/css.

[…] 在现时的开发界,每个人都应该使用 LESS 或 Sass。虽然这类工具也有争议,但利大于弊。 […]

I'm still not convinced and I'm forced to work with these tools due to the sheer popularity so I'm not ignorant of them. CSS works best when it is minimal. Vars would be a great feature of the core language but not enough that I'll personally take SASS and LESS with all of the rest of the weight and potential for abuse they add to the workflow. The first thing every more exclusively engineer-leaning CSS noob does with SASS and LESS is go berserk with the nesting which bloats selector count in a hurry.

Quantity of selectors per property set is the real enemy of maintainable CSS IMO. Not specificity as the no-ID crowd would have you believe but the tangled mess that happens when you're trying to figure out how that eight class property landed where it did in a layout with a lot of HTML depth and how the heck you're going to override the silly thing somewhere else.

It's like templating. With older-school code-inline approaches you can bust into the JSP or ASP or PHP and do whatever the Hell you want. Sure we can blame the user for doing it wrong but I'd rather just have something like Django or a modern JS templating system that provides for loops and basic conditional switching but stops there on the dynamic side of things because some ninny, whether he's writing your app or wrote for some inextricable dependency stuck with, is always going to want to start making database calls or process images in the !@#$ing HTML.

And seriously, why do we want all these junk dependencies in our workflow? How many hours do you have to spend trying to figure out why docpad's file watcher craps out in OS-X before you start to resent the need for no doubt 4-8 different flavors of files being watched in the first place? I used to laugh at Java devs for all the crap they had to put up with, the hours of XML Ant/Maven BS just to get their apps up and running every freaking week and now I'm running any number of JS "transpilers", CSS compilers, dependency management junk in addition to NPM (why does everybody wrap/reinvent NPM?) and everything has to livereload because apparently refreshing a browser involves work.

If so then why peoples are using it. I see the statistics with LESS using builtwith.com and found more than 45K sites are using it including twiters bootstrap.

I feel like SASS is a bit of an epidemic pushed on rookie webdevs with no battle experience nesting ids and classes in their HTML and writing selectors as atomized units of a whole style which is an intuitive chain of selectors.

Your comment about SASS fixing problems you don't have speaks to it being a crutch.

While I do appreciate that you took the time to explain the reasoning behind each of your points, I must respectfully disagree with your premise. To me, what you're saying is no different than saying "We shouldn't drive cars because if you use them wrong, you could crash and kill people. Or the engine could blow up. Or you could speed and drive off a cliff. The risks are too great, let's just keep walking everywhere." Obviously this is not a perfect analogy, but every analogy breaks down at some point.

I've been doing web development for 11 years now, and did not start using CSS pre-processors until last year when I began my current job. Did I get along fine before being introduced to LESS/SCSS? Yes. Does that mean I should continue using vanilla CSS when there are better alternatives? Not at all.

You listed numerous potential pitfalls with CSS pre-processors, but at the end of the day, that's all they are...potential pitfalls. When used by inexperienced developers who do not have a strong knowledge of the ins-and-outs of CSS, and how browsers parse/render it, then yes, they can cause more issues than they're worth. However, for those with strong development skills, CSS pre-processors are a tool that can drastically increase efficiency within a workflow.

As long as you plan out your project beforehand (which everyone should do), and properly set up your development environment, then there's no reason for any of the potential issues to occur.

[…] to write some HTML and CSS (preferably you can code raw CSS3 and HTML5 even if you prefer using CSS pre-processers and mixins) as well as be able to use work with images (Photoshop, Pixelmator, Gimp, Illustrator).   […]

Here's the sad reality: In over four years of working on projects with SASS I have never once experienced an improvement in efficiency. Instead we all just have an extra layer of problems to debug and battle with. Write quality CSS; end of all problems. (CSS4 will provide the ability for constants, etc). SASS removes developers further from the problems in hand and is slow slow slow. Amazingly I can type, so the ability to not have to type characters such as a semi-colon doesn't really bother me too much!? SASS is extra treacle to wade through and only "solves" problems only poor CSS developers and poorly organized projects, seemingly suffered?

I think we should consider both pro and cons of css preprocessors and then decide why we are going to use it. If this is going to make more problems than benefits then this is not a good choice. code should be scalable and flexible at any point of time. i appreciate your views....

I do use SCSS, but mainly because it is the only sane way to customise the Foundation framework CSS. However, I agree with what you are saying except inline CSS - that should only ever be injected by code and only in very specific situations.

What many people don't understand is HTML and CSS were originally designed to work with pages of text and images as if reading book. We've come a long way since then, but all the changes right up to CSS3 and HTML5 fail to address the way we use the web today.

HTML and CSS were conceived as great democratic enablers; encouraging people to create something with little training, just like "Logo" and other "Turtle" languages allowed non-programmers to play with programming principles. HTML and CSS (less so JavaScript) can remain for such purposes, but it's time to grow up. What will the Web's Turtle to C++ moment look like? It's certainly not Java or C#, but it's just as certainly on the cards over the next five years. What we do know is Web 4.0 won't use HTML and CSS.

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.