CSS预处理器能否生成更高效的CSS代码？

Question

By efficient I mean less code (less css rules).

Because I'm converting a CSS file to less, and I'm surprised to find out that the compiled CSS file is quite small (I haven't finished yet :P)

Answer 1

It really depends how you structure your code in LESS. The compiled output can become quite unwieldy if you use a lot of mixins (for example for gradients) or the @ operator to nest selectors too liberally.

All in all one could argue that they 'can' produce more efficient code if used properly. But then, so can you I you use plain CSS.

Answer 2

As noted above, it largely depends on whether your CSS was inefficient to start with. However, there is almost no situation in practise that requires more "efficient" CSS (I'm talking about performance rather than repetition) - yes it's bad to duplicate rules etc, but first and foremost should be code readability and maintainability.

In general, I find that the productivity gains from using a pre-processor far outweigh any issues with rule repetition, and if it's actual filesize you want to cut down on then WinLESS (and other compilers) can minify at source.

Answer 3

In general tools like LESS or SASS will not be able to produce as streamlined CSS as writing it manually (with proper knowledge), because the tools have no knowledge of the DOM on which they're operating. Any optimizer will only be as good as how thoroughly it can assess the runtime environment, and the missing DOM is a pretty big variable. If you structure your document properly and write the CSS to take advantage of that, then the output will be far smaller than generated code.

The advantage to these tools like any form of code generation or even higher level languages for that matter is that they enhance productivity. More consistent and possibly maintainable output can be produced more easily, but in order to do so these tools will be uncompromisingly explicit and "safe", and therefore produce code that a human would able to easily recognize as unnecessary when associated with the document. In general development and maintenance costs are higher than CPU cycles, so the productivity gains win out out. There may be times like any other when there may be performance issues that need to be addressed, but "premature optimization is the root of all evil" - Knuth

Answer 4

LESS (when compiled) and Sass both minify your CSS. In addition to stripping out whitespace, you'll sometimes see things like border: 0 10px 0 10px get turned into border: 0 10px or colors like #666666 turned into #666 . It isn't any more efficient, but it does make a smaller download for the user (which is valuable for mobile devices).

That said, Sass has a unique directive called @extend, which allows you to group your styles logically in the pre-compiled state, but will group them together to avoid duplication in the compiled state.

.classA { color: blue }

// 50 lines of code defining other elements...

.classB { @extend .classA }

Will output something that looks like this:

.classA, .classB { color: blue }

It doesn't seem like that big of a deal with 2 classes only having one thing in common, but its a bigger deal the more elements you are using and the more things they have in common.

Otherwise no. The efficiency is entirely based on the author.