
Why I don’t use CSS preprocessors - ausjke
http://www.456bereastreet.com/archive/201603/why_i_dont_use_css_preprocessors
======
__michaelg
Whenever I mention that I don't use compilers I tend to get strange looks from
people who cannot imagine writing assembly with using a C or Fortran compiler.
And so I have to defend my choice and explain why, over and over. Some people
will understand, most won't. Or they don't want to. But here is an attempt to
explain my reasoning.

[...]

A list of reasons then:

* I don't feel the "problems" compilers intend to solve are serious enough to warrant the cost, i.e. to me the solution is worse than the problem.

* I want absolute control of my instructions, which means I want to work hands on with it, and see exactly what will be executed by the CPU (well, before it's translated into its binary form, of course.) If that means seeing the same setup of stack frames and the manual register allocation over and over again, so be it. To me, WET assembly is much more understandable and maintainable than DRY C.

* I don't want to learn and depend on a non-CPU-vendor syntax for my programs, making it require compilation before CPUs can understand it. Neither do I want my colleagues to have to.

[...]

~~~
smoyer
I'm always shocked when I run into people who use an assembler instead of
interacting directly with their target hardware. If you're dedicated to your
craft, you memorize the associated byte-code and enter that directly into the
computer's memory. With practice, the machine will crash with less than 50% of
your changes.

On a more serious note, the first computer I ever touched had six thumbwheels
that were used to enter a memory address (4) and the associated byte to be
placed at that location (2). The first computer I ever built/owned was a
COSMAC ELF [1]. It (originally) had 8 toggle switches that could be used to
enter the address and data (serially). In both cases, you still wrote assembly
(on paper) and used a translation table to look up the associated byte-codes
which you transcribed to the paper. Finally you actually entered it via the
system's input.

[1] [http://www.cosmacelf.com/](http://www.cosmacelf.com/)

~~~
amelius
Why even rely on the machine instruction decoder implemented in your
microprocessor? I prefer to hook up ALUs and flipflops manually...

~~~
50CNT
That's a lot of work though, I just let the verilog compiler handle that.

------
Lazare
Obviously the author should use whatever they want. But...the reasons given
aren't in any way compelling.

> If my build process fails, for whatever reason (like an unpublished npm
> module),

If you were unable to deploy because `left-pad` got unpublished then 1) you've
got way more problems than your use of SASS, 2) not using SASS would not have
helped you because you're build process is still broken, and 3) you could
still run SASS manually.

~~~
andersen1488
Agreed. Really the only legitimate point is the increased iteration time when
working with a preprocessor vs straight CSS. But even that can easily be
overcome by using an auto-reloader

~~~
Freak_NL
On a modern computer with SSD drive the iteration time is actually negligible
for a not too complex stylesheet; auto-reloading might even be faster than
manually refreshing your browser without a build chain.

~~~
ivanhoe
yes, on fast computer with small sass... as the size and number of watched
files increases so does the reload time, and while it's still not some huge
delay on its own, it does add up when you repeat it hundreds of times a day,
and can be a real pain in the ass... to the point that I usually test all my
changes live in css first, and then implement the final version in sass later,
for easier management.

~~~
Silhouette
It's a separate issue to CSS processing, but do you not find that tools like
live-server or browsersync that hot-reload CSS changes are more efficient than
manually refreshing the browser anyway? They update quicker than a full
refresh, and if you're working on interactive web apps then they have the
significant advantage that any other state you've set up doesn't get discarded
while you experiment with styling.

~~~
ivanhoe
I use browsersync all the time, it's a great tool, but IMHO it's still much
more hassle then just live editing css in chrome devtools and then having the
browser save the changes to local css files directly. No need to reload
anything, you just save it and you are free to continue working... of course,
sass has many other benefits, it's a way easier to manage, but with devtools
pure css workflow is nowadays really fast and streamlined, too.

