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.
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.
That is totally fair, but for me, I make internal company apps. They happen to use Javascript, but realistically we could ask someone to download 100mb of a binary, and it would still be an ok situation.
For other devs? I bet they say that people on slow connections are not the target market. After all, a slow line will choke on all the ads used to pay for the site.
Yeah, we definitely care about this more for our external apps than internal ones, but as we grow and our internal users expect more and more sophistication from our internal tool, it's becoming a bigger priority. It really does matter. Think the customer support agent or the sales rep who's on the phone and has to make the customer wait just a few more seconds can have an impact... but it's definitely harder to justify.
> I bet they say that people on slow connections are not the target market
That however... there's a LOT of data showing how every seconds count for things like ecommerce or news websites. And for actual B2B type apps, they likely don't have adds after you are logged in. We're gathering a lot of data on this internally, and customers care a -lot- about perf of things like CMSs, CRMs and other enterprisey apps.
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.
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.
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.
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
> 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.
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).
> 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.
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.
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).
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?
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.
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.