Jump to content

Recommended Posts

Posted

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. 

Posted

That is talking about cssnext and Babel, though, not PostCSS, so not really to the point regarding this topic ;)

Read again :)

Posted

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.

Posted

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.

Posted

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.

Posted

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. 

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...