Quick Thoughts on Gatsby JS vs. Jekyll
Static sites have become something of a hobby of mine recently. I’ve become addicted to spinning up new Jekyll sites both at work and for fun for a myriad of purposes. Portfolios, blogs, documentation — really any site hosting static content or managed by a CMS are great candidates for a simple static site.
I’ve been a huge fan of Jekyll to do just that. It enables you to write and manage content in markdown and just sit back and let Jekyll to the heavy lifting of putting your site together. And with GitHub pages you barely even have to run Jekyll locally to build a new site.
So, Jekyll is great and easy and supported by my favorite tools. Nothing else deserves my static site attention/love, right?
Enter Gatsby JS
I first heard of Gatsby JS from Michael Rose on Twitter, when he dared suggest that Gatsby had shook his stalwart adoration for Jekyll.
That tweet alone was enough to warrant my attention. But for others who might not be swayed, my elevator pitch for Gatsby is this:
Build static sites using React.js and its powerful and versatile reactive components, and harness the power of GraphQL to fetch data from a vast array of sources — quickly.
That snippet is a lot more convincing than even the Gatsby JS documentation, which to me ends up being an endorsement of the power of Jekyll than a clear indicator of why Gatsby outdoes them all. You can compare features one by one on the website, but again you end up with a spotty picture of why you should care if you already understand and use Jekyll.
I spent about a week going through the Gatsby JS tutorial, and quickly picked up on the basics of the React and CSS-in-JS concepts behind Gatsby. The value of components is pretty apparent, especially when it comes to designing a site like a blog or landing page quickly.
I went ahead and built a quick portfolio site as well, and used it to test making a markdown-driven page. There were definitely some challenges, especially the frustration of dynamically managing assets packaged with webpack and in constructing GraphQL queries, but nothing that a more experienced JavaScript-er would even blink at.
In the end I was able to create a portfolio page of designs, each defined by the YAML front matter, that could be populated dynamically.
Musings
Overall, I was impressed by the power of Gatsby and the flexibility of building with React components. GraphQL is also an interesting alternative to something like REST, and I’m glad I learned the basics on the scale of static sites.
That said, coming from Jekyll, a tool that already does a lot of this really well and more out-of-the-box, the case isn’t as strong. I like that I can just start shoving markdown content into most Jekyll themes and it just works. I like that the static themes are a little more static. I like the tightly coupled GitHub pages integration.
So, if you’re reading this wondering which site generator to use, I would suggest checking out Jekyll for your first static site. Check out the work by Michael Rose and my tutorials on your first Jekyll site. It’s just so easy and fast to get your start, and it does almost everything Gatsby does and in my opinion it does it with a slightly shallower learning curve.
But if you’re really excited about React and you want to learn more about using it along with GraphQL to build a site, then Gatsby is defintely worth a shot.
In my mind, all the static site builders can get along. I’m excited for what I’m going to build next, regardless of which of these two I’m building with.
If you’re interested in the source code for my attempt at building a site with Gatsby, check it out on GitHub.
