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.
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.
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.
> 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.
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.
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
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.
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.
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).
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)
From users point of view, it's irrelevant what you use inside but how snappy things are.
Why is this the first metric that is always trotted out?