I used v1 for my current site , and have been planning on revamping or redoing everything with v2 eventually. I loved how little I had to meddle with things to get something up and working that was solid.

I ended up with my dream workflow for writing and publishing content:

1. write content in markdown
2. git push
3. What....? There is no other step. That's literally it.

Ok I cheated a little. There is a Build step, git commit, etc. But it's about as streamline as humanly possible.

That said, to really dig into things deeper, you do need several layers of tech know-how (JS, React, GraphQL, etc.). I don't think that's a negative though really.

I would recommend AT LEAST giving it a test run.

1. It took me some time to be up and running, but their docs are really written well, so that helped.

2. At first graphql data layer seemed like an overhead. But the elegance of getting the data that was required, helped components being independent and clean.

3. I've not been critical enough to look for metrics of if the markup comes out bloated like Jason Knight did in his answer ( I've started being a little scared of him 😅), but the fact that they pre cache remaining routes ( as well as data needed by them ) by following Link tags of a route, as soon as the route is loaded makes transitions fast, at least for small to medium websites. More info with metrics here

4. I agree with Ryosuke, if there's a first class data entity that needs to be put somewhere, a CMS solution has to be a must with gatsbyjs.

5. I also have had instances of not very helpful build crash errors when there was some problem in either fetching data from the source, or some other typo mistakes like Ryosuke explained.

6. But I really really like their plugin architecture. It enables to for example have blur image effect (progressive image loading) and have responsive images with just one plugin inclusion in gatsby config and it works like a breeze.

7. Gatsby has been adopted by numerous government websites throughout the world which is really nice to hear, considering how dysfunctional many of the government websites throughout the world seem to be. It's a good middle ground between a fully blown opinionated content management system and something completely static.

8. Gatsby comes with out of the box service worker support.

9. Some of the libraries / components that you might use with a client side single page app, or server rendered app is hard to pull off with Gatsby. For example one can't properly use ( as far as I could understand and tried ) react-media React component for handling media queries because, there is no way for us to tell react-media what the value of defaultMatches should be at load time. We might only keep track of it in React's state, and detect the user's device on componentDidMount, which is ought to produce jagged switch of layout either on mobile, tablet, or desktop. But I guess this is very obvious 😅. It wasn't for me 😁.

10. Gatsby is constantly working on lowering the build time for thousands of pages, which is encouraging to see. I've never tried building 10000 pages for a website, so I can't comment on the experience with a massive website/app like that.

I'm sold on Gatsby over other static site generators in what it enables me to do, with a little reading of the docs and trying things out.

Great for static content. Not great (yet!) for dynamic content, or massive repositories of data (like Wordpress DBs with 1000s of posts). However, Gatsby v2 is currently working on lowering the build time for larger projects.

I'd recommend Gatsby if you're not satisfied with another, more out-of-the-box solution like Gitbook, Docusaurus, Docz, etc.

It's a lot easier to create a custom Gatsby theme, as well as customize and manipulate data sources.

Gatsby makes it easy to take any data source and plug it into GraphQL, and work from that layer. Instead of pulling from 5 different APIs every time you need something, you can just query GraphQL for everything. And it loads all your data on build, so you don't have to stress the API on each page load.

If you don't want to fuss with the GraphQL data layer -- or a more complex use case -- I'd recommend something like NextJS.

My personal experience

Gatsby takes time to setup, and it can be fussy in production because of GraphQL. If data is missing, the site won't build properly. I had to debug an issue on my personal Gatsby site where I incorrectly formatted a date in my Markdown (09-09-2018 vs 09-9-2018 🤯) and GraphQL wouldn't recognize it -- crashing my entire build process.

If you use Gatsby, I'd highly recommend using a CMS to manage any user-inputted data.

Regardless though, I've loved my experience with Gatsby. It makes it much easier to create lightning fast static websites. Every site feels incredibly fast, with almost instantaneous page loads in some cases (thanks to all the preloading and PRPL pattern magic under the hood).

