Did you hear about CSS 4?View other answers to this thread
3.4K+ developers have started their personal blogs on Hashnode in the last one month.
Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more
I hope the time of CSS preprocessors is over.
Why? For a couple reasons:
- all CSS preprocessors out there are imperfect in their design, and end up being high-maintenance as time goes on
- people marketing those preprocessors feel they have to lie to convince people to use it
CSS is a language that has a definition of its syntax specified in a document. This means that everything CSS is and does fits within this predefined grammar, and also every new feature that will ever be dreamed up and added to the language will also fall inside of the grammar we can read and use today.
This means if you were setting out to create a CSS preprocessor - you should write something that abides by the same CSS grammar rules so when you add your new features and functionality you can be sure that it won't ever be something that's added to CSS. The key here is that you have to fully support CSS, while claiming to do things CSS will never do.
Most preprocessors get that backward. Most preprocessors don't support CSS's grammar, but rather have a limited ability to parse or read CSS, and rather than trying to do things CSS will never do, most of them claim to let you write things that will someday be in CSS in your code today. This is where all of the problems with CSS processors as we have them today lies.
An example - Sass followers often claim:
- Sass is a superset of CSS (it isn't)
- all valid CSS code can be passed through SCSS (it can't)
One great and recent example was CSS variables, the real kind of CSS variables like
--bg: blue; and
var(--bg). When the people who made SCSS thought of what was valid CSS or wasn't valid CSS, because this wasn't based on CSS's grammar but their understanding (or guesses) at what CSS was, when this feature was first added to CSS it broke SCSS. So they updated it and now it works. Fast forward a year and CSS is in the process of standardizing
max() functions. But SCSS already added their own
min() function to CSS so now you have to pick:
- use SCSS with its
- use CSS with its
You can't do both!
Over time as CSS grows (always within the grammar that has been defined for it) more and more you see preprocessor maintainers having extra work to do just to keep normal, regular CSS from blowing up their compilers and breaking the sites of all of their users. And sometimes, like with
min(), they have already camped on something that eventually ends up in CSS's namespace and now it's incompatible with actual CSS and will be…forever.
So to summarize, preprocessors are (truthfully):
- non-standard CSS-like dialects
- that compile to a subset of CSS features
The sooner people put down their preprocessors, the sooner they'll realize they were doing a lot of extra work (learn non-standard language, run compiler to convert file to another language every time you save before you can preview your work, makes it harder to debug the resulting CSS, etc) to solve problems they think they have…that just actually using vanilla CSS might solve for them without all the extra work.
Thing is all the stuff those preprocessors do there's either ways to do it without them in simpler and easier to follow ways, or even more often the case they're doing stuff that has zero business in the code in the first place.
As I've said many times, most of the garbage preprocessors do I would never see any practical use for on any layout I would even consider deploying. The only way I can fathom people seeing any use to them are those two words I keep overusing: Ignorance or ineptitude.
... and again I don't mean ignorance as an insult, it just means people don't know any better. Like not knowing what's wrong with outright ignorant trash like class="text-center col-x-5 box-shadow" or what's wrong with deploying 100k of markup, 500k of CSS, and 2 megabytes of JS to deliver 5k of plaintext and a half dozen content images... all whilst doing the job of 10k of HTML, 32k (or less) CSS, and 64k (IF ANY) JS.
If you're creating ten times the code resulting in ten times the work, I could see being deluded into thinking that trash made life easier. It didn't, it just encouraged sticking with bad practices and broken methodology, at best sweeping deep rooted issues under the rug.
... and much like front-end frameworks they sure as shine-ola don't make anything easier, or simpler, or "help with collaboration", or "make you more productive".
To be frank, web developers are all the dumber for any of this malarkey even existing.
Sad part is I've seen this before, back in the big iron days where BASIC, Cobol and DiBol developers would just slop together off the shelf code snippets and "boilerplates" they didn't understand and blindly hope things work, then run around crying wah-wah when anything broke. Most always in the long run resulting in more work, more difficulty, and more expense despite the claimed "ease".
Same stupid mistakes based on the illusion of ease, different century.