------
usaphp
To me this just shows his lack of experience working with a big project where
using things like variables and scoping things helps a lot. And what about
mixins? To me they are a great tool to fight code duplication, especially once
you start dealing with responsiveness for multiple hundred of elements and
need to generate similar styling based on dimentions of a screen, I can't
imaging maintaining a big site using regular css, it would be a nightmare.

~~~
wallacoloo
> I can't imaging maintaining a big site using regular css

It wasn't that long ago that nobody used [the current big-name] CSS
preprocessors. But site admins got along fine, and I certainly didn't hear
many complaints.

To each their own, but I don't find maintaining a big site with 'regular' css
unimaginable.

~~~
viraptor
> But site admins got along fine

Apart from those who generated css dynamically. And those who hated the
situation enough to create preprocessors to improve their lives.

"Before X people were ok without X" is a tautology.

~~~
coldtea
> _" Before X people were ok without X" is a tautology._

No, it's not.

Sometimes new techniques appear without anybody feeling there was a problem in
the first place.

Other times they appear after people struggle and curse their way without
them.

"Before X people were ok without X" only refers to the first case, so it's not
a tautology applicable to all cases before X.

E.g. people always struggled with webpage layout, and knew they needed a
solution X to appear, even before an X emerged.

------
PaulB_GD
Variables though, I can't see how you can go without them. Being able to
change 6 characters and have the entire site theme change for a client is
great.

~~~
j4kp07
I would never allow a design get that far into the process and then allow a
client to start testing various colors. That is just asking for trouble.

~~~
Silhouette
Have you never implemented a design yourself, and then found that when you
looked at the results as a whole, it didn't work quite as well as you hoped
from the original concept work?

Have you never A/B tested a site and found that varying colours made a
difference?

Have you never developed a site with some colour scheme and later found you
needed to extend the colour scheme, perhaps to incorporate a new product or
service being added to the available range?

Having a colour scheme that is set in stone early on sounds like one of those
idealised things that sometimes just doesn't work in the face of reality.

~~~
anotheryou
I agree!

I'm currently building something that has mild themes for fonts, colors and
some margins (and is build on top of a SCSS framework, but that wasn't my
choice), without color variables it would be a pain...

------
robertelder
One of the reasons that I don't use css preprocessors is actually because it
promotes very aggressive de-duplication of code. Keeping code duplication to a
minimum is a healthy practice for any project, but I find that it is usually a
pre-mature optimization for a project where the requirements keep changing a
lot (which is especially true for we dev projects).

The disadvantage you get with css preprocessors in this case is that you have
lots of tight coupling between a large number of concepts, and you're much
more likely to subtly break something unrelated by updating your highly
generic code. People have cited 'big' projects as being one of the main
reasons to use these preprocessors, but more and more, I find that as projects
become larger and larger tight coupling becomes a bigger problem. In this case
duplicating code can often the _solution_ , and not the problem (because it
reduces coupling).

Of course, after you've shipped the feature you should take time to carefully
refactor all the duplication into a common location, but companies often don't
give you time for this critical last part.

------
TamDenholm
Almost every single comment here is berating this guy for not using SASS,
saying he's wrong. Just because he does it a different way doesn't mean it's
wrong. Can we please disagree while respecting the guys decision to do what he
wants?

There's more than one way to solve a problem, especially in the coding world.
There are always "better" ways, but at the end of the day, if plain css works
for him and he can solve the problem with it, more power to him. Let's not get
the pitchforks out please.

~~~
tacos
His previous blog post berates vendors for using vendor prefixes in CSS.
Presumably because this conflicts with his desire not to automate the process
by using a tool.

Take an unpopular stance and write a weak blog post in support of it -- while
being self-contradictory -- and you can expect people to speak up when it hits
HN. I don't see pitchforks. I see people who are smarter and more experienced
rolling their eyes while taking some time to share experience late on a Friday
night.

~~~
TamDenholm
I was only asking that we respect this guys ability to solve the same problem
as the "smarter and more experienced" without the "eye rolling" and
condescension. We could instead educate, encourage and inspire people (not
necessarily the author, the other HN readers) to new techniques and advocate
their strong points while still respectfully disagreeing with an "unpopular
stance".

