5 ms·

I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 30

I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant. I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't address any of that.

Sujan 8y ago
Why and how are the suggested alternatives worse regarding the aspects you mentioned?
phaedryx 8y ago
Yeah, I don't understand why comparisons are always made for gzipped code sizes. I mean, I could write something really small that is difficult to parse and abuses memory vs. something big but is all comments. Why is this the first metric that is always trotted out?
- k__ 8y ago
  Guess you have to measure yourself then :)
- owenversteeg 8y ago
  Because it's a simple, universal metric. Accurately stating the the performance impact of something like Moment is extremely involved and entirely dependent on how your project works and your users.
- hinkley 8y ago
  Because every web browser and server understands gzip. The gzipped size reflects the transfer size for the file without doing anything at all exotic.
big_elephant 8y ago
it depends on who will be downloading the bundle. if it's a group of consistent users primarily using desktop browsers, it may not be worth worrying about since they'll probably download it once at a fast speed and reuse from the cache repeatedly afterwards. if you have lots of new users on mobile using slow cellular connections, big libraries like moment.js add up and can really hurt load times and make for a poor user experience. for circumstances like that, a developer might look at what are the biggest libraries in their vendor bundle and look for ways to reduce them via tree-shaking or find alternatives, that is if they are even aware of how slow their current bundle might be for mobile users. i think this is for that kind of use case, not only to offer alternatives to those who might need it, but also to raise awareness for those who develop on their desktop and don't engage with their app like most of their users do
- appleiigs 8y ago
  I think mobile phones have browser cache too.
  - big_elephant 8y ago
    sorry, i shouldn't have mentioned caching. the emphasis should have only been on connection speed
shados 8y ago
300kb is half a second to load for someone with a 5mb connection (which is still quite common in a lot of the world...and even in parts of the US). It's also a LOT of crap to parse on a lower end computer. Repeat with a few libraries, and you're going to need a Flash-style progress part as your app loads. That's not exactly a great user experience. Doesn't really matter if you're building an MVP or if you have bigger fish to fry, but eventually it certainly matters. There's a reason the modern web is so freagin slow, and only half of it is because of slow backend APIs.
- angersock 8y ago
  After gzipping none of the variants are that large, and let's be real: the 3rd party ads and analytics and cat pictures are gonna strictly dominate the load time.
  - this_user 8y ago
    Just because there is even more bloat being loaded from other sources doesn't mean that adding more bloat doesn't matter. This kind of mindset has brought us to exactly this point where modern web sites are loading more slowly than one from 20 years ago would have while using dial-up.
    - deleted 8y ago
      [deleted]
  - FridgeSeal 8y ago
    Cat pictures don't interfere with my ability to interact with the web page. The 2MB+ of bloated, unoptimised JS that you ship with your page that I need to parse and render before I'm allowed to see the 20kb of actual content _does_ interfere with my ability to use the page.
    - angersock 8y ago
      The library in question is nowhere near 2MB. You're tilting at windmmills.
deleted 8y ago
[deleted]
anonytrary 8y ago
> for 99% of developers out there, a difference in 300kb is just completely irrelevant. If this is true, which I hope it's not, then I feel very sorry for anyone who doesn't live in a major first-world c̶o̶u̶n̶t̶r̶y̶ city and wants to enjoy the internet.
- deleted 8y ago
  [deleted]
- danielvinson 8y ago
  I feel like this is just a very short-sighted view of the JavaScript ecosystem. A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. I've worked on multiple projects that are served locally from a pre-downloaded package (for example a Kiosk UI).
  - s17n 8y ago
    True, but in your OP you said 99%. Far more than 1% of javascript developers are working on websites and all of those people should be thinking twice before adding 300kb to their bundle size.
  - anonytrary 8y ago
    > A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. This is the exception, not the rule. I find it hard to believe at 99/100 JavaScript programmers are not working mobile or web applications, where 300KB matters, even if you do some sort of content hashing.
robocat 8y ago
I'm assuming you don't have anything to do with mobile web design. Our complex single page app is approximately 180kb gzipped (JavaScript files and a single html main page) - no html from the server except for reports. Size is very important for first visit (lower delay loading files over cellular), and important for subsequent cached visits (mobile devices are slow to parse JavaScript).
ricardobeat 8y ago
300KB is more than enough for a fully functional website including _all code assets_. This is the sort of thinking that got us here.
h1d 8y ago
I wonder how many seconds it takes to load your site on mobile when you think 300KB is irrelevant in your product. From users point of view, it's irrelevant what you use inside but how snappy things are.
fouc 8y ago
https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ https://infrequently.org/2018/09/the-developer-experience-ba... https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
boubiyeah 8y ago
Devs like you is the main reason why the web is much, much slower than it could be. Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc. Making your dev life easier is nice, but don't forget the end goal... (Note: I'm not talking about those internal apps that have 10 users :p)

