What do you think about PostCSS?

[tenhobi]

Well, what do you think about PostCSS?

A lot of people say "write future CSS" and the post-processing itself is mentioned like the sentence, but if you look at the plugins, a lot of them are written like for pre-processor use, which is kind of strange...

What do you like (and do not like) about the idea of PostCSS compared with Sass?

Do you think about move to PostCSS?

[KittyGiraudel]

Hey Honza.

As far as I can tell, PostCSS is just an engine to post-treat stylesheets, in the way that it doesn't do anything in itself, until you start using plugins. Some of them are really handy, such as Autoprefixer. I feel like this is typically the kind of scenario where post-treating CSS makes sense. Same goes for rem-ifying, at least in some cases.

Now regarding using PostCSS or cssnext as a replacement for Sass in my daily workflow, I don't see it happening soon. For starters, PostCSS would not solve any problem that Sass doesn't solve for me yet so no need to change something that works fine. All in all, I believe postprocessors and preprocessors basically solve the same problems, so using one or the other doesn't make much difference at the end of the day. I am just used to Sass, that's as simple as that.

Secondly, there are things that I don't like about polyfilling the future CSS syntax: it cannot be done. At least not efficiently. The whole idea behind this comes from Babel and other JavaScript transpilers, polyfilling future JS syntax with JavaScript. Then people thought “let's polyfill future CSS syntax with JavaScript as well”. Unfortunately it is not that simple and more often than not it cannot be done at all.

The thing is, CSS is heavily related to context. The same code snippet will have a completely different impact depending on the DOM structure, the browser, and a couple of other factors. That means you cannot really understand CSS outside of the browser rendering frame. Because of this, you cannot truly polyfill future syntax with JavaScript. Because it's not JavaScript that is needed to do so; it's a rendering engine. Take calc(100% - 200px) for instance. Only the browser is able to compute the resulting value, because it knows how to convert 100% in pixels.

Now, CSS variables. They cannot be polyfilled with JavaScript. Because they are not CSS variables. They are custom properties. The strength of this feature is not to avoid a search and replace like preprocessors variables. The strength of CSS CP is to follow the cascade, to be inherited, to be updated on-the-fly, and so on. PostCSS and the like polyfill what they can of the spec of Custom Properties; which is not only a very fraction of it, but also —I believe— extremely misleading.

Some developers using PostCSS without being very aware of the specifications of the Custom Properties are likely to believe that they are just variables, because that's basically what PostCSS can offer from the spec. And they will probably never know there is so much more to them than avoiding to perform a search and replace in the IDE when changing a value. In that way, I wonder whether it actually helps the community. I believe I prefer no polyfill than a half-baked one, but that's probably only my opinion.

Anyway. I like the idea, but I think we are pushing it too far, where it doesn't belong. And when you think about it, preprocessors do not really have this problem, as people know that Sass/LESS/Stylus syntax is proprietary, features are proprietary and this is not going to be implemented as is in the CSS language. Nobody will ever be confused about the mixin directive or the dollar variables. They are Sass features, working as intended per Sass documentation. No surprise.

I don't like surprise. Especially in my code.

[tenhobi]

Very nice answer. :+1:

And I like Sass because of its abstract layer above CSS where I can do magic. :smile_cat:

[jacquesletesson]

Amazing answer!

PostCSS performance could be a huge asset for large scale project, don't you think?

https://github.com/postcss/benchmark#preprocessors

[chriseppstein]

:+1:

[hedgerh]

@jacquesletesson I ran postcss benchmarks a couple of months ago and libsass was actually only 1.5 times slower. The strange part was that I even stepped back a few versions in libsass, and didn't even come close to matching the 3 to 4 times speed boost that they're reporting with postcss. I thought that was kind of strange.

[MoOx]

Some notes:

• "post-process"ing/sor is not used by community anymore. (eg: last update https://github.com/postcss/postcss/pull/450)
• plugins that transform some "w3c syntax" to more compatible css never mention the word "polyfill" (because like you said, it doesn't make sense to use this). cssnext just aim to provide a future proof syntax & (even with the known limitations) does this like a charm (a code that you write today might also work in the browser (if browser support current state of the specs)).
• performance benchs are not relevant (yet) since postcss doesn't handle imports for example (and so, postcss + postcss-imports + some plugins might not be faster at all. This will require a more serious work with a "fair" comparison.

[benjamminf]

My issue with implementing future syntax is that it's definition is not finalised and therefore subject to change in the future. This means your "future-proof" processed CSS might not be future-proof after all. This is a maintainability nightmare - CSS based on a syntax that never technically existed! Whereas Sass has a well defined syntax that isn't going anywhere.

[soniar4i]

I was wondering if you still think the same about PostCSS

[KittyGiraudel]

Hey.

Kind of. I am still not sure polyfilling non-polyfillable specifications with JavaScript (PostCSS here) is a good idea. Might be just confusing for some people.

That being said, PostCSS is now so much more than a polyfill for future CSS syntax. This would rather be cssnext I suppose. PostCSS on the other hand provides direct access to the CSS AST and makes it possible to manipulate it through JavaScript. That is incredibly powerful.

I can see PostCSS becoming the base of any tailored and efficient CSS pipeline, the way Babel tries to be the platform for modern JavaScript development. I believe they both operate along the same lines, and so far it has proven to work well.

I am slowly moving away from Sass. Not because I don’t like it, but because I am getting more and more conservative about my way of using it, and try to stick to CSS as much as possible, avoiding over-engineering and too many layers of abstractions.

I find CSS scoping issues and the fact that it operates in a global namespace much more problematic than repetitive code (cleaned up with Sass mixins and @extend).

[soniar4i]

Thanks Hugo.

I'm a bit overwhelm by how fast everything is evolving nowadays.