4 ms·

Controversial opinion, but I myself use CSS preprocessors quite sparingly. I actually see nothing wrong with the CSS syntax. I like the fact that CSS is (almost

Controversial opinion, but I myself use CSS preprocessors quite sparingly. I actually see nothing wrong with the CSS syntax. I like the fact that CSS is (almost) nothing but a bunch of named key-value pairs. The real issues have always been semantic, in the subtleties of the box model, which Flexbox is addressing somewhat, though more daring ideas like constraint-based styling are still niche. Just look at the LESS example on the front page. The compiled output is simpler than the source you're writing. I find having some code duplication to be an acceptable trade-off for turning a basic declarative configuration language into a chimera DSL that must be incorporated into the build process. The more a configuration language strays away from being declarative, the less desirable this becomes.

sanderjd 11y ago
I think "some code duplication" massively understates it. Being able to use named variables for colors is on its own enough of a win to make up for whatever truth there is in the "harder to train developers" downside. The many other wins make it a no-brainer.
- robinson7d 11y ago
  Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.
- thebfed 11y ago
  It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/ http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.
  - sanderjd 11y ago
    Certainly, everything has trade-offs, but CSS pre-processors are more heavily weighted toward the positive side of the trade-off calculation than pretty much anything else I can think of, especially in the "web technologies" space. I found lots of the arguments in the OP to ring true – things often feel far too fancy, and the more "boring" stuff has major appeal – but I found the arguments against CSS pre-processors there and in the article you linked very thin relative to my experience with them after years of using raw CSS.
losvedir 11y ago
I'm sort of coming around to this perspective as well. Ever since I read this article[0] on more of a APL/J/K style to CSS (the author's blog's CSS looks like this[2]), I've noodled with the idea of doing straight CSS again, in this pretty condensed format. It's kind of shocking at first, but does have its own charm. [0] http://prog21.dadgum.com/200.html http://prog21.dadgum.com/200.html [1] http://prog21.dadgum.com/p21.css http://prog21.dadgum.com/p21.css
pjungwir 11y ago
Ironically in the context of the original article, it's precisely when you're trying to support IE 5+ or 6+ (or even more modest goals) that less/sass is really valuable, since you can generate chunks of CSS values with all the browser prefixes/hacky workarounds/etc, and still be able to think about things at a higher level.

sanderjd 11y ago

I think "some code duplication" massively understates it. Being able to use named variables for colors is on its own enough of a win to make up for whatever truth there is in the "harder to train developers" downside. The many other wins make it a no-brainer.

robinson7d 11y ago
Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.
thebfed 11y ago
It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/ http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.
- sanderjd 11y ago
  Certainly, everything has trade-offs, but CSS pre-processors are more heavily weighted toward the positive side of the trade-off calculation than pretty much anything else I can think of, especially in the "web technologies" space. I found lots of the arguments in the OP to ring true – things often feel far too fancy, and the more "boring" stuff has major appeal – but I found the arguments against CSS pre-processors there and in the article you linked very thin relative to my experience with them after years of using raw CSS.

losvedir 11y ago

I'm sort of coming around to this perspective as well. Ever since I read this article[0] on more of a APL/J/K style to CSS (the author's blog's CSS looks like this[2]), I've noodled with the idea of doing straight CSS again, in this pretty condensed format. It's kind of shocking at first, but does have its own charm. [0] http://prog21.dadgum.com/200.html http://prog21.dadgum.com/200.html [1] http://prog21.dadgum.com/p21.css http://prog21.dadgum.com/p21.css

pjungwir 11y ago

Ironically in the context of the original article, it's precisely when you're trying to support IE 5+ or 6+ (or even more modest goals) that less/sass is really valuable, since you can generate chunks of CSS values with all the browser prefixes/hacky workarounds/etc, and still be able to think about things at a higher level.