[pknopf]

IMO, Gatsby is one of the biggest hammers for smallest nails.

I mean, how many dependencies/ceremony do we need to convert .txt > .html?

Webpack? Graphql? Client-side routing? I mean, if you want to have fun with shiny tech, go for it, but it really is the wrong tool for the job.

[nkristoffersen]

The bottom line is flexibility and speed. With Gatsby you get both. Only looking at it as a .txt > .html convertor is very limiting. I generate 1,500 webpages every day from custom datasources with Gatsby. Using React components gives me DRY code. This gives me very great flexibility during development and great SEO and speed in production.

[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?"

[cdaringe]

You are grossly simplifying the value that SSGs provide and problems they solve. Gatsby has some quirks, but it does strike a good balance of providing value whilst giving you plenty of control. It does the data capture and transformation of content I want, it gives me a place to explore and visualize those parsed datas, and it lets me control how to render that content in a context that very closely resembles the final artifact (jsx, html). It doesn't cram a new DSL down your throat (jsx is close to html enough, and, it's optional). It has excellent debugging in node and the browser. Hugo doesn't have those, Jekyll super doesn't have those, and everyone's home grown scripts certainly don't have all of those. There isn't a one-size-fits-all, but saying it's a poor tool because it has a lot of dependencies is silly and immaterial.

[pknopf]

> There isn't a one-size-fits-all

Spend an extra day and build your own. It will fit you exactly. No more, no less.

> but saying it's a poor tool because it has a lot of dependencies is silly and immaterial.

You're missing also the time it takes to customize it. For example: https://github.com/gatsbyjs/gatsby/issues/4583

How complicated can it be to have simple tree navigation? Turns out, it's pretty complicated...

I could role my own in 20 minutes without the abstractions, but no, I'm fighting uncessaray abtractions/layers/tooling that gives very little value when it comes to converting .text -> .html.

It blows my mind that people don't see this.

Read this: http://tonsky.me/blog/disenchantment/

[kall]

The amount of (dev) dependencies doesn’t matter that much to me, but I agree about the client side. I wish gatsby could emit a version without client side routing / react. I also find the way to create and manage pages (and yeah trees) is not as flexible as it should be.

"Just a txt > html converter" is what every developer builds for themselves at some point and hence the 300 different projects that already do that. I‘m glad someone is making a database backed (kind of) static site generator for once, even if it brings some code weight with it.

[pknopf]

> The amount of (dev) dependencies doesn’t matter that much to me, but I agree about the client side.

I read a blog post recently that really resonated with me [0].

> And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):

But yeah, I don't mind where the data is stored. It's the html generation that people go overkill with.

[0] http://tonsky.me/blog/disenchantment/