------
Bahamut
This reads as rambling - for example, "I don’t feel the “problems” CSS
preprocessors intend to solve are serious enough to warrant the cost, i.e. to
me the solution is worse than the problem." doesn't really expound on this
narrative.

~~~
ehnto
It also means he likely doesn't understand the features correctly, which might
be because he hasn't encountered the problems they solve yet.

Trying to maintain a gigantic multifaceted application with thousands of lines
of just CSS, and half a dozen developers working on concurrent features is a
nightmare, source control included.

Breaking apart your application into reusable components represented by single
files is an incredible maintainability boost. You can achieve it without SASS
but it's features help a lot in achieving it.

The nesting then helps to achieve higher readability for the developers and
makes it easy to find what you need to modify.

~~~
Bahamut
Agreed, just didn't feel the need to bring it up - I feel it's obvious.

------
tomphoolery
Although I use Sass, I frankly don't make use of mixins or includes very
often. That said, when I actually do need that functionality it's great that I
can just write it without having to re-think the solution. The author's point
about not leveraging those features too much is definitely something to think
about....If I've learned anything in the last 15 years of being a web
developer, it's that the best bet is to stick with what the browser provides.

~~~
tracker1
I can't imagine what a pain in the ass it would be to deal with a dynamic site
(different appearances at different browser sizes) without a preprocessor...
Just to be able to nest the media query rules next to the regular rules,
instead of inverting them over, and over again.

That doesn't even get into variables and mixins (I use the former much more).
Variables in particular help a lot if you have two types of things the same
color, and now need to change one of them... wow, that can be a pain in
classic CSS without a preprocessor.

I just spent a couple days dealing with a web app that doesn't use any
preprocessing for JS or CSS, and man is it hard to deal with... no, I'll stick
to babel and at least postcss (if not sass).

------
DGCA
Is your project small enough that variables don't benefit you? Okay, don't use
CSS preprocessors.

~~~
yoavm
Actually CSS has variables (even if the syntax is slightly messy) -
[https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_v...](https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_variables)

~~~
debaserab2
No, it doesn't in any sort of browser compatible way.

------
morrisda
I think you can simply use preprocessors and write vanilla css as well, and
using just a few preprocessor's features that could really help you
maintaining your code (maybe variable). If you write on sass as you write in
css, it will get compiled in the same way. If you find it too slow to compile,
maybe you are using an high level compiler. There are native ones like
[http://sass-lang.com/libsass](http://sass-lang.com/libsass) and i can't
figure out lasting about 1 second to compile.

------
tacos
Most of these "complaints" could apply to tools of any form in any discipline.
If you've been in tech a while you've heard it all before. Hang around
woodworkers and you'll hear people bemoaning progressive use of fasteners,
too.

But really... what's the point? He's not particularly insightful in his blog
post. Nor does he appear amenable to other viewpoints. "Good job dude, keep
micromanaging your CSS. Keeping up to date with the latest -webkit-this-that
is an awesome use of your limited time here on Earth. Search and replace when
you change shades of blue is _brilliant_. You're a superhero!"

... that's good for two downvotes and nothing else.

So I'll offer this: there's a experience level of engineer where this kind of
thinking is common. It's a mix of fatigue and self-micromanagement. Getting to
the next level often requires rethinking your assumptions and thinking bigger
picture. Don't be this guy.

~~~
oneeyedpigeon
Your argument that you should use a CSS preprocessor because it makes changing
a shade of blue easier is a weak one because a) search/replace for such a case
IS perfectly viable b) it is likely to occur so rarely that the savings - if
any - will be minimal. There may be other reasons to use a preprocessor, but
complicating an architecture for very little benefit might actually be
counterproductive.

~~~
nailer
You don't often change the values of variables and you're better at regex than
most front end engineers?