staticgen.com has tons of options to consider.

React is not an ideal base for static sites as its primary purpose is live rendering/updating, which is the opposite of what you need in a static site. Honestly for a really small site I just use PugJS and a Makefile.

For simplicity

SSG - Static Site Generator

SSR - Server Side Rendering

Instead of GatsbyJS, I've tried NextJS while building my startup MFY. I would say GatsbyJS is a subset of NextJS. GatsbyJS is an SSG while NextJS can do both SSR and SSG.

SSG vs SSR?

If you're developing a site in which the content doesn't change frequently or you want the content to change on reach build, go for GatsbyJS.

But if your content is inside some API or database and on reach render it should show new data, go for SSR.

For example, consider the case of @hasnode. Every time a user visits they need to show the latest posts from DB. In such cases, Gatsby can't help. NextJS can render it from the server itself fetching from DB.

However consider a Blog or a static site, their inner contents won't change like this. In such cases, they can call some API (maybe WordPress rest API) and then create HTML files for each blog post, which will be super fast than SSR.

However, I left SSR (NextJS) in MFY, because I can easily deploy it to Netlify and at that time there were many bugs (looks like most of them are fixed now). If its SSR I've to run my own server

Never heard of it, but giving the demo's a once-over if this is typical of the code they vomit up:

gatsbyjs.github.io/gatsby-starter-default

I would NOT suggest using it. They seem to have a raging chodo for inlining style in the markup which means a missed caching opportunity. In general their entire site and much of the methodologies listed in their tutorials

So like most of this nonsense, my advice is just say "no" -- unless you WANT to tell users with accessibility needs to go plow themselves and deploy ten times the code needed to do the job.

The real laugh being their output is minified and it's STILL 11k of markup to deliver 100 bytes of plaintext -- not even 1k's flipping JOB. Admittedly 9.9k of that is all the style that has ZERO BLASTED BUSINESS IN THE MARKUP, but even that's a bloated mess; a laundry list of how NOT to build a website. Don't even get me STARTED about the train wreck of hardcoded CSR in that bloated script.

To be brutally frank if all of those "data-react" attributes slopped onto things JavaScript has zero blasted business even touching, inlined style="", static STYLE tags, pixel max-width with EM content, lack of condensed properties in the stylesheets, and host of other "I cans haz teh intarwebs" ineptitude doesn't tell you these people have NO business telling others how to make websites, nothing well.

Just once I'd like to see one of these things where the code didn't just scream "For people who know nothing about building websites, BY people who know NOTHING about building websites."

This one only reinforces my belief that such systems are incapable of producing quality websites. They are universally bloated trash flipping the bird at accessibility, chewing on bandwidth for nothing, and overflowing with bad practices. I hate to use the words as I do resort to them far, far too often, but these types of "shortcuts" simply reek of ignorance, ineptitude, and incompetence.

Apologies to all if that's too "harsh", or "offensive", or gets your knickers in a twist, but that's the TRUTH of it! Truth hurts, that's why it's so unpopular.

Alternatives? You want to write a static site, just write a static site! Or go simpler by just leveraging whatever your server side language is to divide up the common parts from your content -- the old "poor man's" approach.

I did and it was really easy (even for me) to set the whole pipeline up and running. Since you're 👌 with with React, you will easily get used to working with it. I played around and even got into the whole reusable components thing. It was all amazingly simple. Also, it's easy for non-tech people to get used to using it ( even mkt teams for example). In combination with some other services (don't want to get all too promotional), you can enable members of your team to just upload pure markdown, and the whole engine would serve the content instantly across platforms.

This comes in handy when you don't want to give access to the source repository to the mkt team and increases the agility of both the development and mkt.

Alternatives:

1. Hugo written in go,
2. Middleman written in Ruby, and
3. Jekyll more Ruby.

I'm sure there are more, looking forward to seeing what people are using 😀