6 ms·

> with many assets being built and minified ... often needlessly and even to the author's own detriment, given the need to configure (and then maintain the con

> with many assets being built and minified ... often needlessly and even to the author's own detriment, given the need to configure (and then maintain the configuration of) the shoddy tooling that produces the blobs--and the inability to debug them directly, of course.

eyelidlessness 4y ago
Minification is good for users in most ways, it’s fewer bytes on the wire and faster to parse. And I know bad tooling and config is the meme but I will say I’ve been pleasantly surprised by how simple it’s been to adopt Vite both in new projects and now a >10 year old one. Edit: I’m just waking up and missed the point about debugging, but source maps work very well. Perhaps more sites should ship them to production though!
- pwdisswordfish9 4y ago
  The key word being "directly". Aside from that, it remains to be shown for most projects that the downsides are outweighed by the upsides (which are often theoretical or aspirational even, rather than actual).
  - eyelidlessness 4y ago
    “Directly” is immaterial if every part of the tool chain supports it transparently. Which granted isn’t a given, but it’s more of a given than being able to directly debug two deep into a vanilla JS Promise.then. As far as what remains to be shown about upsides, smaller JS packages isn’t in question. I don’t even know what resources to link which show this because it’s so fundamental that I wouldn’t know which fundamental to begin with. You’re coming from the perspective of tooling complexity being a large downside (and I agree), but it takes approximately none to minify JS. And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting.
    - pwdisswordfish9 4y ago
      > “Directly” is immaterial if every part of the tool chain supports it transparently. Which granted isn’t a given In other words, it's not immaterial (and even hinting that it might be by introducing the word in the first place is a red herring). > it takes approximately none to minify JS Simply untrue. > And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting. There are two issues here, both of which come down to the fact that the practice of minification doesn't exist in a vacuum: 1. HTTP payload compression is already a thing 2. There's a counterintuitive product of the industry that churns out minified JS bundles, which is that if you look at what people are actually doing, pretty much all these things end up being larger--this is approximately the same as the "low-fat/low-calorie snacks lead to overeating" phenomenon, but there's a fair bit of "lost knowledge/nobody knows how to do this stuff anymore" <https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko> involved, too

eyelidlessness 4y ago

Minification is good for users in most ways, it’s fewer bytes on the wire and faster to parse. And I know bad tooling and config is the meme but I will say I’ve been pleasantly surprised by how simple it’s been to adopt Vite both in new projects and now a >10 year old one. Edit: I’m just waking up and missed the point about debugging, but source maps work very well. Perhaps more sites should ship them to production though!

pwdisswordfish9 4y ago
The key word being "directly". Aside from that, it remains to be shown for most projects that the downsides are outweighed by the upsides (which are often theoretical or aspirational even, rather than actual).
- eyelidlessness 4y ago
  “Directly” is immaterial if every part of the tool chain supports it transparently. Which granted isn’t a given, but it’s more of a given than being able to directly debug two deep into a vanilla JS Promise.then. As far as what remains to be shown about upsides, smaller JS packages isn’t in question. I don’t even know what resources to link which show this because it’s so fundamental that I wouldn’t know which fundamental to begin with. You’re coming from the perspective of tooling complexity being a large downside (and I agree), but it takes approximately none to minify JS. And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting.
  - pwdisswordfish9 4y ago
    > “Directly” is immaterial if every part of the tool chain supports it transparently. Which granted isn’t a given In other words, it's not immaterial (and even hinting that it might be by introducing the word in the first place is a red herring). > it takes approximately none to minify JS Simply untrue. > And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting. There are two issues here, both of which come down to the fact that the practice of minification doesn't exist in a vacuum: 1. HTTP payload compression is already a thing 2. There's a counterintuitive product of the industry that churns out minified JS bundles, which is that if you look at what people are actually doing, pretty much all these things end up being larger--this is approximately the same as the "low-fat/low-calorie snacks lead to overeating" phenomenon, but there's a fair bit of "lost knowledge/nobody knows how to do this stuff anymore" <https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko> involved, too