Hot off the presses from Devon Govett, creator of Parcel, is Parcel CSS:
A CSS parser, transformer, and minifier written in Rust.
Nice. The CSS world could use a little processing shake up like this.
Ya know how esbuild has seriously shaken things up for the JavaScript processing world? Maybe we need a cssbuild? It would process imports and do bundling (something we generally rely on Sass for). The point would be extreme speed. Maybe it would be plugin-based and compatible with the PostCSS API so that existing PostCSS plugins would work on it. Maybe it could make sourcemaps and do modification. Maybe it would run your Sass, too, I dunno. But something to spark the CSS ecosystem like that could be cool.
Close! It looks like it doesn’t do bundling (standalone anyway). I suppose it would have to just invent a syntax for that, as I think Sass somewhat regrets the ambiguity of how it uses @import just like native CSS does and I wouldn’t blame anyone for not wanting to go down that road. It’s tricky territory, for sure, as inventing syntax kinda puts it into a different category of tool. I think it would be worth it though, as breaking up CSS into smaller files but bundling them in development is like… a thing people do, and I could see really wanting to use this without having to necessarily commit to Parcel (which can bundle).
So why run your CSS through this thing? From the docs, it looks like you’d wanna do that because…
- it’s a minifier,
- it does vendor prefixing,
- it can process as CSS modules (the classic library, not the native ones), and
- you get sourcemaps.
(Originally, I thought it leveraged other tools for these tasks as tools like Autoprefixer and cssnano appeared in the project’s package.json file, but as the comment below from Devon confirms, Parcel CSS is a replacement for these, it doesn’t use them.)
But there is one more! Seems to me the killer Parcel CSS feature is what they are calling “Syntax lowering” meaning you can use “future” CSS today (like, say, nesting) by having it processed down to things that browsers understand, like Babel does in JavaScript. It feels similar in spirit to postcss-preset-env.
And crucially, it’s fast:
Will Parcel CSS become an ecosystem?
So I guess the big question is: If Parcel CSS becomes the CSS parser of choice, will we get plugins? And if we do, will it become a robust ecosystem like PostCSS plugins?
Parcel CSS is a replacement for cssnano, autoprefixer, and postcss-preset-env. It does not use them. The dependencies you saw in package.json are dev dependencies for testing, benchmarking, and generating data about what prefixes are needed for what browsers (we reuse autoprefixer’s data, but not its implementation).
Impressive! Will update the post to be clear about that.
That is indeed the idea behind Sass’s new module system with
@useand@forward.Oooh… this is interesting. Been using Parcel 2 for a while now, and I love it.
Question:
I’ve just read the docs about Parcel transformer setup.
Will this work with Sass (.scss) files, or just raw CSS?
Yes it works. SASS will be compiled to CSS first (included in the default Parcel config), and then run through the CSS pipeline you’ve configured there.
Thanks Devon… that’s great news!
I can now hopefully discard some explicitly defined PostCSS plugins.
Nice! It’s really exciting to see this step forward in CSS tooling. Really excited to see where it goes and how it progresses.
I too had the question at the end of the article though. At the end of the day, I can’t see this becoming the next PostCSS. Their approach of focusing on a parser/AST tool, making it as fast and friendly as possible, then letting plugins handle the mutations seems like the right one for an ecosystem.
Hopefully Parcel CSS moves this direction. While Parcel CSS definitely has the big four equivalents built-in (Autoprefixer, cssnano, postcss-modules, and postcss-preset-env), it’s missing out on an entire catalog of other enhancements. Further, what if I want to exchange built-ins? There’s a lot of competition in the css minifier tooling arena for example… what if I want to swap out parcel’s minification for one with a smaller output?
Sure, I can turn off parcel’s minification and run my CSS through an additional Node AST/tool like PostCSS.. but that really starts to water down the benefit of using Rust doesn’t it? If I have to parse my CSS in Node… it might as well start there too and then I can eliminate a dependency.
None of the above is to downplay the accomplish of the tool. It’s really exciting (at least to me) to see the first major WASM-powered CSS AST tool. And hey… if we absolutely must have a plugin chain, there’s nothing stopping anyone from building their own on top of the Parcel CSS parser… though I’d obviously love that OOTB ;)
Great work Devon (and team)!!!!