11 ms·

Why I don’t use CSS preprocessors

103 points by ausjke 11y ago

philliphaydon 11y ago
I use CSS processors for name spacing. That's pretty much it.
justinlardinois 11y ago
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.
Bahamut 11y ago
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 11y ago
  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 11y ago
    Agreed, just didn't feel the need to bring it up - I feel it's obvious.
DGCA 11y ago
Is your project small enough that variables don't benefit you? Okay, don't use CSS preprocessors.
- yoavm 11y ago
  Actually CSS has variables (even if the syntax is slightly messy) - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v...
  - debaserab2 11y ago
    No, it doesn't in any sort of browser compatible way.
  - Retra 11y ago
    CSS was invented 20 years ago and it needed variables then. It still doesn't really have them.
  - DGCA 11y ago
    I'm very excited for this to be widely supported. Right now, though, support is totally lacking in IE and Edge.
- txutxu 11y ago
  Agreed partially. I seems like the counterpart is: "if you need variables, then use pre-processors". Well, when I've needed variables to ease changes on CSS files, I've used a template system (previous to all current pre-processors).
  - wallacoloo 11y ago
    Same here. My html pages already use a template system - why not use the same one for my CSS files? As a bonus, I get proper dependency tracking for my CSS files (i.e. which font files does it require at run-time, which other CSS files should trigger a rebuild when changed, etc) because my templating system is already rigged to do that. I could never figure out how to extract a dependency list from SCSS files, though I didn't search for very long.
reustle 11y ago
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.
kyriakos 11y ago
As long as you don't abuse nesting CSS preprocessors make the world a better place.
PaulB_GD 11y ago
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.
- nostrademons 11y ago
  Sure, but there are plenty of other ways to achieve the same effect. One I used for many years was to run your CSS through the same templating engine that generates your HTML. Wait a few more months and you might also get native CSS vars: http://caniuse.com/#feat=css-variables http://caniuse.com/#feat=css-variables
  - Lazare 11y ago
    > One I used for many years was to run your CSS through the same templating engine So...a preprocessor? :)
    - nostrademons 11y ago
      That you have to use anyway.
- ino 11y ago
  Is there a css3 variables compiler/processor/translator to plain css without variables? It can be a copy-paste tool on the internet or whatever, no preprocessor or build tools required. You work directly with styles.css3 in the browser and when you're done you transform it to old style without variables, so it works in older browsers. That's what I wanted to do last week but as I couldn't find such a tool, at the end I did a search/replace. It was a small project obviously.
  - cobalt 11y ago
    i think that is what postcss does
    - 11y ago
vonklaus 11y ago
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
Lazare 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
KayL 11y ago
Only one problem I have while using CSS preprocessors. It's not so searchable.
hobarrera 11y ago
Previous discussion here: https://news.ycombinator.com/item?id=11409808 https://news.ycombinator.com/item?id=11409808
jtchang 11y ago
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.
- jeswin 11y ago
  >Best practice would be to use SASS SASS is a personal preference and one of the available options, not a best practice. PostCSS is a great option, with the ability to use upcoming CSS specs in the same way Babel lets you use ES7 on today's JS engines.
- deleted 11y ago
  [deleted]
- spriggan3 11y ago
  > Best practice would be to use SASS. Best practice would be to use LESS.
  - nailer 11y ago
    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.
tacos 11y ago
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 11y ago
  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 11y ago
    You don't often change the values of variables and you're better at regex than most front end engineers?
    - oneeyedpigeon 11y ago
      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 11y ago
        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.
ocfx 11y ago
Clickbait. No valid arguments made.
MichaelBurge 11y ago
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.
tomphoolery 11y ago
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 11y ago
  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).
niuzeta 11y ago
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.
grav 11y ago
React components with inline css has eliminated the need for preprocessors and stylesheet classes for my team altogether.
usaphp 11y ago
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.
- BinaryIdiot 11y ago
  > 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. Honestly depends on how you structure the HTML and CSS. I've worked on some very, very large projects stretching across 15 subcontractors and we did not use css preprocessors. It wasn't even an issue really. CSS is really great at cascading properly. Most of the times I've seen where people want to use variables could have been just as easily accomplished via inheriting from a top level style. But I'm not going to sit here and tell you you're an idiot for using CSS preprocessors. They serve a purpose. They work. Yes they complicate things further but if it helps you deliver faster I'm not going to complain...much :)
  - nailer 11y ago
    The general approach without using mixins is creating visual classes, which now means the look of say .login-box is determined in two places : the HTML where .login-box has visual classes added and the CSS for .login-box and whatever the visual classes are.
  - Akkuma 11y ago
    I'm hard pressed to believe the quality of the CSS across 15 subcontractors was actually good and consistent. You can't get 5 developers in a room without finding at least a few differences in opinion how something could or should be done and when it comes to CSS you have even more flexibility to how you're writing it and the associated markup. What was done to ensure similarity of HTML/CSS across such a large project?
usaphp 11y ago
Looking at his other articles on his blog I stumbled upon this one: http://www.456bereastreet.com/archive/201304/responsive_drop_shadows/ http://www.456bereastreet.com/archive/201304/responsive_drop... 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 11y ago
  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 11y ago
    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 11y ago
      > 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).
jwdunne 11y ago
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.
TamDenholm 11y ago
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 11y ago
  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 11y ago
    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".
lowmess 11y ago
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.
__michaelg 11y ago
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 11y ago
  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 11y ago
    Why even rely on the machine instruction decoder implemented in your microprocessor? I prefer to hook up ALUs and flipflops manually...
