An Honest Review of Gatsby

Gatsby is a great idea, with a questionable execution. Being able to build your entire site with React, make all of it statically rendered, and then opt into interactive/dynamic parts as needed is really great. Pulling in data sources at build time can be excellent. Overall I like the ideas behind Gatsby a lot.

But with real websites, I struggled to get Gatsby to be performant both at build and runtime. Gatsby really wants to preload other pages on your site in an attempt to speed things up, and you can't opt out of it. Whether this preloading is a benefit is a real mixed bag, and I have found myself spending a lot of time tweaking things to try and make it a net plus across the site. Mostly with bad results. gatsby-plugin-no-javascript can really improve things here a lot. It allows you to opt into JS only on pages that really need it, kill off the preloading entirely, and gain more control over the end result of your site. It's very strange that to get something like Gatsby in the ballpark you want you need to strip out JS, but well, it's true.

gatsby-plugin-no-javascript is not a perfect solution. It's too coarse. But I have found overall it can be a net positive. What I really want is the ability to say "this part of the page/site/whatever is truly static, please don't rehydrate it at runtime".

Gatsby's plugin system is nice. I like being able to handle things like robots.txt, sitemaps, favicons in a well defined, easily managed part of my app. The downside being you gotta accept what the plugin gives you. For example the favicon plugin generates favicons that are over 30kb. In my case, the favicon is often larger than the entire rest of the page combined. So I still find even here Gatsby is a good idea with questionable execution at times.

Gatsby has strict caching requirements -- https://www.gatsbyjs.com/docs/caching/ -- and if you can't meet them, your site will have subtle bugs. This means Gatsby is not compatible with Github Pages, and is a major downside to Gatsby.

This article spent a long time complaining about MDX. I agree, I think MDX is quite bad. But of the 4 complex Gatsby sites I have built, none of them used MDX. I don't think it's fair to conflate MDX's short comings with Gatsby.

I'm currently playing with Svelte's Sapper. It might possibly become what I always wished Gatsby was.

Perl's Template Toolkit has provided everything I've needed in a SSG for the last 20 years.

Argh, I thought this was a (potential) new take on "The Great Gatsby" but it turns out to be some web framework I haven't heard of. Could we maybe name things so that tech things sound like they are tech?

The creator of Lektor (https://www.getlektor.com/), aka @the_mitsuhiko, works for Sentry, and as I got from David Cramer himself over Twitter, Lektor is used for various secondary or internal websites at Sentry.

Has it been a contender for the rewrite of their documentation?

Shameless plug: I'm in the middle of a rewrite of my company's website (https://abilian.com/) using Lektor myself. So far so good, for someone used to Python and Flask it's the obvious choice for a static website generator.

> If a static site generator put my images in the wrong place and required a gigantic JSON file to be loaded by the client for no reason I would not think twice to get rid of it.

Incorrect DOM-output is likely caused by common mistakes (e.g. conditional rendering based on `typeof window !== 'undefined'`) which screw up rehydration. Dealt with it in the past and seen a lot of developers struggle with it. This article describes it well:

https://joshwcomeau.com/react/the-perils-of-rehydration/

Gigantic page-data.json files are caused by querying more data than necessary to render a given template/component. Let's say you define a component named `EmployeeCard` that renders a name and photo given an `employeeId`. Now you need to query all employees and render the right one using `.find()`. All this data (including base64 thumbnails) ends up in page-data.json, even if you need to render a only single employee.

This is solved by querying only the relevant employee(s) in the template and provide the data (name + photo) directly to the `EmployeeCard` component as props.

I've developed quite a few websites using Gatsby (mostly backed by various GraphQL API's such as WPGraphQL and Strapi) and while there's lots to learn, it's been an enjoyable experience so far.