8 min read

Let's talk about my first day with Gatsby

It all started with a single tweet...

Gatsby had been on my radar for a long time, to say the least. I had first checked it out when it was still what seemed to be a side project for Kyle Mathews. I tried it out and happily gave it a star on GitHub. It was a nice experience, but nothing that I was exceptionally excited about. This was all mid-2016 when JavaScript-Fatigue™ was still very much at its peak. For that reason alone, I was apprehensive to fully adopt such an infantile library.

Shortly after that, however, I saw this tweet from Kyle Mathews.

At that moment, Gatsby had fully piqued my interest. It definitely seemed to be a risky move to an outsider, but I had seen Kyle's work and admired his dedication to the project, so I was fully interested to see where this would go.

Unfortunately, due to other work-related circumstances, I still was unable to adopt it into any projects. I was more interested in watching it grow than actually adopting it at that time anyway.

Fast-forward to 2017, I was working full-time at Timber.io with little time for my side-projects. But boy-oh-boy did Gatsby mature during that time. The community surrounding it exploding seemingly-overnight. Getting hundreds, if not, thousands of GitHub stars every month, I knew that this project was going to be something big.

Which brings us to now, mid-way through 2018. I'm finally in a position where I can begin working on personal projects again with a stack of my choosing. The Gatsby library sitting pretty at over 25,000 GitHub Stars, 1,000 contributors, 6,000 commits, v2 looking more and more stable by the day, and an extremely healthy plugin ecosystem. If there was any time to get into Gatsby, this was for sure the best time.

So I decided to rewrite my blog site with Gatsby. That's right, the blog that you're currently reading this on.

First things first though, I had to settle what front-end stack I would be using.

The Stack

For anybody who has been following me on social, you probably already know I'm a huge fan of styled-components. It was another library that I was an early adopter on because I saw the potential in it and absolutely fell in love with the API. So I knew that was going to be my style library. With styled-components v4 on the horizon, there was even more reason to go with it.

Other than that, there really isn't much more to the stack. Gatsby amazingly has almost every base covered. Markdown transformers, offline support, PWA support, and lots of plugins to help with accessibility and SEO.

Knowing that, it was time to dive into actually creating my site.

First Impressions

Funny enough, I jumped the gun a little bit with that tweet. In the next few tweets in that thread, I had apparently been reacting to Gatsby v1 instead of v2. :man_facepalming: It was nobody's fault but my own, since I confidently skimmed over the line in the ReadMe that said...

Want to try v2 beta? Run this instead: gatsby new my-blazing-fast-site https://github.com/gatsbyjs/gatsby-starter-default#v2

I soon realized my mistake after commenting in an issue thread related to styled-components v4 not working in Gatsby. Turns out, however, that there were some issues with styled-components v4 not functioning properly in Gatsby v2. At the time of writing this, the issues have been ironed out via styled-components@4.0.0-beta.3. Evan Jacobs was very responsive in that thread and had the problems resolved within a day. So hats off to you, Evan!

Backtracking a bit back to that tweet though, what I said was still valid. If you don't want to install gatsby-cli globally to start projects, you can quickly create projects using the latest cli version by using npx. Here's a small example of what that would look like:

npx gatsby-cli new projectname https://github.com/gatsbyjs/gatsby-starter-default#v2

It's not mandatory, but it's a nice trick for starting new Gatsby projects with zero installs required.

Moving on...

I'm very finicky when it comes to the folder structure, so I was very pleased with the default structure in the starters. I did deviate a bit after working on building out my blog, but that's what is great about Gatsby, you're not bound to anything. You can check out the folder structure I ended up using for my blog in the repo.

The Developer Experience

I was coming into Gatsby like a full-blown newbie. I had admittedly never gave GraphQL a try. I know that's slightly embarrassing to say as a full-time front-end developer, but that's just the way things have worked out for me. But I knew it was high time to get some experience using it.

It was recommended in the official docs to check out the How To GraphQL series, so I turned it on, sat back, and listened. I already had very extensive experience with REST, so after watching the first two videos, I learned all I needed to about the fundamentals of GraphQL. If you're somebody who's new to the concepts of REST or APIs in general, it's probably a good idea to sit through the whole series. But alas, I was confident and anxious to start hacking away at my Gatsby blog.

Following along to part 5 of the official Gatsby tutorial series, my mind was thoroughly blown.

As an outsider, I was confused when I first heard of Kyle's plans to leverage GraphQL in Gatsby. I hadn't fully understood where the benefit would be, considering that it's a static site generator.

But boy was I wrong!

"This changes everything", I quietly thought to myself. I had been a long time user of static site generators like Jekyll and Hugo, but I never realized how beneficial it would be to have a data layer that you could flexibly query.

It was an absolute breeze to add in a post loop to my main page and then a single post page. At this point, I was not only thoroughly invested in Gatsby, but I was also ready to rebuild all my personal projects with Gatsby.

Although that will be done over time, I'm sure... —I said sarcastically to myself, knowing full well that I was going to start rewriting things in Gatsby as soon as this blog post goes live)

Performance

When it came time to run that juicy gatsby build command, I was anxious to see how performant it would be. I had previously seen lots of lighthouse screenshots boasting high numbers, but I was expecting to have to put in a bit of work to get there.

But I was wrong. With zero efforts to optimize anything, my compiled and hosted blog was getting near-perfect scores.

gatsby lighthouse score

With numbers like those, there are almost zero reasons to further optimize or even worry about performance. I was (and still am) totally blown away with the sheer speed of the sites outputted by Gatsby.

Concluding Thoughts

Honestly, I just want to take this time to sincerely thank everybody who has contributed to this wonderful static site generator. I don't think I've been this excited for anything JavaScript related since I first discovered React. Considering that this is just v2, I am thoroughly excited to see what the future will bring for Gatsby. But one thing is for sure, I will be using Gatsby in as many projects as I can.

Next up on my list: Build a complex Single-Page-App with Gatsby.


If you like what I've written or what I build and you think I'd be a good fit for your team, drop me an email: hi@garet.io. I'm currently seeking full-time or contract work in anything related to front-end development.

Thanks for reading,

—Garet