Gatsby is a static site generator based on React and GraphQL. Other static side generators, are for example Jekyll and Hexo, while Jekyll is probably the most used one due to the build in jekyll support of github (This blog uses Jekyll because of that).

The new website of the Infographics Group The new website of the Infographics Group

Why should one use something new, relatively unproven like Gatsby in comparison to Jekyll? Because Gatsby offers you all the advantages of modern React development: A vast ecosystem, hot-reloading, super flexible data sources, a kick ass workflow… and much more! Jekyll feels kind of outdated in comparison: ruby-based build, limited choices of data sources and no modern JS build pipeline. The last point is not directly bad, most websites don't need a heavy JS-stack, this Blog for example uses 25 Lines of javascript to make pictures zoomable and load fonts async. But for example, I would love to have interactive elements on some blog posts, how would I do it? I would need to put heavy effort into it and would probably hack some React + Webpack support into jekyll, because it's my preferred way of developing interactive websites. With Gatsby this would be super easy. Gatsbys docs are pretty good and reading them should make it more clear why one would like to use it.

The first few days

The tutorials at gatsbyjs.org are a joy to follow and read. Every important aspect is taken care of to quickly get something working and to get the workflow. After everyone made himself familiar how Gatsby works, we started our project with the Gatsby Typescript starter. We did some scaffolds using the build in npm run generate command and started working. The build support of react storybook made it easy to develop quickly independent components and to easily review them.

Webpack 1.0 & versioning issues

One problem our chosen starter had, that the Gatsby versions weren't actually locked at all, every dependency was set to latest. This wasn't a big issue in the end, but still annoying and I will never forget again to check that after setting up a project from a boilerplate. A big surprise for us was also the fact, that Gatsby still uses webpack 1.0. This isn't bad per se, but for some reasons we had the webpack-text-extract-plugin explicitly stated in package.json… in version 3. It didn't break anything at first, but after trying to build production no styles we're generated.

Cache problems

By far the biggest issue we had, was that somehow the caching didn't work correctly. we had no clue what was going on, index.html was not cached at all, but after a new deployment we had invalid Javascript with the issue: Uncaught TypeError: Cannot read property 'call' of undefined. What was going on? The Javascript sources had a hash appended to their filename, which is done to make sure that the sources in index.html always point to a new file and the browser does not use an invalid cached one. Then I read this issue and got angry. In short: Gatsby has no real way to cache JS-files currently, because of webpack 1.0. I don't know the details, but that's their explanation. I really didn't even think about the possibility that the hashes didn't change. Why should one append hashes when they don't change? But it didn't take long to find that issue, but I would wish they would have state that somewhere or not use hashes at all.

Should you use it?

It depends for your project, I would definitely use it again. The workflow is rock solid and despite the problems we had, only one was Gatsbys fault. And even if one decides to ditch Gatsby - it shouldn't be hard transition to a custom React + server side rendering stack. Here you can check our site we did with Gatsby: http://infographics.group/.