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

by Lapz • 5 years ago

345 122 5 years ago

sfvisser4• 5 years ago

What does it mean to compile CSS? Pack multiple files into one? Resolve and inline variables? Convert nested rules into flat CSS? Something else?

I'm really not sure.

JonathonW• 5 years ago

In addition to minification, Parcel CSS handles compiling CSS modules, tree shaking, automatically adding and removing vendor prefixes for your browser targets, and transpiling modern CSS features like nesting, logical properties, level 4 color syntax, and much more.

codebeaker• 5 years ago

Had you taken the time to open the link, the 2nd paragraph states their capabilities succinctly:

Parcel CSS has significantly better performance than existing tools, while also improving minification quality. In addition to minification, Parcel CSS handles compiling CSS modules, tree shaking, automatically adding and removing vendor prefixes for your browser targets, and transpiling modern CSS features like nesting, logical properties, level 4 color syntax, and much more.

sfvisser4• 5 years ago

I've obviously read that. Most of those features are what we used to call CSS pre-processors, but I'll happily call that compilation if that's a thing now.

have_faith• 5 years ago

It's in the first couple paragraphs

Parcel CSS handles compiling CSS modules, tree shaking, automatically adding and removing vendor prefixes for your browser targets, and transpiling modern CSS features like nesting, logical properties, level 4 color syntax, and much more.

emrah• 5 years ago

Its GitHub repo calls it a "transformer" rather than a compiler.

https://parceljs.org/features/plugins/#transformers

eatonphil3• 5 years ago

Elitism about the term "compiler" aside, I've been reading through The History of the FORTRAN Programming Language and funnily enough compile in those historic CS contexts just meant what "to compile" means in English: merging things together. It's an interesting read whatever the case.

[0] https://www.goodreads.com/book/show/52320048-abstracting-awa...

sfvisser4• 5 years ago

This is not about elitism about terminology, but about sloppiness in using well established words in a specific context to mean something new. It happens rather frequently in the frontend world - which I’m sometimes a part of - and it’s incredibly confusing to all of us.

dgellow• 5 years ago

That’s awesome, great job!

chronogram2• 5 years ago

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

pastelsky• 5 years ago

