Parcel CSS: A new CSS parser, compiler, and minifier(parceljs.org) |
Parcel CSS: A new CSS parser, compiler, and minifier(parceljs.org) |
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/
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.
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.
Most of CSS OM is already implemented in Javascript which can come in handy for this project:
https://github.com/jsdom/cssstyle
(both of which jsdom use internally. cssstyle is a kind of updated version for some parts of CSSOM)
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.
Well, Bootstrap 5 is ~200K when not minified and a web site usually ships additional CSS resources as well.
I'm really not sure.
[0] https://www.goodreads.com/book/show/52320048-abstracting-awa...
> 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.
> 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.
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
[0] https://www.npmjs.com/package/node-sass [1] https://www.npmjs.com/package/sass instead
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...
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.
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.
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
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.
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...
I mean, if using js/ts is not beneath you I'm pretty sure any css-in-js solution fits the bill.
Fantastic work, I believe cssparser could benefit from Parcel CSS if they contributed back.
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.
In what way? People seem to really like cargo.
Cargo being good is necessary, but not sufficient.
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.
But "#0f0" is fewer letters than "green"?
I nearly didn't look at this because I didn't want another javascript dependance in my pipeline.
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).
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.
What a weird thing to say. I feel like people say this because they don't understand it's uses, and it's versatility.
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.
That'd be my recommendation to you, still, sadly.
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.
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.
So, Esbuild for 'no configuration' as it is significantly faster than Parcel and Webpack for more complex stuff.
The important part now is ensuring that these projects don’t just die and disappear like, say, Rich Harris’ “buble” tool (a very old “fast Babel alternative”)
1. Understanding the purpose of the feature ("why/when would I use this?")
2. Understanding how to implement the feature
3. Understanding how to use the feature
4. Understanding the feature's "corner cases" (surprising implications, cases where it doesn't do what you'd expect, etc.)
5. Understanding why the feature works the way it does (instead of some other way)
Most of the web specs really only explain how to implement a feature, and even then, they're not great at that, because they do such a poor job at explaining the purpose of the feature.
Assuming that you, like most of us, aren't working on implementing a browser, that means that web specs are mostly unhelpful to you. It's almost completely beyond the purpose of a spec to teach you how to use a feature, what its corner cases would be (which are often unknown at the time a spec was written), and why the specification says what it says.
This is an area where the web spec community has made some improvements in recent years. Nowadays, it's understood that new proposed specifications shouldn't just provide a specification, but also a separate "explainer" document to explain the purpose of the feature, and also persuade the other browser vendors to implement the feature. ("This will be really cool, and here's why…")
At a minimum, specs nowadays often include a non-normative "Motivation" section, as the CSS Nesting spec does. https://www.w3.org/TR/css-nesting-1/ I you'll find that you can "get" that spec much better than you can the CSS OM spec https://www.w3.org/TR/cssom-1/ which is old enough to buy alcohol and doesn't include a "Motivation" section.
You can often find explainer docs linked off of https://chromestatus.com/ e.g. https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/... I think you'll find that explainers are 10000% better for learning features than specs are. (They typically even discuss #3, #4, and #5, as they typically discuss alternative rejected approaches.)
https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecim...
Not sure if we could reuse these packages though, since we'd need to expose an API from Rust to JS anyway.
Sadly in my use case it is not a dependency conflict, but I'm failing to replicate it (and actually not even trying very hard). I guess it will automagically fix itself on some minor update.
You can't dip into the documentation for the one thing you're trying to do, you have to spend time reading a large chunk of the documentation, then going to forums and such to try an understand the history of how that one thing you're trying to do has changed over webpack's history.
Then 5 months later when you're doing it for another project, you have to re-read all that documentation again because one other thing is different.
Compare that waste of time and effort to:
A developer is now unavailable and you are taking over the project. The project uses a modern build-system/module-loader/etc... You need to change one thing to the way to project is built.
You don't have to learn an uber nested spaghetti config file that looks like a domain-specific language. You just read the miminal configuration the previous developer left you and now you know what to change, or how to add the one thing you need to do. You've now saved days of work.
I just replaced Webpack with Vite, in a 2yo React project, with relatively standard webpack config (scss, fonts, assets copying, minify etc). I was able to remove 24 total devDependencies packages, including the whole of babel and its related ones, bunch of webpack plugins that broke our build on every packages upgrade (e.g. to Webpack 4, then again for Webpack 5) etc etc.
We now have nothing to do with babel, hard-to-understand plugins that someone added since it was solving a build error, nothing to do with webpack, just 1 almost non-existent config file, instant HMR, and 3x faster build...
You were meant to rely on sourcemaps to get something on your debugger, but despite using the latest Chrome and developer tools at the time, I could never get it to work to actually debug sites.
I know Rollup, Vite and etc had a much easier time providing an easier developer experience because they rely on the browser's native ESM support, but I never could understand why webpack decided to mangle the code so badly.
The confusing part is not calling this process compilation, the confusing part is now calling something a compiler for which the consensus previously was calling it a pre-processor. Now I started to wonder if there is something new that I wasn't aware off, like a browser support optimized binary style format that we can compile into.
<!doctype html><meta charset=utf-8>
<!DOCTYPE html><meta charset="utf-8">
LZMA, similar: 60 and 63 bytes.
But then compress these with Brotli, and it’s the other way around by a larger margin, 29 and 19 bytes, because Brotli ships a dictionary primed on arbitrary web content. And so it becomes a popularity contest, and an inferior but vastly more popular technique compresses better.
In the case of #008000/green/#00ff00/#0f0/lime/#ffff00/#ff0/yellow, the dictionary doesn’t look to bee tainted, so traditional length and repetition wisdom still applies.
A minimizer should care a lot abut size. I'm not sure what would be faster, but the difference must be minimal anyway, so it's safe to focus on your default concern.
This is an interesting premise, do you know of any tools that optimize web pages for parsing and rendering speed as opposed to size? I wrote a tool once that bundles and archives webpages for offline viewing, and in those cases network throughput is not an issue since files are stored locally. It could be interesting to see what performance benefits I might be able to get from optimizing for parsing speed in this case, although I suspect the performance differences will be so negligible that it won't make much of a difference. Still would be an interesting experiment nonetheless.
That depends entirely on your definition of “magic”. Needing a specific incantation of seven different plugins and rules, that are often conflicting and incomprehensible, to get a basic project to build, is the same as magic to me.
I assume you mean magic == conventions or implicit behavior. I’ll take that over the Webpack mess any day.
Neither of which are necessarily negatives of course!
Only thing is that for every minute gained from those speedy rust builds, I lost five more on debugging stuff that used to work fine with Babel + having to learn this new language to write replacements for now unsupported plugins :)
Until you eject a CRA :)
One such process is what you're commenting on here in this thread.
If memory serves me right, you could compile the Bootstrap library and choose the parts you needed. Not sure if that is still true for Bootstrap 5. If it is not possible, it stands to reason, that perhaps one should not use Bootstrap 5 and instead write good styling oneself, without all the stuff, that will never be used on the site anyway.
CSS can be tricky, but in the end, reasonable styling is usually not that hard to do. Even responsiveness can be done mostly without media queries these day, unless you want content to change, if layout changes. It used to be much harder, when our browser standards were not that far. Nowadays we have flex and grid and more standardized interpretations of CSS rules in browsers. We can make navigations, menus, tiles and whatever all responsive without that much work put in.
Anyway, as others comments said, these kind of tools nowadays are more 'transformers' than mere 'minifiers'.
Yes there is:
Tailwind actually has its own jit compiler for development since the old, full css was extremely long. Windi always creates small css as far as I remember.
I wonder how much ineffective styling still remains after "tree shaking". I guess the fancy tree shaking is out of luck, if we add unnecessary styling to elements, which are indeed used. It seems a really hard problem to solve automatically, to transform CSS in a way, that takes care of redundancies and unnecessary styling, while still maintaining the readability, which well crafted CSS can have.
The problem is, with CSS you don't know if you've added too much. As the project evolves, and code and styles change there's literally no way of knowing if a certain CSS rule is still in use Well, except regexp'ing the whole project looking for matches.
That's basically what these tree-shaking tools do.