5 ms·

While weight is a factor in professional car racing, and while I've built a go-kart that is significantly lighter in weight than a professional racing car, it i

by hug 7y ago

While weight is a factor in professional car racing, and while I've built a go-kart that is significantly lighter in weight than a professional racing car, it is not a particularly impressive achievement that I have managed to do so, and I wouldn't think to criticize a race team for the weight of their vehicle.

andrewzah 7y ago
Good thing we’re discussing JavaScript library sizes and not cars in random contexts, then. 77kb gzipped is massive considering it’s only doing one thing. If I want my website to load in ~100 milliseconds or less (or even 1 second or less!), I absolutely do need to pay attention to all the libraries I add. I can and do criticize software developers for making hideously bloated websites because they don’t pay attention to what they add. Not only are a lot of modern websites wasteful, they’re painful or outright useless on slow mobile connections—not a problem for software developers on fibre networks, beefy dev machines, etc.
- hug 7y ago
  So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.
  - pier25 7y ago
    You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.
    - hug 7y ago
      I am most assuredly not missing the point. Your use-case is not my use-case. I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Also, my go-kart also gets more miles to the gallon than NASCAR team cars.
      - pier25 7y ago
        > I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Fair point but you have to admit that is a very niche use case. Have you compared the execution to native performance? Even decoding a 50MB JPEG in Chrome with turbojpeg is going to be a hard pill to swallow.
        hug 7y ago
        I do know it's a niche use case. And I for sure wouldn't recommend that every man and his dog use the polyfill. I'm not even sure it's right for the scenario I'm thinking of. But I can definitely contrive a case where it is. I haven't benchmarked this specific thing, because I've never used it. But I might, because it sounds like a fun thing to do.
thanatropism 7y ago
Go home, GPT-2, you're drunk.
- forgottenpass 7y ago
  underrated comment
bawolff 7y ago
If we are in the space of compression than i think its relavent.

by hug 7y ago

andrewzah 7y ago

Good thing we’re discussing JavaScript library sizes and not cars in random contexts, then. 77kb gzipped is massive considering it’s only doing one thing. If I want my website to load in ~100 milliseconds or less (or even 1 second or less!), I absolutely do need to pay attention to all the libraries I add. I can and do criticize software developers for making hideously bloated websites because they don’t pay attention to what they add. Not only are a lot of modern websites wasteful, they’re painful or outright useless on slow mobile connections—not a problem for software developers on fibre networks, beefy dev machines, etc.

hug 7y ago
So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.
- pier25 7y ago
  You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.
  - hug 7y ago
    I am most assuredly not missing the point. Your use-case is not my use-case. I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Also, my go-kart also gets more miles to the gallon than NASCAR team cars.
    - pier25 7y ago
      > I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Fair point but you have to admit that is a very niche use case. Have you compared the execution to native performance? Even decoding a 50MB JPEG in Chrome with turbojpeg is going to be a hard pill to swallow.
      - hug 7y ago
        I do know it's a niche use case. And I for sure wouldn't recommend that every man and his dog use the polyfill. I'm not even sure it's right for the scenario I'm thinking of. But I can definitely contrive a case where it is. I haven't benchmarked this specific thing, because I've never used it. But I might, because it sounds like a fun thing to do.

thanatropism 7y ago

Go home, GPT-2, you're drunk.

forgottenpass 7y ago
underrated comment

bawolff 7y ago

If we are in the space of compression than i think its relavent.