An Honest Review of Gatsby

I never tried Gatsby, but I tried Hugo. I like Go, so I searched for a Hugo-template I liked and build some documentation for my project. Then I took a break from the project and when I wanted to update the documentation a few months later (minor changes), I spend about 2 days just bringing my content in sync with the updated template. What a horrible experience.

Maybe I was doing something wrong or the template author, but actually I am thinking about my best options currently, because I am 100% sure, I don't want to go through that mess again. Even building plain HTML pages by hand would have been a lot easier for me than finding out why the updated template didn't compile anymore.

Dunno, but I'm going to take a stab in the dark at the possible incentive structure:

(1) No amateur is especially proud of setting up a static site, because it either seems easy as expected or it wasn't easy and they don't feel like trumpeting that.

(2) Professional web developers went into web development because they like featureful JavaScript, so they don't really see the appeal of static sites.

(3) Some big % of professional designers went into design because they wanted to design complex user experiences, and so they push for things that require JavaScript.

(4) Website owners like metrics, so they want a bunch of JavaScript to track user engagement and whatnot.

I have seen good results from Hugo. It is easy and typically works. Good for a small business website.

> approximately 0% of the engineering team knows Ruby

I found this surprising. I once worked somewhere that used Sentry heavily (liked it a great deal, it was pretty important to us). We had about a hundred projects and were encountering quota problems, the worst of which were usually from misbehaving queue workers on staging or perf the would consume our entire event budget if left unchecked. If we didn't shut it off in time we'd end up losing meaningful prod events.

Our solution was to switch to a YAML based config for rate limits and per project quotas. This would ensure every project was capped, central prod services were allocated more events like they deserved, etc. Sentry staff sent us a helpful starter script for utilizing their project configuration REST API. It was written in Ruby.

I think alot of folks share this view. When we switched our marketing site over to Gatsby it was a godsend, but once we hit over 400 static pages on our site, the build times were killing us.

Our devs complained that even on local, building took forever, and because it had to refetch all of our WordPress CMS media library each time, sometimes it would just crash during build.

Also we grew the need for good SEO support for dynamically generated pages (of which we have thousands), and we had to write our own prerendering lambda function to handle bots (and embed tools) that couldnt run js on their own

After Next announced their support for static site generation and the release of next-serverless, we took the next three weeks to get our site ported over and haven't looked back since.

The first complaint in this is review is that markdown isn't rendered in custom MDX components, using this example:

``` PUT/DELETE methods only apply to updating/deleting issues. Events in sentry are immutable and can only be deleted by deleting the whole issue. ```

And goes on to shiw their ugly hack to make it work.

Well, markdown in custom MDX components is rendered. You only need to leave a line break to signal to the parser that this needs further processing. Like this:

```

    **PUT/DELETE** methods only apply to updating/deleting issues.

Events in sentry are immutable and can only be deleted by deleting the whole issue.

```

Which I really don't find to be a deal breaker.

I stopped reading after that because I was hoping for a somewhat more informed opinion.

From my experience, build time/build complexity is Gatsby's achilles heel. But I've built some stuff that looking back I don't think I could have done without Gatsby, as I came yo it being new to React.

It's simple enough on the surface and as you dif deeper, there's plenty of knobs to turn.

My one wish is if they'd let you bypass image processing in the development environment. Apart from that, I can't recommend it enough.