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

121–129 of 129 posts

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

#121

Post by rhengles »

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.

One thing that always put me off about webpack is the default way it compiles your code. One of the ways is(was?) compiling code as _eval_(!!) statements and code as string. It is absolutely impossible to debug such code.

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.

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

#122

Post by throw10920 »

genuine_smiles wrote: post #90
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.

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.

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

#123

Post by yencabulator »

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?

#080 is #008800, not #008000.

https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecim...

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

#124

Post by wbolster »

jacobp100 wrote: post #120
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…

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

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

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

#125

Post by apatheticonion »

danielskogly wrote: post #110
apatheticonion wrote: post #105

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

`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

Well I'll be...

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

#126

Post by selcuka »

dmitriid wrote: post #100
zelphirkalt wrote: post #82

Earlier quoted context omitted.

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, whic…

> that which is too much should not have been added in the first place. 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.

> regexp'ing the whole project looking for matches

That's basically what these tree-shaking tools do.

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

#127

Post by lenkite »

danielskogly wrote: post #110
apatheticonion wrote: post #105

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

`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

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

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

#128

Post by jbergens »

zelphirkalt wrote: post #75
selcuka wrote: post #74

Earlier quoted context omitted.

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

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.

You can switch to WindiCSS or Tailwind and use the optimized output. That is usually a lot shorter.

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.

Post reply on HN