[methyl]

> Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip!

How is that 22.5kB making any difference? Unless you are working on a project that will be used on very slow connections I see no point in choosing a library basing on such small difference in size. And if you really are targeting those slow connections then maybe going SPA is not the best choice?

[brianmathews]

From recent bundle audits of e-commerce sites built with React, less than 20% of the code was actual custom site code and the remaining 80% was from dependencies.

If the bundle size is 550kb min/gzipped, that's 110kb of app code, and 440kb of dependencies. Some of the largest dependencies in a recent audit were: moment (60kb), swiper (32kb), lodash (24kb), react-select (26kb), raven.js (12kb), polyfills (25kb), mobile-detect (15kb), and then a bunch of smaller dependencies that made up the remaining 300kb.

Using this performance budget calculator you can quickly see how each 25kb of JS adds ~.3s to your TTI on a mobile phone:

https://perf-budget-calculator.firebaseapp.com/

If developers shop around for smaller alternatives of each dependency, then they can cut their load times pretty drastically.

[underwater]

Fixating on package size alone is missing the forest for the trees. A good library can massively reduce your application size and pay for itself many times over.

For example, Relay removes the need for a lot of Flux and network request boilerplate. Going beyond that, it can collapse serial network fetches down into one request, massively speeding up page loads.

(This doesn't apply to moment, that library is just designed in a brain dead way).

[wolco]

Not using moment will give you back 60k almost three times the savings: 22k

[helloguillecl]

It does incrementally make a difference. You want all your libraries to stay under a certain budget if you don't want to hit your users with a 500 KB bundle size.

It is not only about how long it takes to download, it is also about parsing that amount of code in low end phones.

[underwater]

Most apps need to do two core things: render UI and manage data. Setting a sub 30kb budget for something so core is madness.

[methyl]

> if you don't want to hit your users with a 500 KB bundle size.

Still I do think if you are building a web application (and not a static site or a blog) it is expected it can take a second or two to load it for the first time. 500 KB bundle is nothing wrong in that case.

[pavel_lishin]

> it is expected

It's also expected that my train is going to be late, but we can lament this condition, instead of resigning ourselves to it.

[ctvo]

The initial question of why did you make something iteratively better (in terms of size). It's only 20KB. Can be used to stop progress in any field by replacing the keywords.

I would hate to use something built by people with the attitude that compromising on performance when you don't need to is OK because it falls in line with current expected ranges.

[RossDM]

18% of the Alexa Top 10K sites grew by 1MB+ from July 2017 - July 18. (source: https://twitter.com/katiehempenius/status/113320912700037939...)

Ignoring the impact of libraries you send to the frontend will lead to death by a thousand cuts.

[methyl]

How many of those Top 10k Alexa sites are full-blown web applications that need GraphQL in the first place?

[RussianCow]

It might be expected, but I have to admit, there is a certain joy to using a website that loads instantaneously (like Hacker News). Whether or not that joy translates into additional revenue to justify the costs is another question entirely...

[itsangaris]

When talking about a few kilobytes, it’s less the download time than the parse time that’s the main performance concern.