[pknopf]

> The bottom line is flexibility and speed

Gatsby gives you neither.

Give me a tree navigation. Oh, it's not supported? Now, in order to implement it, I have to figure nodes/graphql/webpack/fragments (I know the tech, but it it's _used_) to get a solution that I could whip up myself in 30 minutes if the tooling and techstach wasn't bogging me down.

There is a hidden cost to large peices of software with high ceremony. Most people ignore it because of the initial speed you get in setting up the project, but fail to realize the downstream time that will be wasted dancing with these large hammers.

[fvsch]

This matches my impression of Gatsby after a day with it. I bailed a bit more quickly than with Hugo, so I refrained from adding a Gatsby section to my already too long article. Also my main takeaway was “Gatsby is an overengineered mess from (and favored by) people who are already all-in on React and GraphQL and don’t realize the learning curve they’re asking others to climb to build simple sites”. Too categorical for something I’ve only spent a short day with, so I decided not to include it.

While I do know React well enough, when trying to work with local content I had to follow a tutorial that asked me:

1. To install 2 plugins 2. To copy-paste 3 different chunks of boilerplate code (configuration, the code that maps filesystem data into some kind of representation — maybe using GraphQL already, I’m not sure — and lastly the GraphQL queries to retrieve that data). 3. To personalize this boilerplate code, which requires me to learn GraphQL.

Other tools can do similar work without plugins, without having to learn a second language (GraphQL) separate from the core language that the tool is using (JavaScript), and without having to write code to feed content into a in-program representation yourself.

It could be that all this overhead is worthwhile because it enables you to do complex things. But from what I’ve read I wasn’t even sure that Gatsby could achieve my use case without me duplicating my information architecture as “feed content to the in-program representation” code, and I didn’t want to risk spending a second day only to find out that it couldn’t. (Your comments about tree navigation, as well as some of the GitHub issues I’ve read, suggest I was right to bail out.)

My actual takeaway is that Gatsby might be a good fit if you already know React and GraphQL (or already wanted to spend time learning those), and are working with remote content from a headless CMS and some other sources. But for local content only, unless you already know Gatsby or want to use that project to learn it, it’s needlessly complex and overkill.

[kall]

I think you might be right on with "people who are already all-in on React and GraphQL". I honestly prefer writing JSX/React+GraphQL to a template language even for static content. I like that gatsby makes that an option without making an annoying SPA content site. It‘s a good reality check that this is likely a niche prefer ce.

And I also want to use headless CMSs or other data sources, in my current project a GraphQL source, which maps right in with the (very recent) schema stitching. So I think gatsby is the right choice for me, but I will carefully consider recommending it in the future. Being a VC backed company they may have more cheerleading than other open source SSGs going on.

[tcfunk]

It most certainly gives flexibility. Speed could be read as page speed or development speed, and it certainly gives the former. The latter depends on your familiarity, I suppose.

[pknopf]

Sure, it's flexible. It can do anything you want. But only if you are willing to put up with the constant fights. See here (for one example out of many): https://github.com/gatsbyjs/gatsby/issues/4583

I urge you to just take a look at the GitHub issues and ask yourself "How much blame can be given to the tooling/tech stack for this given issue?"