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

21–30 of 129 posts

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

#21

Post by CognitiveLens »

dymk wrote: post #15
pastelsky wrote: post #11

Earlier quoted context omitted.

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

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…

I don't get the sense that runtime CSS parsing is really much of a concern - it's more about build speed and asset size - since 'green' might be used hundreds of times in a large CSS bundle, the optimization might make sense even with an imperceptible speed cost in the browser.

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

#22

Post by rattray »

dymk wrote: post #15
pastelsky wrote: post #11

Earlier quoted context omitted.

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

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…

I don't have intuition here, but perhaps transferring two bytes over a slow network takes longer than the string normalization and dictionary lookup?

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

#23

Post by robocat »

dymk wrote: post #15
pastelsky wrote: post #11

Earlier quoted context omitted.

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

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

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

#24

Post by gampleman »

dymk wrote: post #15
pastelsky wrote: post #11

Earlier quoted context omitted.

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

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…

Don’t know, but I wouldn’t be surprised if the browser first tried a dict lookup (which is super fast) and only then tried to actually parse hex the string.

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

#25

Post by aarchi »

> 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

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

#26

Post by chronogram »

rawling wrote: post #13
pastelsky wrote: post #11

Earlier quoted context omitted.

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

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

Ah thanks, I assumed ‘#0f0’ as well. I guess it is length based then.

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

#28

Post by kevincox »

aarchi wrote: post #25

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

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

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

#29

Post by mbb70 »

swagatkonchada wrote: post #27

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?

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

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

#30

Post by ry4nolson »

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

Someone else mentioned this already but "green" is not #00ff00. Tt's #008000.
Post reply on HN