Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

parceljs.org

Post reply on HN
Print view View original

81–90 of 129 posts

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

#81

Post by dfabulich »

no_wizard wrote: post #67
devongovett wrote: post #48

Earlier quoted context omitted.

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 wil…

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.

For a spec about a browser feature, "getting it" can mean a few different things.

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

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

#82

Post by zelphirkalt »

saint-loup wrote: post #80
zelphirkalt wrote: post #78

Earlier quoted context omitted.

I am more talking about "Only ever include the CSS rules we need." instead of "Lets take the whole of bootstrap! Oh damn, we have to somehow reduce it!". 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…

From the Parcel CSS page : it does 'tree shaking', which automatically eliminates unused code. Not details on what that implies, though. Tools like PurgeCSS (used by Tailwind pre-v3) comb through the HTML for matching selectors, but I'm not sure if Parcel does the same thing. Anyway, as others comments said, these kind of tools nowadays are more 'transformers' than mere 'minifiers'.

That's really nice, but to me still sounds like the wrong way to go. Instead of reducing something that is too much, that which is too much should not have been added in the first place. We are doing work here, removing, what we have previously added.

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.

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

#83

Post by chrismorgan »

robocat wrote: post #23
dymk wrote: post #15

Earlier quoted context omitted.

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' p…

More importantly, I would expect #00ff00 to compress better than green, because it would usually make the CSS file more predictably repetitive. Reducing network bytes is usually very important for speeding up loading (at least it is in the boondocks of the internet - out at the rim of the world).

A related thing that I realised a few days ago about compression algorithms:
Compress these with gzip, and the first is smaller than the second (56 and 58 bytes): lowercase doctype because you’re using very few uppercase letters in your document (on slightly larger samples it tends to save a byte or two), and omit the quotes as unnecessary. On larger documents there will be some places where you need quotes around attribute values, but it’s still worth omitting them when you can.

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.

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

#84

Post by spartanatreyu »

pferdone wrote: post #45
no_way wrote: post #20

Earlier quoted context omitted.

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.

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.

The problem with using something like webpack is that you can't use it for something quick.

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.

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

#85

Post by crehn »

pastelsky wrote: post #11
chronogram wrote: post #9

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

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

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

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

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

#86

Post by feupan »

mikepurvis wrote: post #41
kevincox wrote: post #28

Earlier quoted context omitted.

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

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;…

The bigger win here are projects that increasingly do more and do it faster. You can essentially replace babel’s hydra with typescript (single dependency) and do it faster too. TS also essentially supports “preset-env” via the target property (however you must pick the ES version, not a browser list)

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”)

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

#87

Post by amw-zero »

zelphirkalt wrote: post #72

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…

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

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

#88

Post by ianschmitz »

samhuk wrote: post #50
TameAntelope wrote: post #16

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

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

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

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

#89

Post by ajxs »

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.

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

#90

Post by genuine_smiles »

throw10920 wrote: post #61

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…

> Rust tooling is rather suboptimal

In what way? People seem to really like cargo.

Post reply on HN