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...
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.
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.
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.
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)
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"?
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
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.
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 nearly didn't look at this because I didn't want another javascript dependance in my pipeline.
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.