ofir_geller 11y ago
"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.
andrewclunn 11y ago
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.
lowmagnet 11y ago
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.
robertelder 11y ago
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.
websitescenes 11y ago
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.
morrisda 11y ago
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.
floatboth 11y ago
"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.
kabes 11y ago
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?
Tiquor 11y ago
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.

103 points by ausjke 11y ago

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

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.

Bahamut 11y ago

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 11y ago
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 11y ago
  Agreed, just didn't feel the need to bring it up - I feel it's obvious.

DGCA 11y ago

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

yoavm 11y ago
Actually CSS has variables (even if the syntax is slightly messy) - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v...
- debaserab2 11y ago
  No, it doesn't in any sort of browser compatible way.
- Retra 11y ago
  CSS was invented 20 years ago and it needed variables then. It still doesn't really have them.
- DGCA 11y ago
  I'm very excited for this to be widely supported. Right now, though, support is totally lacking in IE and Edge.
txutxu 11y ago
Agreed partially. I seems like the counterpart is: "if you need variables, then use pre-processors". Well, when I've needed variables to ease changes on CSS files, I've used a template system (previous to all current pre-processors).
- wallacoloo 11y ago
  Same here. My html pages already use a template system - why not use the same one for my CSS files? As a bonus, I get proper dependency tracking for my CSS files (i.e. which font files does it require at run-time, which other CSS files should trigger a rebuild when changed, etc) because my templating system is already rigged to do that. I could never figure out how to extract a dependency list from SCSS files, though I didn't search for very long.

reustle 11y ago

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.

kyriakos 11y ago

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

PaulB_GD 11y ago

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.

nostrademons 11y ago
Sure, but there are plenty of other ways to achieve the same effect. One I used for many years was to run your CSS through the same templating engine that generates your HTML. Wait a few more months and you might also get native CSS vars: http://caniuse.com/#feat=css-variables http://caniuse.com/#feat=css-variables
- Lazare 11y ago
  > One I used for many years was to run your CSS through the same templating engine So...a preprocessor? :)
  - nostrademons 11y ago
    That you have to use anyway.
ino 11y ago
Is there a css3 variables compiler/processor/translator to plain css without variables? It can be a copy-paste tool on the internet or whatever, no preprocessor or build tools required. You work directly with styles.css3 in the browser and when you're done you transform it to old style without variables, so it works in older browsers. That's what I wanted to do last week but as I couldn't find such a tool, at the end I did a search/replace. It was a small project obviously.
- cobalt 11y ago
  i think that is what postcss does
  - 11y ago

vonklaus 11y ago

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

Lazare 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.

KayL 11y ago

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

hobarrera 11y ago

Previous discussion here: https://news.ycombinator.com/item?id=11409808 https://news.ycombinator.com/item?id=11409808

jtchang 11y ago

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.

jeswin 11y ago
>Best practice would be to use SASS SASS is a personal preference and one of the available options, not a best practice. PostCSS is a great option, with the ability to use upcoming CSS specs in the same way Babel lets you use ES7 on today's JS engines.
deleted 11y ago
[deleted]
spriggan3 11y ago
> Best practice would be to use SASS. Best practice would be to use LESS.
- nailer 11y ago
  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.

tacos 11y ago

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 11y ago
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 11y ago
  You don't often change the values of variables and you're better at regex than most front end engineers?
  - oneeyedpigeon 11y ago
    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 11y ago
      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.

ocfx 11y ago

Clickbait. No valid arguments made.

MichaelBurge 11y ago

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.

tomphoolery 11y ago

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 11y ago
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).

niuzeta 11y ago

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.

grav 11y ago

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

usaphp 11y ago

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.

BinaryIdiot 11y ago
> 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. Honestly depends on how you structure the HTML and CSS. I've worked on some very, very large projects stretching across 15 subcontractors and we did not use css preprocessors. It wasn't even an issue really. CSS is really great at cascading properly. Most of the times I've seen where people want to use variables could have been just as easily accomplished via inheriting from a top level style. But I'm not going to sit here and tell you you're an idiot for using CSS preprocessors. They serve a purpose. They work. Yes they complicate things further but if it helps you deliver faster I'm not going to complain...much :)
- nailer 11y ago
  The general approach without using mixins is creating visual classes, which now means the look of say .login-box is determined in two places : the HTML where .login-box has visual classes added and the CSS for .login-box and whatever the visual classes are.
- Akkuma 11y ago
  I'm hard pressed to believe the quality of the CSS across 15 subcontractors was actually good and consistent. You can't get 5 developers in a room without finding at least a few differences in opinion how something could or should be done and when it comes to CSS you have even more flexibility to how you're writing it and the associated markup. What was done to ensure similarity of HTML/CSS across such a large project?

usaphp 11y ago

Looking at his other articles on his blog I stumbled upon this one: http://www.456bereastreet.com/archive/201304/responsive_drop_shadows/ http://www.456bereastreet.com/archive/201304/responsive_drop... 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 11y ago
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 11y ago
  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 11y ago
    > 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).

jwdunne 11y ago

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.

TamDenholm 11y ago

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 11y ago
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 11y ago
  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".

lowmess 11y ago

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.

__michaelg 11y ago

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 11y ago
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 11y ago
  Why even rely on the machine instruction decoder implemented in your microprocessor? I prefer to hook up ALUs and flipflops manually...

ofir_geller 11y ago

"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.

andrewclunn 11y ago

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.

lowmagnet 11y ago

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.

robertelder 11y ago

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.

websitescenes 11y ago

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.

morrisda 11y ago

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.

floatboth 11y ago

"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.

kabes 11y ago

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?

Tiquor 11y ago

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.