Parcel CSS: A new CSS parser, compiler, and minifier

This is amazing! Seen a lot of work around Rust and JS &#x2F; JSX &#x2F; TS &#x2F; TSX (notably SWC[0] is moving to be a Rust based version of Babel) not so much around CSS.<p>My genunine hope is this will replace PostCSS sooner rather than later. PostCSS isn&#x27;t the most performant thing I&#x27;ve worked with, and a lot of plugins for PostCSS rely on doing multiple passes at the AST, they can slow down significantly as a result<p>For that however, we will need some kind of plugin system. I know the SWC[0] project has had some struggles with this as their current JS API relies on serializing the AST back and forth. I wonder if this forgoes a JS API entirely or if that is something planned for say 1.5?<p>[0]: <a href="https:&#x2F;&#x2F;swc.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;swc.rs&#x2F;</a>

When a site&#x27;s CSS is well written, with a capable web developer knowing, what they are doing, such a tool would not be necessary. People pump out megabytes of JavaScript, but then they worry about a few kilobytes of CSS being saved by compressing it, at the same time making it less readable by minifying it. (We are not yet shipping hundreds of kilobytes of CSS, are we?!)<p>When there is a need for a tool that minifies CSS, then people seriously need to ask themselves, how it can be, that they have that much CSS. How much redundant CSS can you accumulate? Was there no coherent styling idea or strategy, so that every thing on the page needs separate styling?<p>What many forget is, that data is often sent gzip compressed anyway, which naturally takes advantage of repeated parts to compress. Text usually compresses pretty well. Especially something like a description language with many repeating parts. It is great, that Parcel CSS is faster than some other tool. However, for me, these kind of tools are merely treating the symptoms of not doing styling properly. I&#x27;m glad, that I got to know the web, when you simply could look at all the source of a page and learn from it, instead of facing a multi megabyte &quot;minified&quot; script and &quot;minified&quot; CSS.

What does it mean to compile CSS? Pack multiple files into one? Resolve and inline variables? Convert nested rules into flat CSS? Something else?<p>I&#x27;m really not sure.

Looking forward to an scss compiler written in Rust, compiled to wasm and exported via a node module that no longer requires node version&#x2F;platform specific binaries to be either downloaded or compiled.<p>Oh cool: <a href="https:&#x2F;&#x2F;github.com&#x2F;connorskees&#x2F;grass" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;connorskees&#x2F;grass</a><p>Oh node-sass is written in C++. I wonder why they aren&#x27;t shipping the code as wasm rather than using node bindings

I was just looking at Parcel a week or so ago to replace the stagnated Snowpack project for our frontend.<p>Should I just stop trying to avoid it and just use Webpack 5, or can I actually rely on Parcel in a way I couldn&#x27;t Snowpack?<p>I just want to bundle my React app, I&#x27;m not trying to do anything special...

&gt; Parcel CSS is based on the cssparser[0] Rust crate, a browser-grade CSS tokenizer created by Mozilla and used in Firefox. This provides a solid foundation, including tokenization and basic parsing. However, it does not interpret any CSS properties or at rules. That&#x27;s where Parcel CSS comes in. It handles parsing each individual rule and property value, as well as minification, compilation, and printing back to CSS.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;servo&#x2F;rust-cssparser" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;servo&#x2F;rust-cssparser</a>

I feel stupid asking this question, but isn&#x27;t the browser that parses css? i understand minifying css, but what does parcel&#x27;s css parsing refer to?

It would be really great for me if any of these CSS preprocessors offered a standalone command line version that didn&#x27;t need npm to install. My developer blog (<a href="https:&#x2F;&#x2F;ajxs.me" rel="nofollow">https:&#x2F;&#x2F;ajxs.me</a>) is built by a homegrown static-site-generator built in Python, which reads data from a simple SQLite database. I&#x27;ve been looking for a suitable CSS preprocessor for a while, however the ones I can find are all totally overcooked for my needs, and nearly exclusively designed to be integrated with Node.js.

For some reason I trust minifier &#x2F; compiler benchmarks way more than I trust DB benchmarks. I wonder why that is?<p>Maybe I expect DB workloads to be much more varied so benchmarks are less representative. Whereas with minifying you can run it against some large project and expect it&#x27;ll reflect your real world experience

Is it just me or parcel is starting to lose focus and performance?<p>Back in the v1 days, things just worked without config and with v2, I need some config and even basic glob pattern to include all files in a directory is now a plugin and for some reason a parcel process takes 3GB of memory to compile a smallish project and I don&#x27;t know how to fix it or pinpoint what the cause is.

Unrelated but regarding SCSS&#x2F;SASS: I am curious, why did we invent a new syntax for scss instead of writing a library in Python or Go that maps data-objects to CSS classes? You have full access to a proper programming language instead of this new DSL we need to learn. I tried searching for it but no luck, any reason why we don&#x27;t do this?

Outside, didn&#x27;t read yet. Does minification include summering? Like if a child has an attribute that it actually doesn&#x27;t need because it will inherit anyway since it is on the parent too, we can remove that attribute and save a line. Does it make sense?

The syntax lowering and modules handling might be really nice. Maybe even the tree-shaking. Minification, thought, especially with this level of parsing, just seems like an elaborate waste of effort if the web server is set to gzip the final CSS file, anyway.

&quot;Parcel CSS is based on the cssparser Rust crate, a browser-grade CSS tokenizer created by Mozilla and used in Firefox.&quot;<p>Fantastic work, I believe cssparser could benefit from Parcel CSS if they contributed back.

After I saw the title, I thought &quot;oh, it seems to kind of occupy the same space as esbuild, but for CSS. I wonder if the devs gave any thought to performance?&quot; Then I clicked the link and saw that there a <i>direct comparison</i> with esbuild, with Parcel being 3x faster on a large real-world benchmark (Bootstrap 4).<p>This is really impressive. Although Rust tooling is rather suboptimal, Rust <i>programs</i> seems to have quite the performance edge. I&#x27;ll take the RESF any day as long as it means getting away from ultra-heavy webtech everywhere.

I hope this can support SugarSS or other indented syntaxes easily. As far as I can tell, you&#x27;d still need to slap in PostCSS to transform to CSS first which defeats the purpose. Semicolons and brackets, like with JSON, make for a condense format for compressing but have an awful writing experience and contribute nothing to readability.

Parcel is a great project that has made it much quicker to develop a SPA. This only furthers my sense of joy for it.

Very nice! Always great to see these new tools, especially if they can speed up build times.

In the playground, why does ‘yellow’ get converted to ‘#ff0’ but ‘green’ remains ‘green’?

It is supporting glob patterns?

That’s awesome, great job!

Why is a product written in Rust have “JS” (javascript) in its URL name?<p>I nearly didn&#x27;t look at this because I didn&#x27;t want another javascript dependance in my pipeline.