Because the hex for green (#00ff00) needs more letters than using the named color.

rawling• 5 years ago

Wouldn't that shorten to #0f0? But "green" is #008000, which doesn't shorten?

dymk• 5 years ago

That's an... interesting optimization, and one that might make sense if you only care about byte size, but intuition (which might be wrong!) tells me that this will be more expensive (especially if it saves only one or two bytes).

I'd bet that browsers can more quickly parse a string like '0x00ff00' into its internal color representation than it can parse the string 'green'. It's probably faster to check for a '0x' prefix and convert hex-encoded ASCII to u8 values, than it is to normalize the string & do a lookup in a dictionary of 147 CSS3 color names, when taking into account the extra two bytes that need to be transferred.

crehn• 5 years ago

Because the hex for green (#00ff00) needs more letters than using the named color.

But "#0f0" is fewer letters than "green"?

TameAntelope• 5 years ago

I was just looking at Parcel a week or so ago to replace the stagnated Snowpack project for our frontend.

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't Snowpack?

I just want to bundle my React app, I'm not trying to do anything special...

CognitiveLens3• 5 years ago

Parcel has been around for awhile, and the project currently has a lot of activity - I've made the call to migrate an old create-react-app project to Parcel 2 and in general it is going well.

The nice thing about Parcel is that it is intentionally low-config with relatively intuitive defaults, which tells me that it wouldn't be terribly difficult to move to a different bundler in the future. Webpack has gotten better, but you can quickly end up with a _lot_ of Webpack-specific config that makes future migrations hard.

That said, optimizing for future migrations shouldn't generally be your #1 priority - I also like Parcel's speed, and new things like ParcelCSS just validate that further.

no_way3• 5 years ago

Use Vite instead, it has very nice developer experience. Webpack is a "legacy" bundler, while it is supported, is shouldn't really be used in new projects if you really value your sanity.

krono3• 5 years ago

Webpack is under active development though, nothing legacy about it as far as I'm aware. Are you referring to abandoned third-party plugins maybe?

Vite and all the other bundlers are really awesome, but Webpack's strenght - and I think this may also be the root of the issues you seem to be having with the tool - is that there's almost no magic and barely any handholding. Freedom and reliability at the cost of having to build your own configuration (it's just dumping plugin config objects in an array, really not difficult).

tiborsaas2• 5 years ago

Webpack is a "legacy" bundler

How did you end up with this assessment? I'm not a fan either, but it's still very popular, I doubt it will go away in the next 5 years.

pferdone• 5 years ago

I seriously don't get the hatred Webpack receives. Calling it legacy when it introduced stuff like module federation is unfair to say the least. Just because a lot of people use CRA or some "zero config" bundler, or because esbuild etc are picking up momentum, doesn't mean it's bad. The documentation is actually really good IMO.

nicoburns• 5 years ago

I'd argue that Vite's still pretty immature. It's great if you can stick within what works with it, but webpack is still the gold standard in terms of compatibility and features, and I suspect that will be the case for another couple of years while the native code bundlers (esbuild, swc, etc) catch up with their JS counterparts.

TheFragenTaken• 5 years ago

Webpack is a "legacy" bundler

What a weird thing to say. I feel like people say this because they don't understand it's uses, and it's versatility.

nawgz• 5 years ago

Snowpack, ESBuild, ..., all promised us nice frontend compiles, yet I still turn to Webpack every time I actually want everything to work - you always hit roadblocks you can't solve in these other tools.

That'd be my recommendation to you, still, sadly.

omnimus• 5 years ago

Not my experience. Both esbuild and vite have been great for my usecases.

armchairhacker• 5 years ago

I recommend Vite. I use ESBuild in some libraries but it has a learning curve. Vite's experience is similar to Webpack.

01acheru3• 5 years ago

Parcel is becoming my go-to choice most of the time now. I’ve migrated some apps out of CRA, pure Webpack and Snowpack to it and I need to say it was incredible.

Some minor issues with HMR on one of those projects I still can’t figure out. Anyway having something that works, with JSX, with TS, really fast, in just 2/3 really simple steps is amazing! You don’t even need to turn your brain on.

My two cents.

CognitiveLens3• 5 years ago

Just a stab in the dark, but I was having HMR issues as well and it turned out to be an obscure transitive dependency conflict - details and solutions here on the outside chance it's the same thing affecting your project https://github.com/parcel-bundler/parcel/issues/6685

ReleaseCandidat• 5 years ago

I used Parcel for about a week a month ago. Couldn't get the HTTPS server to use my certificate and key and would have needed to write a plugin so that it wouldn't rename favicons and delete files not mentioned in the HTML file.

So, Esbuild for 'no configuration' as it is significantly faster than Parcel and Webpack for more complex stuff.

samhuk2• 5 years ago

I have been using esbuild for a while, and I can say that it's looking like a huge improvement over webpack, snowpack, vite, etc.

I made a web app starter that uses esbuild to bundle a react-redux app [0] and my experience was very positive of the bundler.

[0] https://github.com/samhuk/tree-starter

ianschmitz• 5 years ago

Vite and snowpack are built on top of esbuild, so I’m not sure your comment makes sense.

aarchi• 5 years ago

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'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.

https://github.com/servo/rust-cssparser

kevincox• 5 years ago

It's really nice to see browser components being able to be reused easily rather than a bunch of half-assed parsers.

hinkley• 5 years ago

Agreed. If cssparser blows chunks on your css then at least you know that will probably break some of your user agents too, rather than the game of “is my tool broken or am I?”

mikepurvis• 5 years ago

Nice too that it's a compiled language, so you get the end tool in a nice static binary. As a non-Node dev, I hate the experience of hacking on some project and having to install a giant pool of NPM stuff just to run some minifier or linter. Hound is an example of this— the guts of the project are golang, but it has a frontend that uses webpack, jest, etc: https://github.com/hound-search/hound

Which is fine, I guess; definitely use the right tool for the job. And maybe Node developers hate finding my Python projects and needing to set up a virtualenv to run them in. But all the same, I approve a direction where more of this kind of tooling is available without a build-time Node dependency.

swagatkonchada• 5 years ago

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

mbb70• 5 years ago

It parses the css so it can improve the minification, for example converting 'margin: 4px 4px 4px 4px' into 'margin:4px'

yosamino• 5 years ago

To do the job of minifying, this minifyer first reads the CSS file into an internal datastructure. That process is called parsing.

All the minifying operations are done on that internal datastructure.

Then it writes it out again into a textfile, ready for the browser to parse it again - hopefully the minifying step made it a bit easier for the browser to parse this minified CSS.

mekster2• 5 years ago

For packages that have images and css, it reads css and extracts image files to be bundled.

habitue• 5 years ago

For some reason I trust minifier / compiler benchmarks way more than I trust DB benchmarks. I wonder why that is?

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'll reflect your real world experience

no_wizard2• 5 years ago

This is amazing! Seen a lot of work around Rust and JS / JSX / TS / TSX (notably SWC[0] is moving to be a Rust based version of Babel) not so much around CSS.

My genunine hope is this will replace PostCSS sooner rather than later. PostCSS isn't the most performant thing I'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

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?

[0] https://swc.rs/

devongovett3• 5 years ago

Hi, author of Parcel CSS here.

I have been thinking about implementing the CSS OM spec as the JS API. This is the same API that browsers expose for manipulating stylesheets. The advantage of this is that we don't need to invent something custom. Still thinking through options. https://github.com/parcel-bundler/parcel-css/issues/5

That said, I think I'd want to keep the use cases for JS plugins limited, because it will affect performance significantly. So, if it's something that exists in an official CSS spec somewhere (even if draft), or a really common transformation, it should be implemented in Rust. An example of this is the support for the CSS nesting spec. Ideally, we'd try to keep the amount of custom syntax being invented around CSS to a minimum and stick to standard CSS syntax wherever possible though.

andrei_says_• 5 years ago

Does this include dart scss processing?

jafitc• 5 years ago

Is this something that can run in browser Workers via wasm or other means?

Most of CSS OM is already implemented in Javascript which can come in handy for this project:

https://github.com/NV/CSSOM

https://github.com/jsdom/cssstyle

(both of which jsdom use internally. cssstyle is a kind of updated version for some parts of CSSOM)

no_wizard2• 5 years ago

Separate question, that may be seemingly unrelated however I'm curious.

How did you kinda "learn" how to read these specs effectively? I can read them, and I think I can reasonably understand them, however I feel like I have little confidence in saying yes I get this.

Is there anything you point to that helps? Tips or recommendations?

I'm trying to learn how to parse these standards docs better myself.

systemvoltage• 5 years ago

Unrelated but regarding SCSS/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't do this?

eatonphil3• 5 years ago

It's called interoperable css [0] or css modules [1].

[0] https://github.com/css-modules/icss

[1] https://github.com/css-modules/css-modules

iaml• 5 years ago

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?

I mean, if using js/ts is not beneath you I'm pretty sure any css-in-js solution fits the bill.

klabb3• 5 years ago

I can't speak for all features in SCSS/SASS. I'd prefer JS (for reusability) to Python, Go and DSLs, but why open Turing complete Pandoras box in the first place when declarative works so incredibly well?

Regular CSS didn't have variables for a long time, which was the killer use case imo. I haven't been in the loop for a while but just found out that there is a CSS Custom Properties[1] standard which would solve most of my use cases. Heck, they're even scoped! Imo front-end folks have an unhealthy low threshold for taking on dependencies that are already supported natively, imo.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

tiffanyh• 5 years ago

Why is a product written in Rust have “JS” (javascript) in its URL name?

I nearly didn't look at this because I didn't want another javascript dependance in my pipeline.

hbn• 5 years ago

It seems Parcel CSS is a project from the creators of Parcel JS, which is a build tool. The URL isn't linking to the top-level page on the domain

Semiapies• 5 years ago

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.

assemblylang2• 5 years ago

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

throw109202• 5 years ago

After I saw the title, I thought "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?" Then I clicked the link and saw that there a direct comparison with esbuild, with Parcel being 3x faster on a large real-world benchmark (Bootstrap 4).

This is really impressive. Although Rust tooling is rather suboptimal, Rust programs seems to have quite the performance edge. I'll take the RESF any day as long as it means getting away from ultra-heavy webtech everywhere.

genuine_smiles• 5 years ago

Rust tooling is rather suboptimal

In what way? People seem to really like cargo.

throw109202• 5 years ago

The Rust compiler is both dog-slow and massive (both from a source and binaries perspective), and doesn't have a working incremental compilation mode yet, or support in-process hot-patching. There's no Rust REPL (hacks like papyrus don't count). Poor structural editing support. Integration with various editors/IDEs is lacking (e.g. there's no support for reporting possible performance issues with code constructs in any editor that I'm aware of, nor is there in-editor per-function disassembly or LLVM IR inspection, or borrow-checker lifetime annotation, no extract-function refactoring).

Cargo being good is necessary, but not sufficient.

davidhariri• 5 years ago

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

zelphirkalt4• 5 years ago

When a site'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?!)

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?

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'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 "minified" script and "minified" CSS.

selcuka3• 5 years ago

We are not yet shipping hundreds of kilobytes of CSS, are we?

Well, Bootstrap 5 is ~200K when not minified and a web site usually ships additional CSS resources as well.

zelphirkalt4• 5 years ago

Oh my ... Does one need all of that? Isn't there a process of reducing it to only what one needs? I think there was something like that in the past. Not sure how well that works.

amw-zero• 5 years ago

This is not a good argument, because no matter how well you write anything, reducing its size is beneficial for everyone.

datagram• 5 years ago

As someone who regularly adds custom CSS to sites to fix various UI issues/annoyances, I can say that I'm definitely not a fan of minified CSS classes.

jacobp100• 5 years ago

What a load of crock. You should always use a css minifier to - at minimum - remove white space and trailing semicolons.

wbolster• 5 years ago

i doubt there's a noticeable difference after applying any "dumb" file compression scheme, e.g. brotli/gzip

mrwnmonm2• 5 years ago

Outside, didn't read yet. Does minification include summering? Like if a child has an attribute that it actually doesn'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?

mrwnmonm2• 5 years ago

Summarizing*

ajxs• 5 years ago

It would be really great for me if any of these CSS preprocessors offered a standalone command line version that didn't need npm to install. My developer blog (https://ajxs.me) is built by a homegrown static-site-generator built in Python, which reads data from a simple SQLite database. I'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.

toastal• 5 years ago

I hope this can support SugarSS or other indented syntaxes easily. As far as I can tell, you'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.

AbuAssar2• 5 years ago

"Parcel CSS is based on the cssparser Rust crate, a browser-grade CSS tokenizer created by Mozilla and used in Firefox."

Fantastic work, I believe cssparser could benefit from Parcel CSS if they contributed back.

devongovett3• 5 years ago

We actually already have! I contributed hwb() color support as part of my work on Parcel CSS, and it shipped in Firefox 96! https://github.com/servo/rust-cssparser/commit/62d63fea751df...

AbuAssar2• 5 years ago

Wonderful, thanks for your contributions!

apatheticonion2• 5 years ago

Looking forward to an scss compiler written in Rust, compiled to wasm and exported via a node module that no longer requires node version/platform specific binaries to be either downloaded or compiled.

Oh cool: https://github.com/connorskees/grass

Oh node-sass is written in C++. I wonder why they aren't shipping the code as wasm rather than using node bindings

danielskogly• 5 years ago

`node-sass` is deprecated [0]. use the `sass`[1] package instead

[0] https://www.npmjs.com/package/node-sass [1] https://www.npmjs.com/package/sass instead

apatheticonion2• 5 years ago

Well I'll be...

lenkite• 5 years ago

Actual source language is dart and this library is basically a transpilation of: https://sass-lang.com/dart-sass

mekster2• 5 years ago

Is it just me or parcel is starting to lose focus and performance?

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't know how to fix it or pinpoint what the cause is.

MartinPL• 5 years ago

It is supporting glob patterns?

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

Related Stories