A Greater Gatsby: Modern, Static-Site Generation
Gatsby is currently generating a ton of buzz as the new hot thing for generating static sites. This has lead to a number of frequent questions like:
- A static…what now?
- How is GraphQL involved? Do I need to set up a GraphQL server?
- What if I’m not a great React developer, really more of a bad React developer? Does this mean our copywriter won’t have to push to a GitHub repo to add a new page?
What does Gatsby do exactly?
Gatsby is a static site generator, intended to build all the HTML you need based on data you created. Presumably, that data was simpler to manage than straight HTML.
I don’t use a static site generator now. Should I?
A static site generator probably doesn’t make sense if your site is truly static (e.g. a marketing site that gets updated twice a year.) Static site generators make more sense if you are building something that updates every 1-10 days, like a professional blog.
If you’ve ever used Jekyll, another static site generator, the basic concepts are similar: turn a folder of plain markdown files, or the like, into a complete site with just a bit of config.
But the limitations of Jekyll and other older generators are myriad:
- Complex and endemic config formatting.
- The lack of some particular feature which you need and they don’t have (it generates blog posts just great and interprets your ‘author’ field, but now you want posts two authors, for instance.)
- There’s no great way to get new files from all team members. Often teams using Jekyll end up using a GitHub repository to store their source text files (again, Markdown or what have you) meaning your marketing copywriter needs to learn git to add a new blog post or more often: email a developer with an attached file for her to add.
- You can’t make a Jekyll site in React.
Gatsby offers significant improvements in these areas since, along with bare-text files, Gatsby can import data from almost any data source and generate a clean React site based on the data it queries.
GraphQL is even cooler than React, but I have concerns.
GraphQL offers a tantalizing dream: a system that can connect multiple data sources with a simple query language. Suddenly your hip NoSQL databases and creaky SQL databases can all be displayed through a single app.
But building and running GraphQL are not always simple, and fundamentally this new engine requires learning a new query structure. It’s cool to see that Gatsby is ‘powered by GraphQL’ but doesn’t that mean there will be some massive friction in getting this deployed?
But remember Gatsby generates a static site. It uses GraphQL to access DB’s and generate your site, but once that process is over, GraphQL doesn’t need to be running for your site to work.
But isn’t there still a learning curve?
Yeah, that part is inescapable. While many common setups have templates to start with, your team’s weird content database from 1997 is going to require some custom config. There’s no way this could be harder than importing the data yourself, and once it’s configured you only need to update your database and re-run the Gatsby build.
What if I’m not a great React Developer?
If it took a React expert to use Gatsby, it wouldn’t really have a market and that’s clearly not the case. Ultimately, if we could make awesome React sites from scratch, what use would there really be for Gatsby?
Fortunately, the tutorial for Gatsby is also a great way to gain knowledge of React in general. If you only use Gatsby for your first React app, a few things like auto-link formatting will seem like they’re core React tools when they’re really part of Gatsby. But that shouldn’t be a dealbreaker for anyone.
Having written zero React in the last year, I found my first few sites a cinch with Gatsby after spending a couple hours in their tutorials. If I can do it, anyone can—yes a logical fallacy on the SAT, but true here.
Can we get the team away from Git?
Here we get to the real potential of Gatsby: for our non-git-savvy team members, Gatsby can consume the database of another Content Management System (CMS), seamlessly importing articles with your main site. A CMS can present an input and editor for articles without taking responsibility for displaying the content it stores. Used this way it’s ineptly called a ‘headless CMS’. The good news is, your content contributors can now publish content on their own, without needing to do a code push.
Gatsby is Different
I’m not aware of any other static site generator that has this kind of functionality out of the box. Problems like scheduling posts ahead of time, editing posts (without needing to edit HTML) and content with multiple links and embedded files can all be handled by a tried-and-true editor like WordPress, while Gatsby generates a high-performance React app from the data. Gatsby is worth the plunge. Let me know how it goes for your team!