It all started with a single tweet...
Been meaning to give @gatsbyjs v2 a serious evaluation for the past few months (last time I used it was late-2016), I think today is finally the day I'm going to rebuild my blog with it.— Garet Eliot (@gareteliot) September 8, 2018
I'll be live tweeting my experience in this thread 😇
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.
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: the cli tool is very reminiscent of CRA. Can't remember whether the early version I tried had such a tool (I think I remember having to manually clone one of the "starters" to work on it).— Garet Eliot (@gareteliot) September 8, 2018
Combined with npx, it's a great experience getting up and running!
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
email@example.com. 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.
I quite like the folder structure of the default starter! I know structures are incredibly subjective, but they're nice and concise leaving zero room for wondering where things should go. I also like the fact that you're not bound to this structure AFAICT— Garet Eliot (@gareteliot) September 8, 2018
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.
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.
Wow, this part of the tutorial really blew me away 🤯— Garet Eliot (@gareteliot) September 8, 2018
My head is spinning thinking about all the possibilities with Gatsby. I'm starting to fully grasp just why this library is such a big deal.https://t.co/WMRVAPFujX
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)
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.
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.
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: firstname.lastname@example.org. I'm currently seeking full-time or contract work in anything related to front-end development.
Thanks for reading,