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 min() and max() functions. But SCSS already added their own min() function to CSS so now you have to pick:

• use SCSS with its min() function
• use CSS with its min() function

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.

Honestly a lot of the stuff being added is stuff I have zero use for, and would advise people not to use because it is the same broken garbage as what CSS pre-processors do. It makes CSS more difficult to use, difficult to maintain, and difficult to work with.

But there's as much useful stuff -- and in that way the splitting the specification into "modules" as they have makes a good deal of sense. Hence why the "CSS Level 4 Selectors Module" is the only one approaching real world deployability whist much of the other modules are for all intents and purposes stillborn.

I love many of the new selectors. A good number of the CSS3 selectors moved a lot of what we had to use JS for that really should have been none of its business back into the HTML and CSS, The new "Level 4 Selectors" continue this trend with range and validity, whilst at the same time reducing even further the need for classes and ID's by giving you even more control via combinators, structural, and so forth.

On the other hand things like :scope just encourages people to ermagahd aherpaderp the STYLE tag into their BODY where it has zero blasted business ever being in the first place! Seriously, I truly believe the STYLE tag should be deprecated! Seriously it has no reason to even exist, and anyone telling you to use it probably doesn't understand enough HTML, CSS, or networking to be flapping their trap on the subject... I don't care if even Google Pagespeed is telling you to do it, it's stupid for so many reasons!

But every one of the modules is a mixed bag like that, following in HTML 5's footsteps of both offering improvements, but in many ways also flipping the bird at good practices, separation of presentation from content, accessibility, and even the intent/reason HTML exists and why CSS is separate from it. Again reeking more of HTML 3.2 / mid '90's browser wars mentality than it does anything to do with trying to make the creation of websites simpler and easier, or making the results more accessible to everyone.

Could be worse though, could be the nightmare of XML trash that is currently being labeled by some as HTML 6, dragging us even further down the road of "just slop more code in there any-old-way, who gives a flying purple fish about accessibility or logical document structure much less making things simpler/easier/better".

One step forward, two steps back.

But that's like the idiocy of CSS preprocessors which IMHO serve zero legitimate purpose if you understand even the most basic concepts of what HTML is, what CSS is, what they are for, and how to use them properly. They create an illusion of "ease" whilst making people work harder, not smarter.

With most of what they do, and indeed much of what is worming its way into certain Level 4 modules, adds nothing of value to the web development process.

Pre-processors, front end frameworks, visual editing -- all half-assed nonsense that cannot die out soon enough for my tastes. At best they thrive in a world of ignorance, at worst they are outright predatory scams! They actively encourage bad practices and methodologies better off left in the 1990's. You want to write your website that way you might as well go back to writing HTML 3.2 with tables for layout and presentational tags/attributes, pretending HTML 4 Strict and CSS never even existed.

That's how backwards what such so-called "shortcuts" are in mindset and methodology.

Don't use sass/less for long time and I do use "CSS 4" with PostCSS+CSSNext. It's like babel for CSS. I just convert future/very new CSS into CSS3 for all platforms.

Apart from that there is also a CSS Houdini.

So, preprocessors won't be needed at all, they are not really needed even today.

#VanillaCSS

They will survive.

I think the goal of CSS preprocessors was to help in writing CSS code. And the later in future, new problems will arise, which I guess they will try to solve.

I think the most basic features of these preprocessors are still their proprietary.

In that context, have you tried PostCSS?