Gatsby: How do you justify Gatsby’s bundle size to clients

[azangru]

I want to begin by saying that I love Gatsby. Especially its graphql-based data layer. Compared to the other static-site generators that I tried, it’s in the league of its own.

Therefore it pains me to say that when the time came to make a static site for our company, my colleagues were set dead against it.

It’s overengineered, they said. What we need is a simple static site, they said (albeit coupled with netlify-cms that will produce what looks very much like relational data that would be a joy to query with graphql). We do not need an interactive application, they said, and you suggest pulling in the whole React. Just look at the bundle size, they said. An empty page with no content whatsoever will already contain about 100 kb of minified and gzipped javascript. Shame on you for even suggesting this, they said.

But look at the bright side, I said. Client-side navigation will be instantaneous.

It will be in any case, they said. If the pages are small, then with server-side caching they will be delivered lightning-fast anyway.

I wonder if you had such discussions with performance zealots, web platform purists and minimalists who will sacrifice developer experience for the leanness of web pages. Did you manage to convince them that Gatsby is a worthy option?

[KyleAMathews]

We generally ignore them ;-)

A more detailed answer would be that they're totally right — for small projects, it really doesn't matter what you pick as everything is easy (as long as it's familiar). I'd argue Gatsby is still easier / delivers a better result since we optimize frontend performance a lot compared to most solutions but sure, for a site with a few pages, whatever you do works out the same.

But the longer/larger the project goes, Gatsby pays huge dividends as you'll develop much faster with React/GraphQL & our automatic code splitting, prefetching, etc. will ensure that you're site _stays_ fast as it grows.

Also, 100kb of JS is tiny ;-) If you add jquery and a few plugins, you'd hit the same amount. Also Gatsby's default JS size is ~65kb :-D

[hassanshaikley]

Are their constraints justified? I think generally they are not and are associated with a cost as @KyleAMathews put it.

[azangru]

Are their constraints justified?

How would you go about exploring this issue?

I would say no they are not (but I am biased, because I love Gatsby). A minimal Gatsby-generated page still passes a lighthouse audit with flying colors (although I got 99 for performance instead of 100 for a page that had like only one sentence of content). But one can’t argue with the fact that 100K of minified and gzipped javascript is larger than 10-20K (I don’t know how much one would realistically need to animate a menu and connect several buttons to some custom data). And if one reads Alex Russell’s tweets where he condemns web devs for their liberal use of javascript frameworks, one becomes easily intimidated.

[jserrao]

If feel like someone complaining about 65K of overhead would have their collection of websites optimized better than any organization I've worked with. Seems like a sheep-in-the-wolfs clothing type of argument; perhaps there is something else going on?

[azangru]

Nothing more going on really; it's just that they object to the idea of starting with around 100k of javascript (I don't know why it's not 65k in my case; perhaps it's because netlify-cms also gets bundled in somehow) before any content is even added to the site.

I thought it might be a fairly common objection and that perhaps you have already had and won these arguments.

[mattbag]

If you have a cms bundled your argument is just: 'How much is wordpress(or other) sourcecode?'
Beside that you could go and make a list of pros and cons to balance this specific drawback (ssr,offline,pwa can come be added)

[azangru]

Thought that might be relevant:

(link)

[KyleAMathews]

Closing this cause if someone is sad about Gatsby adding JavaScript they're well served by other options.