TrySound@brillout one more binary increases install size though
patak@trysound @brillout IIUC @daniel said that @devongovett will implement the same scheme as esbuild where you only download the binary you need for your platform. So the size increase isn't that bad. And this will probably be opt-in at first.
Devon Govett@patak @trysound @[email protected] @daniel I believe this was about the watcher. Lightning CSS is already distributed per-platform. The binary size did increase a bunch when we added custom transform support. I debated that here: https://twitter.com/devongovett/status/1599101826338459649
If that’s a problem for Vite we could make a lightningcss-lite build without it, but would be a bit unfortunate not to support plugins.
Devon Govett on Twitter
“How much do you care about npm install size? I'm considering adding a feature to lightningcss, but it would significantly increase the binary size. Should I add it to the main package, or release a separate package that you'd use instead if you wanted to use this feature?”
@devongovett @trysound @brillout @daniel Oh, yes, I got these mixed up. Not bad that so many parts of parcel may be used by Vite that I get to confuse them.
Agreed about plugins. The size increase would be considerable though. We are at 3.11MB publish size and 14.6MB install size in Vite. I think it would be ok if this is optional. It is the same kind of tradeoff we have with plugin-react (using babel) and plugin-react-swc.
https://packagephobia.com/result?p=vite
Agreed about plugins. The size increase would be considerable though. We are at 3.11MB publish size and 14.6MB install size in Vite. I think it would be ok if this is optional. It is the same kind of tradeoff we have with plugin-react (using babel) and plugin-react-swc.
https://packagephobia.com/result?p=vite
@patak @trysound @[email protected] @daniel yeah I guess they aren’t really comparable because Vite doesn’t have postcss-preset-env built in. That’s 4.7 MB too. Harder to split a binary up into multiple packages unfortunately. I can look again to see what optimizations are possible though.
l'm wondering why binaries are getting so big. Not specific lib but fundamentally. Maybe compiler includes too much of stdlib? Or there is additional instrumentation added to compiled object.
@trysound generally you can either optimize for speed or size, but it’s hard to optimize for both. When optimizing for speed, there is more inlining, and generics are monomorphized, meaning there is more duplication. This makes a big difference for performance but at the cost of size.
Joe Sweeney@devongovett @trysound This is basically just a bigger bundle for dev only, right? If it doesn't create (much) bigger bundles in prod, I'd say its bigger size is a good trade-off to get more performance.
@devongovett @trysound Ah okay, well my point still stands then 😁
@trysound fwiw, here's the real-world difference for lightningcss:
opt-level=3 (current, optimizing for speed): 7.1MB, minify bootstrap in 4.6ms
opt-level=z (optimizing for size): 3.5MB, 10.9ms
so about half the size, but over 2x slower.