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

61–70 of 129 posts

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

#61

Post by throw10920 »

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.

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

#62

Post by iaml »

systemvoltage wrote: post #51

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?

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

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

#63

Post by sfvisser »

eatonphil wrote: post #57
sfvisser wrote: post #2

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.

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

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.

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

#65

Post by eatonphil »

sfvisser wrote: post #63
eatonphil wrote: post #57

Earlier quoted context omitted.

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

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.

I write frontend code and backend code and do compiler stuff for fun and I don't find it confusing. "Compiler" means completely separate things in so many contexts that I get the general picture and always need to look deeper to truly understand. Just because it's a generic term doesn't mean anyone should not be allowed to use it IMO.

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

#66

Post by assemblylang »

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…

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

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.

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

#67

Post by no_wizard »

devongovett wrote: post #48
no_wizard wrote: post #43

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

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.

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

#68

Post by devongovett »

jafitc wrote: post #59
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…

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)

Yes, there is a WASM build used by the demo: https://parcel-css.vercel.app

Not sure if we could reuse these packages though, since we'd need to expose an API from Rust to JS anyway.

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

#69

Post by no_way »

tiborsaas wrote: post #40
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.

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

It won't go away, it will still be supported and used for many years, but majority of new projects today won't use it. Brief history: Rollup dramatically improved bundler plugin and ES modules situation, then came new super fast bundlers like Esbuild and finally solutions combining both like Vite. Webpack is still playing catch up with that. There is literally zero reasons to choose clunky, slow Webpack configs, while alternatives exist, unless you have a legacy codebase and migrating is not an option.

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

#70

Post by no_way »

krono wrote: post #39
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.

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…

I have done manual configs from scratch in Rollup, even wrote bunch of plugins for stuff like custom css class minifying and web worker support, so no I don't need handholding :) Setting it all up was even fun, everything was well documented and clear, with Webpack on the other hand, you only have fun if you like pain.
Post reply on HN