~~~
oneeyedpigeon
No, the colours of the sites I look after don't tend to change on a regular
basis. And, if they did, a regex wouldn't be required for the search and
replace.

~~~
tacos
I'm a designer. There is no "blue". There's the blue in the logo. And then
there's the blue saturated a bit more when it's on a gray border. And there's
the blue brightened a bit when it's on white. If repeating yourself over and
over in CSS makes sense by all means stick to your guns. This practice is
verboten in all other aspects of tech engineering and it's only the truly
idiotic nature of CSS that has people thinking like this to begin with.

------
floatboth
"I don't use preprocessors… except… I use PostCSS"

Well, yeah, I prefer PostCSS to others too. Syntax based on future standards
is better than syntax invented just for a specific preprocessor, but I don't
think the difference is THAT significant.

------
jtchang
Are you kidding? He even says on his twitter that he is a best practice
promoter.

No. You should be using a CSS preprocessor. There are tons of them out there
and for good reason. Best practice would be to use SASS.

The only time I could see best practice being "use pure css" is if the project
is so small it doesn't matter or you are learning CSS. Even SASS allows you to
write CSS and gives you a ton of flexibility in organizing your code. Yes CSS
is code.

He even mentions one of the reasons is to avoid having a compilation step.
Well lots of things require compilation and generally it is to make our lives
easier. The trade off between a broken pipe-line and maintainability via Sass
is certainly worth it.

~~~
spriggan3
> Best practice would be to use SASS.

Best practice would be to use LESS.

~~~
nailer
As some one used less since 2010, it really isn't. Less is like Mercurial, it
may be better than git but not enough to make a difference and the network
effects of using scss are massive.

------
jwdunne
I love SASS. After years of wroting vanilla CSS, you really get to appreciate
some of its features e.g nesting, variables.

The problem is this: for small websites, you don't need to pay a lot of money
to get a lot of work done. These are not the greatest developers who use the
latest and greatest tools. They write decent vanilla CSS, HTML, JS and that's
about it.

For large projects, I would use SASS but for smaller projects that won't grow
much greater, for which I have a lot of, CSS is just fine. Gulp, SASS et al
complicate the mix and make it harder to get things done and projects turning
a profit at a small scale.

------
lowmagnet
We have a build that compiles 30 sites of common css into site specific
themes. This build runs inside a lesscss plugin for maven that takes 2:24 to
build everything. It does them one at a time and seems to throw away commonly
compiled bits regularly.

When we dont need new css, we pass a profile disable that wraps the css
compile.

This may be an extreme case, but most of it seems avoidable with normal
cascades. My front end people want the "convenience" of less, but they dont
consider the cost until it hurts their build times.