Sujan 8y ago

Why and how are the suggested alternatives worse regarding the aspects you mentioned?

phaedryx 8y ago

Yeah, I don't understand why comparisons are always made for gzipped code sizes. I mean, I could write something really small that is difficult to parse and abuses memory vs. something big but is all comments. Why is this the first metric that is always trotted out?

k__ 8y ago
Guess you have to measure yourself then :)
owenversteeg 8y ago
Because it's a simple, universal metric. Accurately stating the the performance impact of something like Moment is extremely involved and entirely dependent on how your project works and your users.
hinkley 8y ago
Because every web browser and server understands gzip. The gzipped size reflects the transfer size for the file without doing anything at all exotic.

big_elephant 8y ago

it depends on who will be downloading the bundle. if it's a group of consistent users primarily using desktop browsers, it may not be worth worrying about since they'll probably download it once at a fast speed and reuse from the cache repeatedly afterwards. if you have lots of new users on mobile using slow cellular connections, big libraries like moment.js add up and can really hurt load times and make for a poor user experience. for circumstances like that, a developer might look at what are the biggest libraries in their vendor bundle and look for ways to reduce them via tree-shaking or find alternatives, that is if they are even aware of how slow their current bundle might be for mobile users. i think this is for that kind of use case, not only to offer alternatives to those who might need it, but also to raise awareness for those who develop on their desktop and don't engage with their app like most of their users do

appleiigs 8y ago
I think mobile phones have browser cache too.
- big_elephant 8y ago
  sorry, i shouldn't have mentioned caching. the emphasis should have only been on connection speed

shados 8y ago

300kb is half a second to load for someone with a 5mb connection (which is still quite common in a lot of the world...and even in parts of the US). It's also a LOT of crap to parse on a lower end computer. Repeat with a few libraries, and you're going to need a Flash-style progress part as your app loads. That's not exactly a great user experience. Doesn't really matter if you're building an MVP or if you have bigger fish to fry, but eventually it certainly matters. There's a reason the modern web is so freagin slow, and only half of it is because of slow backend APIs.

angersock 8y ago
After gzipping none of the variants are that large, and let's be real: the 3rd party ads and analytics and cat pictures are gonna strictly dominate the load time.
- this_user 8y ago
  Just because there is even more bloat being loaded from other sources doesn't mean that adding more bloat doesn't matter. This kind of mindset has brought us to exactly this point where modern web sites are loading more slowly than one from 20 years ago would have while using dial-up.
  - deleted 8y ago
    [deleted]
- FridgeSeal 8y ago
  Cat pictures don't interfere with my ability to interact with the web page. The 2MB+ of bloated, unoptimised JS that you ship with your page that I need to parse and render before I'm allowed to see the 20kb of actual content _does_ interfere with my ability to use the page.
  - angersock 8y ago
    The library in question is nowhere near 2MB. You're tilting at windmmills.

deleted 8y ago

[deleted]

anonytrary 8y ago

> for 99% of developers out there, a difference in 300kb is just completely irrelevant. If this is true, which I hope it's not, then I feel very sorry for anyone who doesn't live in a major first-world c̶o̶u̶n̶t̶r̶y̶ city and wants to enjoy the internet.

deleted 8y ago
[deleted]
danielvinson 8y ago
I feel like this is just a very short-sighted view of the JavaScript ecosystem. A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. I've worked on multiple projects that are served locally from a pre-downloaded package (for example a Kiosk UI).
- s17n 8y ago
  True, but in your OP you said 99%. Far more than 1% of javascript developers are working on websites and all of those people should be thinking twice before adding 300kb to their bundle size.
- anonytrary 8y ago
  > A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. This is the exception, not the rule. I find it hard to believe at 99/100 JavaScript programmers are not working mobile or web applications, where 300KB matters, even if you do some sort of content hashing.

robocat 8y ago

I'm assuming you don't have anything to do with mobile web design. Our complex single page app is approximately 180kb gzipped (JavaScript files and a single html main page) - no html from the server except for reports. Size is very important for first visit (lower delay loading files over cellular), and important for subsequent cached visits (mobile devices are slow to parse JavaScript).

ricardobeat 8y ago

300KB is more than enough for a fully functional website including _all code assets_. This is the sort of thinking that got us here.

h1d 8y ago

I wonder how many seconds it takes to load your site on mobile when you think 300KB is irrelevant in your product. From users point of view, it's irrelevant what you use inside but how snappy things are.

fouc 8y ago

https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ https://infrequently.org/2018/09/the-developer-experience-ba... https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

boubiyeah 8y ago

Devs like you is the main reason why the web is much, much slower than it could be. Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc. Making your dev life easier is nice, but don't forget the end goal... (Note: I'm not talking about those internal apps that have 10 users :p)