Jonathan Lahijani Posted August 9, 2015 Posted August 9, 2015 I'm currently reading up on PostCSS, which seems to be the future of CSS pre-processors (it's actually a "Post" Processor). https://github.com/postcss/postcss Anyone else using it?
Beluga Posted August 10, 2015 Posted August 10, 2015 Yes, I've used it (as a "consumer"). I have mentioned this in a thread about grid systems before: https://github.com/corysimmons/lost Here is a recent article introducing the system: http://davidtheclark.com/its-time-for-everyone-to-learn-about-postcss/ 1
diogo Posted August 10, 2015 Posted August 10, 2015 I think this opinion by Chris Coyier is quite to the point https://css-tricks.com/the-trouble-with-preprocessing-based-on-future-specs/ 1
Beluga Posted August 10, 2015 Posted August 10, 2015 I think this opinion by Chris Coyier is quite to the point https://css-tricks.com/the-trouble-with-preprocessing-based-on-future-specs/ That is talking about cssnext and Babel, though, not PostCSS, so not really to the point regarding this topic
LostKobrakai Posted August 10, 2015 Posted August 10, 2015 I'm not sure, but if I understand the PostCSS thing right, than it's just a css parser per se and nothing more. So one can really only evaluate the use-cases for it's plugins. I've yet to grasp why so many people think this is different to other preprocessors except for the fact it's more customizable.
diogo Posted August 10, 2015 Posted August 10, 2015 That is talking about cssnext and Babel, though, not PostCSS, so not really to the point regarding this topic Read again
teppo Posted August 10, 2015 Posted August 10, 2015 I've yet to grasp why so many people think this is different to other preprocessors except for the fact it's more customizable. Isn't that alone pretty big difference? Modularity is the key argument for PostCSS, and unless I've missed something big time, that's a feature none of the "typical CSS (pre)processors" provide. This is why comparing PostCSS to typical preprocessors seems kind of pointless; they're entirely different types of beasts. If their benchmarks are anywhere close to truth, it seems more like this could be a suitable platform for rebuilding some of the current preprocessors. I've been using the Ruby SASS compiler for a while now, and that, at least, is painfully slow. @diogo: Unless I'm missing something here, Chris Coyier mostly discusses alternative/future CSS syntax in his post. That's an extremely valid point, but it's not yet an argument against (or for) PostCSS. PostCSS, like LostKobrakai pointed out above, is essentially a CSS parser with plugin support, and it's entirely up to you (and other devs) what the plugins you build/install actually do.
LostKobrakai Posted August 10, 2015 Posted August 10, 2015 Isn't that alone pretty big difference? Sure, but from some blogposts one could think this is the new holy grail, but it still has all the problems of other preprocessors in terms of providing new alternative syntaxes to writing css. The speed issue is so true, even libsass is sometimes quite slow, couldn't work with the ruby one anymore.
Beluga Posted August 10, 2015 Posted August 10, 2015 Read again Chris's article is about potential problems arising from the use of future syntax with the help of transpilers and preprocessors like Babel and PostCSS. It's not like one has to use cssnext, when starting to use PostCSS. I have never used it myself. I know how the CSS spec process goes and decided I wasn't interested in learning a moving target syntax. I have, however, used plugins to get Sass-like useful functionality: simple vars, mixins, nested.
Adam Kiss Posted August 12, 2015 Posted August 12, 2015 If their benchmarks are anywhere close to truth, it seems more like this could be a suitable platform for rebuilding some of the current preprocessors. I've been using the Ruby SASS compiler for a while now, and that, at least, is painfully slow. Libsass + sassc for the win, man.
Recommended Posts