[lhorie]

Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable. It's because of developers prioritizing developer experience and other baggage over user experience that I despise my mobile web surfing experience.

Plenty of people do care about frontend performance (as evidenced by the plethora of efforts ranging from small alt vdom libs by solo devs to large corporate efforts like AMP or m.uber.com[1])

[1] https://eng.uber.com/m-uber/

[enraged_camel]

>>Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable.

So large library size == mediocre?

Jesus christ, HN is full of extremists.

[lhorie]

A large library is perfectly fine if it provides enough functionality to pull its own weight. But these days just about every site on the web has dozens if not hundreds of bloated libraries for the stupidest things and large bundle sizes due to that have become a pretty good indication of wrong priorities from the developer's part.

And I, as a user, am left waiting several seconds waiting for pages larger than the original Doom executable to load. It's gotten so bad that my wife had to be selective of when to use her phone because browsing normally without wifi from starbucks etc would get her over the plan limit by mid-month. I mean, how much browsing are you really supposed to be able to do when every page is several MBs of JS alone, and you have a 300MB/mo plan to work with? Not every country has cheap/good mobile plans.

[starbuzz]

^ This

[starbuzz]

The irony is you are the extremist for thinking HN is full of extremists! :)

Also, library size !== mediocrity at all. No one builds an unreasonably large framework on purpose either.

[pygy_]

Given an equal feature set (and similar performance), a larger lib is worse, yes.

If your problem space requires a lot of code, then off course not.