Hacker News new | ask | show | jobs
by cmaher 3957 days ago
> "Tired of all the slow and bloated preprocessors..."

libsass is amazingly fast. I generally see it churn through ~20k lines of CSS (don't ask) in 6ms.

2 comments

Just as I can not rip my bleeding eyes away from Honey Boo Boo, I can't not ask how you got 20K lines of CSS. Families live under the covers of ~5-6K of CSS. Major click bait sites exist with 10-15K of CSS. Help all of us here. You only have 6 lines of HTML and the 20K of CSS does all the work?!? I feel the iterwebtubes are doomed.
Look at major websites. You can easily reach 50k to 200k+ lines of CSS in a large project.
It's true. sassc(1) is a great step forward in terms of speed.

That said, Sass encourages practices that I consider bad. Nesting, @extend, etc.

Sass's design also makes it difficult to implement a basic feature like grouping all media queries for a single output. Check this issue from 2011: https://github.com/sass/sass/issues/116

If you don't mind a bigger tool and the dependency on Node.js, then PostCSS looks very good: https://github.com/postcss/postcss

Why do you consider nesting bad? I'm on the opposite side -- would be interested to hear your thoughts.
Most importantly: it's very easy to end up with a huge CSS file that can't be compressed, and it makes everything more complicated.

Representing hierarchy in the class name makes the output shorter, in most cases, and makes the HTML and CSS code easier to understand. For instance, when you see <div class=title>, you need to go up to find context to understand what that "title" class is. If you have <div class=widget-title>, that's much better. Let alone that generic ("title") classes can lead to problems with conflicting rules depending on their specificity.

By the way, classes at the top level are faster to parse and apply.

This articles expands on some of these issues: http://www.sitepoint.com/beware-selector-nesting-sass