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.
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.
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.
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
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.
> 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 :)
> 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.
The author has been a well known, though low key, source since I began in 2004 and I've been following him since. His about page says he's been developing for the web since it began so, no, he does not lack experience.
I've written CSS for over 10 years, and I don't use preprocessors at all. I've written small web pages, e-commerce sites, enterprise applications with tens of thousand users. And I find it really offending that you think this is because of lack of experience.
I don't care about mixins, variables, a few instances of duplicated code and my clients doesn't care about any of the code under the hood. In fact they care about time to market, and that is something I am exceptionally good at in my area.
In fact variables has always been possible with multiple class names.
The discussion about what we should choose between traditional CSS, SASS and LESS is on the same level as what color the bike shed should have. http://bikeshed.com/
Pick one and be happy, neither is better or worse. When you're building web applications, CSS is least of your problems.
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.
> Variables though, I can't see how you can go without them.
The point of variables is to allow the setting of one style property and applying it to others, right? So why not just to that at the top level element and inherit it down? Typically you only want to select a handful of colors for a web site / application so simply set those at the highest level possible then allow CSS inheritance to work.
Out of all of the big projects I've been on only one has used CSS preprocessors and I've never run into an issue with needing to change a value in too many places. It doesn't seem all that hard to avoid if I'm being honest here it just really, really depends on the structure of your CSS and HTML.
Yeah this is the one that I don't understand, his argument about wet css being more readable doesn't even make sense in the case of "#ec3f5d" vs "$red", let alone the fact that in a big project not having one place to change this can be a nightmare.
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.
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:
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.
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.
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.
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.
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.
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.
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).
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 and i can't figure out lasting about 1 second to compile.
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.
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.
"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.
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.
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.
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.
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.
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.
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?
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|10 years ago|reply
[...]
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|10 years ago|reply
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/
[+] [-] Lazare|10 years ago|reply
> 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|10 years ago|reply
[+] [-] usaphp|10 years ago|reply
[+] [-] BinaryIdiot|10 years ago|reply
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 :)
[+] [-] wallacoloo|10 years ago|reply
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.
[+] [-] toomanythings2|10 years ago|reply
[+] [-] olavgg|10 years ago|reply
I don't care about mixins, variables, a few instances of duplicated code and my clients doesn't care about any of the code under the hood. In fact they care about time to market, and that is something I am exceptionally good at in my area.
In fact variables has always been possible with multiple class names.
The discussion about what we should choose between traditional CSS, SASS and LESS is on the same level as what color the bike shed should have. http://bikeshed.com/
Pick one and be happy, neither is better or worse. When you're building web applications, CSS is least of your problems.
[+] [-] PaulB_GD|10 years ago|reply
[+] [-] BinaryIdiot|10 years ago|reply
The point of variables is to allow the setting of one style property and applying it to others, right? So why not just to that at the top level element and inherit it down? Typically you only want to select a handful of colors for a web site / application so simply set those at the highest level possible then allow CSS inheritance to work.
Out of all of the big projects I've been on only one has used CSS preprocessors and I've never run into an issue with needing to change a value in too many places. It doesn't seem all that hard to avoid if I'm being honest here it just really, really depends on the structure of your CSS and HTML.
[+] [-] myblake|10 years ago|reply
[+] [-] j4kp07|10 years ago|reply
[+] [-] ino|10 years ago|reply
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.
[+] [-] nostrademons|10 years ago|reply
http://caniuse.com/#feat=css-variables
[+] [-] robertelder|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] Bahamut|10 years ago|reply
[+] [-] ehnto|10 years ago|reply
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.
[+] [-] tomphoolery|10 years ago|reply
[+] [-] tracker1|10 years ago|reply
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|10 years ago|reply
[+] [-] txutxu|10 years ago|reply
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).
[+] [-] yoavm|10 years ago|reply
[+] [-] morrisda|10 years ago|reply
[+] [-] tacos|10 years ago|reply
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|10 years ago|reply
[+] [-] floatboth|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] spriggan3|10 years ago|reply
Best practice would be to use LESS.
[+] [-] jwdunne|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
[+] [-] kyriakos|10 years ago|reply
[+] [-] justinlardinois|10 years ago|reply
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|10 years ago|reply
[+] [-] lowmess|10 years ago|reply