3 ms·

Speed brings value. Loading dash without optimizing it carries a huge weight. Weight can slow down users. Users leave the cart before completing a purchase. Lo

Speed brings value. Loading dash without optimizing it carries a huge weight. Weight can slow down users. Users leave the cart before completing a purchase. Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`. On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just: https://github.com/angus-c/just https://github.com/angus-c/just

Zetice 4y ago
> Loading dash without optimizing it carries a huge weight. This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
- boredtofears 4y ago
  It's not that small: https://bundlephobia.com/package/lodash@4.17.21 https://bundlephobia.com/package/lodash@4.17.21
  - Zetice 4y ago
    Per your citation, at 875 kB/s it takes 28ms to download. I'm gonna leave that in the "small" category for now, considering 516.25 kB/s is about what Cuba averages on mobile, ranked last in the world. [0] [0] https://www.speedtest.net/global-index https://www.speedtest.net/global-index
    - boredtofears 4y ago
      28ms isn't small trade-off if you're pulling it in for a one off utility function. Not calculating these types of trade-offs is exactly how you run into mammoth bundle sizes when you're a year or more into development.
      - Zetice 4y ago
        28ms is a small trade off. Sorry, but it is, and this is exactly my point; you don't have to give a hoot about 28ms and you can still be a very effective developer. In fact, I find it hard to think of an effective software dev who does care about 28ms without having specific reason to, due to a niche use case (not a generic web app for Internet things, like a hospital instrument that needs every ms).
        boredtofears 4y ago
        ..and when you've added a couple dozen of these you're sitting at half a second. Indeed, I guess we just develop different classes of applications. I don't know what a "generic web app for Internet things" is.
        Zetice 4y ago
        Who here is suggesting you add a "couple dozen" of dependencies like this? And you're on a "generic web app for Internet things". This page loading 27ms slower would not be perceptible.
        boredtofears 4y ago
        If you're not evaluating every package you're adding to your manifest how would you prevent that scenario from happening? Personally I've never worked at a product where response time wasn't an important metric.
        Zetice 4y ago
        Hm, so you think it's better to calculate response time than to measure it as a way of tracking this important metric?
        boredtofears 4y ago
        Why would those things be mutually exclusive?

Zetice 4y ago

> Loading dash without optimizing it carries a huge weight. This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.

boredtofears 4y ago
It's not that small: https://bundlephobia.com/package/lodash@4.17.21 https://bundlephobia.com/package/lodash@4.17.21
- Zetice 4y ago
  Per your citation, at 875 kB/s it takes 28ms to download. I'm gonna leave that in the "small" category for now, considering 516.25 kB/s is about what Cuba averages on mobile, ranked last in the world. [0] [0] https://www.speedtest.net/global-index https://www.speedtest.net/global-index
  - boredtofears 4y ago
    28ms isn't small trade-off if you're pulling it in for a one off utility function. Not calculating these types of trade-offs is exactly how you run into mammoth bundle sizes when you're a year or more into development.
    - Zetice 4y ago
      28ms is a small trade off. Sorry, but it is, and this is exactly my point; you don't have to give a hoot about 28ms and you can still be a very effective developer. In fact, I find it hard to think of an effective software dev who does care about 28ms without having specific reason to, due to a niche use case (not a generic web app for Internet things, like a hospital instrument that needs every ms).
      - boredtofears 4y ago
        ..and when you've added a couple dozen of these you're sitting at half a second. Indeed, I guess we just develop different classes of applications. I don't know what a "generic web app for Internet things" is.
        Zetice 4y ago
        Who here is suggesting you add a "couple dozen" of dependencies like this? And you're on a "generic web app for Internet things". This page loading 27ms slower would not be perceptible.
        boredtofears 4y ago
        If you're not evaluating every package you're adding to your manifest how would you prevent that scenario from happening? Personally I've never worked at a product where response time wasn't an important metric.
        Zetice 4y ago
        Hm, so you think it's better to calculate response time than to measure it as a way of tracking this important metric?
        boredtofears 4y ago
        Why would those things be mutually exclusive?