------
hobarrera
Previous discussion here:
[https://news.ycombinator.com/item?id=11409808](https://news.ycombinator.com/item?id=11409808)

------
kyriakos
As long as you don't abuse nesting CSS preprocessors make the world a better
place.

------
justinlardinois
Fair enough.

I think it really depends on your environment and the scale of your software.
CSS preprocessors are trendy and hip right now and often get used with
projects that are too small to really need them.

I hacked a little PHP into the stylesheet on my website so I could have some
randomized colors.

------
kabes
I'm getting tired of these "Why I don't use X" posts. Just use whatever you
want and be done with it. Why do you necessarily need to explain your
rationale behind it to random people who never questioned you about it?

------
lowmess
Performance for Sass has not been an issue since libsass. Not once have I been
able to switch to the browser faster than my Sass has compiled. Most of the
time I even miss the browser-sync reload.

------
ofir_geller
"I want my source CSS to be deployable at all times, albeit in un-minified,
un-concatenated form."

Add the output css to source control, now you can always deploy that in an
emergency.

------
philliphaydon
I use CSS processors for name spacing. That's pretty much it.

------
MichaelBurge
I use LESS to at least define constants easily. It's useful to be able to
define your site colors as a few constants to keep things consistent.
Theoretically, I could dynamically generate it on the server for the same
effect, but that breaks my workflow because I usually write the HTML + CSS
first in a prototype page before writing any server-side code.

You can mitigate #4 and #5 by importing less.js during development. I don't
know if SASS has something similar.

------
vonklaus
i may be using these tools "incorrectly" but i have a modularized component
based structure with components/partials in one directory(e.g sometimes
_footers.scss or sometimes _landing.scss based on project) and another with
varibles.

However, I compile and write my CSS to disk and serve it. so maybe i am
atypical, but i thought that was common. i obviously perfected my workflow
over time but i got it setup initially in like 2-3 hours which was a great
investment given i use it often and this was 2 years ago. that is why i dont
understand this post.

> don't feel problem worth cost

again, it is almost exactly the same as css but you can nest. you can fork a
build tool and use it quickly (2-3 hours with a highly optimized setup) and
this atrgument doesn't hold up if you use processing as you already have the
setup in place, e.g adding 1 module to gulp and just git cloning local if you
are that worried about dependency.

> i like control of my css

me too i find nested representation provides better selector targeting, much
more readable and reflects the html structure it corresponds to

> deployable

i may be atypical, i just write 1-3 files to disk and they are served as
static css

> dont want to wait

i have to wait. it is 2 seconds at most. however, and this is not snarky, that
ends up getting annoying. somewhere around under 1 second usually but
sometimes you have to reload twice and tricks you into thinking you made s
mistake

however, with livereload or nodemon changes propogate quick so the
componetization is great for even small projects. doubly if you have to ever
collaborate with anyone as it gets annoying dealing with other peoples "best
practices" when css is the wild west with a global namespace so collisions and
cascading overrides are annoying if nothing else, leaving aside formatting and
naming conventions

------
grav
React components with inline css has eliminated the need for preprocessors and
stylesheet classes for my team altogether.

------
websitescenes
I can build out CSS at least twice as fast with a preprocessing and it's much
easier to update later. why waste your time for some dogmatic belief? It's not
like we're programming in 0 and 1s still. CSS is already an abstraction, why
fight more abstraction? That's the progress of technology.

------
Tiquor
I started using a preprocessor because I wanted to be able to maintain and
compose multiple stylesheets in a complex app with lots of subcomponents with
some distinct styling. Once you do that, you've introduced a compiler in your
workflow and it may as well be a preprocessor.

------
andrewclunn
With the inclusion of CSSnative variables, some functionality may be lost by
using preprocessor, but that's a reason to avoid them based on actually
knowing them, and this article feelings like it's more subjective attitude
than based on experience.

------
reustle
I used to be against css preprocessors as well, but nesting is what eventually
sold me. It just makes so much sense. My code isn't cluttered with tons of
classes, and the css is far more readable.

------
KayL
Only one problem I have while using CSS preprocessors. It's not so searchable.

------
niuzeta
Respectful opinion, but as an only part-front-end dev...

> I don’t feel the “problems” CSS preprocessors intend to solve are serious
> enough to warrant the cost, i.e. to me the solution is worse than the
> problem.

I don't think CSS preprocessors _solve_ any problem per se, insomuch that C
preprocessors _solve_ any problems - they just help the code without
introducing extra syntax to the core language.

> I want absolute control of my CSS, which means I want to work hands on with
> it, and see exactly what will be sent to the browser (well, before it’s
> minified and gzipped, of course). If that means seeing the same declarations
> repeated in several rules, or having to see what vendor prefixes look like,
> so be it. To me, WET CSS is much more understandable and maintainable than
> DRY black box pseudo-CSS.

I don't see how this argument is different from refusal to use any language
other than C for complete control. While it _does_ give you complete control,
often times it may not even be worthwhile. In fact, SASS constructions are
well-defined(enough) that most of time, you can derive exactly how the
resultant CSS will look like; of course, some minute optimization may be
required but the same argument can be made by pointing out that dlls exist.

> I don’t want to learn and depend on a non-standard syntax to wrap my CSS in,
> making it require compilation before browsers can understand it. Neither do
> I want my colleagues to have to.

Unless your team uses two different method of compilation on one
environment(i.e., agreeing on which implementation to use), I doubt there'll
be any problem with consistency. If you _do_ use different compilations so
that _standardness_ matter, then you have a different problem.

> I want my source CSS to be deployable at all times, albeit in un-minified,
> un-concatenated form. If my build process fails, for whatever reason (like
> an unpublished npm module), I can deploy the source CSS as an emergency
> solution. Performance may perhaps take a hit, but a slightly slower site is
> likely better than a site with broken or no CSS until the build process can
> be fixed.

This is a non-sequitur on a hypothetical situation on artificial emergency.

> I don’t want to have to wait for compilation before seeing the results of my
> CSS changes. Processing time may be anything from negligible to frustrating,
> obviously, but if it takes longer than the time it takes for me to switch
> from my code editor to my browser and reload the page (≈1s) it’s too slow.

filesystem watch generally handles the auto-compilation, and am I the only one
who edits css _on-browser_ first before editing files on CSS sheet? If the
only way to edit styles on web page is editing the source and reload, this
method will definitely cause much more frustration on dynamically generated
applications.

I can sort of see where this person is coming from, but I would say the
benefit outweighs the cost here. Again, personal preference, but I would
rather have my team employ preprocessor just for variables and palette from
designs.

------
usaphp
Looking at his other articles on his blog I stumbled upon this one:
[http://www.456bereastreet.com/archive/201304/responsive_drop...](http://www.456bereastreet.com/archive/201304/responsive_drop_shadows/)

He recommends using images in order to create a shadow...and that was in the
middle of 2013, when "box-shadow" css attribute was supported by all major
browsers with some prefixes...and the funniest part is that he is using shadow
image as an :after pseudo-element which has the same browser support as the
"box-shadow", this tells a lot about his CSS skills.

~~~
BinaryIdiot
Perhaps you should check your own CSS skills before trying to find further
information on his blog to simply use to trash him? This wasn't even
constructive it was just a rush to find _something_ to say "ah ha!".

IE8 supports :after[1], IE8 does _not_ support box-shadow[2]. Furthermore he
even explains, in his first paragraph, that what he is showing allows for a
more _complex_ design look over 'box-shadow' which, even if what you
originally said was true about browser compatibility, it _still_ explains his
reasoning and says _absolute nothing_ about his CSS skills.

[1] [http://caniuse.com/#search=%3Aafter](http://caniuse.com/#search=%3Aafter)

[2] [http://caniuse.com/#search=box-shadow](http://caniuse.com/#search=box-
shadow)

~~~
usaphp
from the article: "I then gave the box element a padding-bottom in percent,
calculated by dividing the image’s intrinsic height by its width, in this case
37 by 992 pixels"

What the hell is that? if somebody recommends me doing that he obviously is
not that good with CSS.

Also how is support for IE8 is even relevant? It's a 7 year old browser.

~~~
robocat
> Also how is support for IE8 is even relevant?

Ten employee business, 5% of clients today on IE8. We have fewer users on
Firefox, so we should do support for that too... And we might as well stop
supporting our Android users too.

Generally we drop support when user stats drop below 1%. Even that can cause a
lot of trouble for our client businesses (we don't want to be hated for making
them change, regardless of how impatient we are for them to do so, or how
insecure they are for not doing so).

~~~
usaphp
If a customer is still using IE8 I am positive that he will be OK with not
seeing a box shadow on an element, and making 95% of other clients suffer and
download images for generating box shadow is just plain stupid for me. I would
either ditch those 5% of clients and focus on better features than spending
lots of time on restraining cool functionality in order to satisfy a 5% of
users on IE8

~~~
BinaryIdiot
> making 95% of other clients suffer and download images for generating box
> shadow is just plain stupid for me.

The images are likely a few hundred bytes if you do it right. Regardless this
is an old article you dug up just to attack the guy; OBVIOUSLY it's far less
relevant today than it was when it was originally written.

