Why I don’t use CSS preprocessors
456bereastreet.com
456bereastreet.com
[...]
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.
[...]
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 - possibly not strictly true in the literal sense as I still have a soft spot for these sorts of hacks
> 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.
Shit's fast yo.
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 :)
What was done to ensure similarity of HTML/CSS across such a large project?
Quality across more than 1 subcontractor for ANYTHING is rarely good. But the most important thing when dealing with large projects divided with multiple groups? Ownership. You make one group own the design / CSS. Then when others change their CSS it runs through them for reviews but they also supply guidelines for being consistent, etc.
It's almost impossible to handle disparate groups without having centralized owners and people who create guidelines on how to do everything so it's consistent.
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.
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.
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.
If life was fine without preprocessors, then why did they see such rapid adoption?
Using tables for layouts was once state of the art as well with no complaints. Things change, as do best practices. You can use inheritance to reuse values without preprocessors, or you can switch to preprocessors and use variables and mixins for composition. The question of which is better (inheritance vs. composition) is a personal one, I prefer composition.
I'm not arguing for or against CSS preprocessors here. I'm trying to point out that one shouldn't have difficulty imagining coding a site with regular css. It's every bit doable, it has been done widely in the past and it is in fact still done today.
In some cases - perhaps many - it's not ideal, sure. But when OP says that not using these tools is unimaginable, I see that as a lack of effort on his/her part into trying to understand the point of view of the people who don't use them.
If I was a LESS user and somebody said, "I can't imagine a case where you'd want that tool", I would scoff at them because there are plenty of examples out there (and in this thread), and their statement shows that they're really not even trying to understand my point of view.
If they instead said, "I can understand why you think you need that tool, but ..." then I wouldn't have a problem because they have made an effort into understanding my point of view (and they can at least imagine using my workflow in their head, even if they don't like the idea).
This may be pedantic - after reading OP's post again, it seems possible that OP wasn't being literal about the imagination thing. But that didn't occur to me at the time of writing.
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.
We can only say that it's "holding him back" only if we can show that he doesn't get the same results as SASS users, in the same amount of time.
We think your path is the wrong way and will cause you problems as time goes on.
Don't measure experience by how long someone's done things. Measure it by what they've done. It's that old quote about "10 years of experience, or one year of experience repeated 10 years."
I've also been following this individual. I don't tend to agree too much with what he has to say because my experiences are very different.
I met a dev at a meetup the other night as I was giving a talk on Elm. He's been doing web dev almost as long as me. He still does HTML with tables. He uses inline CSS. He's never investigated a preprocessor, and has never looked at Angular, Backbone, or React.
But he's successful, so, shrug.
So be wary of "appeal to authority" arguments. Yes, he's been around a long time. Doesn't mean he's right.
None of us are really right. Just weigh all the opinions and decide based on experience.
I'm too old and tired now to try to convince people I'm right and they're wrong. I'm more interested in saying "I think this is cool and here's why."
For the record, I think Elm is the future and you can pry Sass from my cold, dead hands. Those are just my opinions, and they may change. It doesn't mean anyone who uses jQuery and straight CSS is wrong.
So...a preprocessor? :)
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.
And the OP uses PostCSS. Apparently, a lot of people here didn't read that part...
int one = 2;However, I've seen projects with a few CSS variables defining the base colours for their scheme and perhaps some tints and shades, and then a second layer of variables defined in terms of the base ones but with more role-based names like heading text colours and focused primary button backgrounds and so on. It's a simple, practical model that has proved very easy to work with and in some cases has stood the test of time for quite a few years now.
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.
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...
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.
So first off if you want it to literally be the same then you could do something like:
h1, button {
color: #343434;
}
.primaryColor {
color: #343434;
}
But if you could break my first example apart and set it in two places just as easily. But that's setting it at a high level element itself. You could even go crazier and set EVERYTHING to that color but ultimately many of these decisions have to be context based to decide.
The way I see it, CSS preprocessors allow for code reuse via composition - vanilla CSS restricts you to inheritance.
The actual art of making visuals usable within a screen is pretty hard to make a language out of. With postcss and react css modules there are advancements. And still, it's one of the things that I have to put the least amount of effort in for the most amount of gain.
I already explained this? You set it at the top level. Have a set of top level HTML elements / classes that set all of these defaults. Then everything inherits from those. Only one place to change them.
Not quite: 'color', 'background-color' and 'border-color' are 3 separate properties that can't be be inherited from one place using vanilla CSS
I disagree - as a matter of fact, a lot of CSS frameworks have the concept of a "primary color" that is used in the manner I have described. Additionally,following your idea of DRY would render CSS variables pointless in CSS preprocessors as mixins cover that use-case (setting the same property).
But now your markup is littered with styling classes, and you could end up with a .secondary button with a .primaryColor class.
In vanilla css, the only way to really define something like a primary color just once and have it apply correctly to all elements is to define it at a high level in a deeply nested cascade. This of course all breaks as soon as you add a container element and have to go back and add another level of nesting to your css.
Variables in css should be standard.
I hate, hate, hate having to alter my HTML to apply styles. The idea of
<h1 class="primaryColor">
totally creeps me out. I do it because other people refuse to use preprocessors and think that altering the HTML to include presentational details is fine (see Bootstrap.)
But it still feels gross to me.
To be fair HTML is the presentation. I can understand not wanting to mix business logic from JavaScript into a page but CSS is just the other half of HTML.
If it makes it nicer you could use more generic class terms (such as page information or HTML structure location, etc).
HTML is the content and description of content. You put a <strong> tag around text to make it strong emphasis.
CSS is the presentation. Your browser sees the <strong> tag and applies its default style of making it bold.
This is just incredibly pedantic. For all practical purposes HTML + CSS is the presentation. Toss JavaScript into that if you want. Front-end work is the presentation.
As far as graceful degradation, If I open a properly built page in a text-only browser, there are no styles. There's no real emphasis or bolding. There's just text. Because CSS didn't exist.
Now, if you want to live in the early part of the decade when it was OK to put inline styles and background colors in your HTML, that's fine. But the world evolved beyond that. HTML with <body bgcolor" is deprecated.
Because HTML is the content. CSS is how it looks. And JS is how it works.
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.
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.
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.
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.
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 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).
I could never figure out how to extract a dependency list from SCSS files, though I didn't search for very long.
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.
- e.g. swapping colors requires you to replace with an interim value
- you might miss the one rgba value, because you only replaced the hex or rgb values
- try search + replace for instead of $border-radius-top, when border radius bottom can, but does not have to be set in the same line.
And more:
- browser prefixes
- synchronized animation timing
- split in to files and folder hierarchy, but compiling to one file (also makes git merges much easier)
- and if you have something with mild theme support it's really handy
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.
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.
Best practice would be to use LESS.
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.
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.
Add the output css to source control, now you can always deploy that in an emergency.
You can mitigate #4 and #5 by importing less.js during development. I don't know if SASS has something similar.
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
> 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.
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.
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.
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.
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).
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.