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.
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.
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.
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.
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.
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:
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.
PostCSS parses CSS, runs plugins and outputs CSS. Yep, of course there is a plugin that does variables! And the "Myth" tool, mentioned in a comment here, is just a pack of PostCSS plugins.
And the OP uses PostCSS. Apparently, a lot of people here didn't read that part...
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.
You're arguing for the sake of it- it was just a bad example. If $red was $leadcolor or something similar, you can define it at the top, comment it to explain what it is, then change it across the whole site in 10 seconds (including the borders which are defined as variables 5% darker and lighter) when the client says "I like it, but the red needs to 'pop' more, do you know what I mean?"
You can write bad code in any language, as the saying goes.
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.
But we've all been in a situation where it's got 'that far' and someone more senior has got involved and done exactly that. Plus, it makes designing in the browser waaaay easier.
Have you never implemented a design yourself, and then found that when you looked at the results as a whole, it didn't work quite as well as you hoped from the original concept work?
Have you never A/B tested a site and found that varying colours made a difference?
Have you never developed a site with some colour scheme and later found you needed to extend the colour scheme, perhaps to incorporate a new product or service being added to the available range?
Having a colour scheme that is set in stone early on sounds like one of those idealised things that sometimes just doesn't work in the face of reality.
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...
> 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.
I am no expert in css but let's say you have a title heading color and you want the button color to be the same as that. You need to specify it separately in 2 places right ?
No but ultimately specifying it in two places could be better.
So first off if you want it to literally be the same then you could do something like:
h1, button {
color: #343434;
}
That would make them the same. You could also do
.primaryColor {
color: #343434;
}
Then set the elements which should have a primary color with that class.
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.
What if want to use the primary color as the background-color to a nav element and as the border-color to inputs and textareas as well? If the designer changes to a different shade, do you do a global search-and-replace?
The way I see it, CSS preprocessors allow for code reuse via composition - vanilla CSS restricts you to inheritance.
Css is quite frankly bullshit (ie. fickle), but I'm proud of it.
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.
> What if want to use the primary color as the background-color to a nav element and as the border-color to inputs and textareas as well? If the designer changes to a different shade, do you do a global search-and-replace?
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.
Those are three different ways of coloring something (and very rarely are exactly the same in my experience). Using variables to make those three the same color is an abuse of DRY in my opinion.
> Using variables to make those three the same color is an abuse of DRY in my opinion.
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).
> Then set the elements which should have a primary color with that class.
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.
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.)
> 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).
They're both the presentation. Showing emphasis and structuring content is as much part of the presentation as CSS, maybe even more so if you care about backwards compatibility and graceful degradation.
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.
It's not pedantic. It's the way it was designed. Just because people use tables for layout doesn't mean they were intended for that.
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.
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
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
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.
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.
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.
I use browsersync all the time, it's a great tool, but IMHO it's still much more hassle then just live editing css in chrome devtools and then having the browser save the changes to local css files directly. No need to reload anything, you just save it and you are free to continue working... of course, sass has many other benefits, it's a way easier to manage, but with devtools pure css workflow is nowadays really fast and streamlined, too.
Are you using libsass or ruby sass? I work with a 10k loc monstrosity that took 4s+ to compile in ruby and it now takes 3~400ms to compile in watch mode, with all the overhead from Grunt & autoprefixer added.
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.
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.
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.
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.
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.
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.
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).
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.
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 :)
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.
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?
> 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.
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.
> 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.
I don't think that is OP's point here. Just because something works doesn't mean you should not improve it. You might get habituated with regular css. But things improve SO much when you use pre-processors.
> 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.
If life was fine without preprocessors, then why did they see such rapid adoption?
Why did NoSQL, programming language of the week, etc. see such rapid adoption before they died out again / moved back to their specialist niches? Shiny new toys, everyone loves them. For a while.
> But site admins got along fine, and I certainly didn't hear many complaints.
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 think my point was missed by most of the replies to this comment. That's likely my fault - I should have been more explicit:
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'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.
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.
Experience seems to be what's holding him back in this case. I've always done it this way soo... As developers and engineers, we have to be ready to change our assumptions and workflows to adapt to new technology.
There is no argument. Simple facts. Plain CSS is monolithic and hard to maintain. Disprove it if you want but I think you'll be hard pressed. This author did not succeed.
You presume that he needs to change but give no reason to do so other than you think your way is better. He says his is better and a lot of people, including myself and a well-publicized recent article, feel the same way.
We think your path is the wrong way and will cause you problems as time goes on.
Speed, maintainability, modularity and readability are all good reasons. I'm sure that there are many more reasons but these are just off the top of my head.
I've also been doing things on the web since 1995.
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.
Nothing you said matters cause it has nothing to do with what I was replying to. I was replying to the statement that he "lacks experience" and that is far from the truth.
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.
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.
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.
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).
If a customer is still using IE8 I am positive that he will be OK with not seeing a box shadow on an element, and making 95% of other clients suffer and download images for generating box shadow is just plain stupid for me. I would either ditch those 5% of clients and focus on better features than spending lots of time on restraining cool functionality in order to satisfy a 5% of users on IE8
> making 95% of other clients suffer and download images for generating box shadow is just plain stupid for me.
The images are likely a few hundred bytes if you do it right. Regardless this is an old article you dug up just to attack the guy; OBVIOUSLY it's far less relevant today than it was when it was originally written.
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.
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.
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".
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.
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.
There was a span of a year or two when I could literally write 68000 machine code by hand, without needing an assembler, due to an obsession with sprite blitters culminating in a bit of code which would generate arbitrary custom blitmask functions as part of the image-loading process. I had very little understanding of "abstraction" at the time, so it pretty much just built instructions from the bits up via shift and mask operations. I would never do anything like that now[1] - but I'll always be proud of the day I dropped into Macsbug, picked out a section of memory, wrote myself a minimal Tetris implementation, moved the PC (aka IP register) into it, and played. It crashed, of course, but the fact that it even sort of worked felt pretty good.
1 - possibly not strictly true in the literal sense as I still have a soft spot for these sorts of hacks
126 comments
[ 1.8 ms ] story [ 224 ms ] threadI 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.
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.
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.
http://caniuse.com/#feat=css-variables
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...
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:
That would make them the same. You could also do Then set the elements which should have a primary color with that class.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.
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
> 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.
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.
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
You can mitigate #4 and #5 by importing less.js during development. I don't know if SASS has something similar.
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 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.
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.
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.
[1] http://caniuse.com/#search=%3Aafter
[2] http://caniuse.com/#search=box-shadow
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.
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.
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.
[...]
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] http://www.cosmacelf.com/
1 - possibly not strictly true in the literal sense as I still have a soft spot for these sorts of hacks
Add the output css to source control, now you can always deploy that in an emergency.