5 ms·
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
by 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 ago28ms 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 agoWho 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 agoIf 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 agoHm, so you think it's better to calculate response time than to measure it as a way of tracking this important metric?
- boredtofears 4y agoWhy would those things be mutually exclusive?
- Zetice 4y agoWhich, of the two, would be more accurate and relevant to users? Do users care about an estimated 27ms increment that they objectively cannot notice, or the overall measured response time?