DEV Community

Cover image for Taking Gatsby for a spin
Arden de Raaij
Arden de Raaij

Posted on • Updated on

Taking Gatsby for a spin

A static site generator based on React, does that even make sense? GatsbyJS tries to answer this question with a hypermodern, feature-packed, jamstacked development tool that you can try out right now! In this post I'll give you a quick introduction and an overview of my own thoughts on Gatsby.

Introducing: Gatsby

Ever since I started following the Gatsby Twitter account, I've wanted in on the action. It's not that I really need a new tool to create static sites, it's just that every developer tweeting about Gatsby seems to think it's the most exciting thing on the web since they learned they could combine the marquee and blink tag. Call it FOMO. Also, the sites that these developers have been showcasing were all so fast and snappy, I had to see what the buzz was about.

Let’s jump in. Here are some of the important features of Gatsby:

React

GatsbyJS is based on React which means that you'll be writing almost everything in JavaScript / JSX. That doesn't mean though you need loads of React experience to start out with Gatsby The tutorials are a great resource and will teach you some React along the way. If you already like React, you'll most definitely enjoy creating static sites with Gatsby. As your final JavaScript bundle includes the React library, you can include React components as if it was a regular React app.

Graphql

Gatsby was my first introduction to GraphQL and I'm loving it already. GraphQL is a query language used by Gatsby to let you connect to all kinds of APIs. With it as an abstraction layer, you can pull in all the data you can think of and utilize it in your app. Gatsby comes with plugins to pull in data from several APIs, CMS systems and local files. With GraphQL, you're able to query data from all these sources in a clear and readable way. The data is instantly available in your components and that's just super cool. Also, it comes with a browser-based IDE called Graph*i*QL which starts along with your development environment. You can use it to see which queries are available, test them out, and see what data these queries return.

Screenshot of GraphiQl

Progressive Web App and PRPL Pattern (Blazing fast)

With an eye on the future, Gatsby already implements lots of Googles so called 'Push, Render Pre-Cache and Lazy-load pattern (PRPL, I'm not sure if that acronym will catch on). Gatsby takes care of the pre-loading and code-splitting, which makes browsing around Gatsby sites an insanely fast experience. PRPL + the gatsby offline plugin mean that your site will be considered a PWA, will load insanely fast on any device and scores great in Google lighthouse. Read more on PRPL.

Webpack and Plugins

Can you say React without webpack? I can hardly say hello world without webpack anymore, although I'm still not sure how to configure it right on the first go. Gatsby comes with an extensive webpack configuration and you don't really need to touch if you don't want to. If you do, you can modify and add to the default configuration with a plugin or in the gatsby-node file. There's already a great range of plugins so most likely any webpack tweak is a plugin install away. With all the plenty of good examples, it’s often straightforward to write your own plugin too.

Community

Even though Gatsby is pretty new, the developers using it seem really involved. There are quite a few articles on the Gatsby blog. People seem to be happy to answer your Gatsby questions on Twitter and on Github you can ask anything without being shot down. Everyone is encouraged to contribute in form of plugins and pull requests, which gives me confidence that we'll see a lot of additions and improvements in the future.

Some thoughts on Gatsby

It's telling that most of the websites that are made with Gatsby are developer portfolios and documentation websites. It shows that Gatsby is still a bit in its early-adopters phase. But seeing what kind of sites are already made with Gatsby, I'm sure the future is bright. I've had a blast creating my own site with Gatsby (checkout the github repo here) and in the end it didn't take more than a weekend to complete, including doing the tutorial and experimenting with the Gatsby starters.

Some other thoughts I had while working with Gatsby:

It's fast

Gatsby definitely delivers on speed. The whole PRPL pattern thing seems to work miracles. I tried browsing the list of sites made with Gatsby with network throttling set to 'slow 3g' in Google Chrome and the performance of these sites is still impressive.

GraphQL is amazing

Data from anywhere with static output. That's sort of the holy grail isn't it? Right now the data I use in this site comes from markdown files, but I can already see that switching to another content source is going to be a breeze with GraphQL. The queries are clean and readable and the Graph*i*QL IDE is the perfect helper. In a way, GraphQL allows you to separate your front-end from the type of data source.

export const query = graphql`
    query BlogPostQuery($slug: String!) {
        markdownRemark(fields: { slug: { eq: $slug } }) {
            html
            fields {
                slug
            }
            frontmatter {
                title
                date(formatString: "DD MMMM, YYYY")
                cover {
                    childImageSharp {
                        resolutions(
                            width: 1200,
                        ) {
                            src
                        }
                    }
                }
            }
        }
    }
`;
Enter fullscreen mode Exit fullscreen mode

Deployment and content management can be so good!

After reading some articles on the Gatsby site, I decided to set up my Gatsby hosting on a free plan from Netlify (which is ridiculously generous by the way, what's the catch?) and that has been a fun experience. Netlify already supports Gatsby out of the box, which means you can configure automatic deploys with git in a few clicks. Every time I push to master, the site gets rebuild and uploaded by Netlify. Magic. There's also the possibility to configure staging servers based on your branches, so you can always test out your changes before merging to master and deploying.

But wait, there's more. If you use Contentful as Content Management System and Netlify as your host, you can easily create a Webhook to trigger a rebuild on every content update! I haven't tried this myself yet, but this posts by Fernando Poumián is a great resource to get you going.

Incremental builds aren't yet possible, so every update means a complete rebuild. I'm sure that's no cause for concern on smaller sites, but with larger sites that are updated often it could be a problem. Luckily, incremental builds will be part of Gatsby 'sooner than later', which will take care of that problem.

Gatsby Image plugin is cool

Did you see the SVG traced image before the image was loaded? If not, you're probably on Safari and I still haven't implemented the intersection observer polyfill. But in other browsers, images you add with the gatsby image component will include a blur or traced svg placeholder effect by default. It also has srcset and webp. It can use some work though it adds a few wrappers around your images that are hard to reconfigure without using !important. Oh and be warned, it uses object-fit by default, which is unsupported by IE11 and older browsers. Of course, you don't have to use this plugin and every addition / change is discussable on Github.

Keep an eye on the output

I'll start by admitting that I haven't validated the HTML of my own site yet, but I'm sure it'll need some work. I feel like the combination of JSX and using loads of React Components can make the HTML output messy real quick . Combined with the use of Gatsby plugins that also manipulate your output, I'd say it's extra important to keep an eye out on the generated code. I understand that GatsbyJS is very much about the modern web, but that's why we've got progressive enhancement.

When your favorite tool is a hammer…

Doing everything in React is a blessing and a curse. You can solve everything with JavaScript but that doesn't mean you HAVE to solve everything with JavaScript. At times I find myself in such a flow of writing just JavaScript that I tend to use it to solve problems that could have been fixed with a hover selector in CSS.

CSS in JavaScript, I can dig it.

You can use anything to style your Gatsby site; CSS, SCSS, Styled Components, CSS-in-JS, you name it. I wanted to give the whole "Use CSS in your JavaScript" a spin and chose for a library called emotion-js based on the fact that I dig the Bowie emoji on its page. After trying it out for a few days I have to admit that I really like it. Creating and styling a component in the same place is such a nice way of working. Even without the cleverness of using React state to toggle CSS values, it's a great tool. There's still some work to do considering autocomplete and syntax highlighting, but when working with components like this it makes a lot of sense.

In conclusion

I like Gatsby and I like the ideas that it promotes. The sites created with Gatsby are blazing fast, as promised. The development environment is one big party and GraphQL makes me rethink my life. I am really looking forward to develop more sites with Gatsby and I'm hoping to find an opportunity to replace a traditional WordPress install with a Gatsby site that pulls in the WP data. When that time comes, I'll report back of course.

If you have any questions based on this post, don't hesitate to contact me on Twitter or via mail. Thanks for reading!

Latest comments (23)

Collapse
 
zeptobook profile image
ZeptoBook

Here is a step by step guide about how to create your blog site using Gatsby.
zeptobook.com/create-your-blog-sit...

Collapse
 
aurelkurtula profile image
aurel kurtula

Hi

Do you know whether anyone tested how gatsby works with lost of page?

For many years I have this problem where I'm not totally satisfied with my note-taking setup. About two years or so a go I started using jekyll, it was fantastic till I wrote over 100 posts when it slowed down and lost it's goodness.

Do you know whether I'll hit the same problem with gatsby?

The idea is I want to run it locally as a way to manage personal/private notes that I write every day.

Thanks

Collapse
 
ardennl profile image
Arden de Raaij

Good question on which I don't have a definitive answer yet. As far as I can see it should be able to handle lots of pages but I haven't seen any examples yet. Let me ask around and get back to you!

Collapse
 
nickytonline profile image
Nick Taylor • Edited

The new reactjs.org site is built with Gatsby.

I don't think you'd run in to performance issues. Gatsby is a static file generator, so all your pages are pretty much just static html with whatever interactions the out of the box React components offer or custom ones you make. Here's a good write up on performance from the creator of Gatsby. Some main takeaways in Thar article in regards to Gatsby:

Thread Thread
 
ardennl profile image
Arden de Raaij • Edited

Hey Nick, thanks for your reply! I think most of us are aware of the performance of the actual static sites by Gatsby. But that wasn't the question, which is: How will Gatsby hold up when building 100's to 1000's of pages?

(to be honest, I just re-read the original post and I kinda assumed it was about building. Nowhere is it stated but it's been an issue I've had with multiple static site generators as well!)

Thread Thread
 
nickytonline profile image
Nick Taylor

Ahh, that'll teach me for responding very late at night. 😉. I'd recommend combing through other issues in the repo. There appears to be at least a few in regards to build times in there.

Having said that, the main benefit of Gatsby is a fast site, not a blazingly fast build time (within reason of course, DX is important). I use it for my blog and it works great, but it's not hundreds of pages.

Logically, I can only assume as more and more pages get added, the build time will slowly increase.

Thread Thread
 
ardennl profile image
Arden de Raaij

Haha well you might've been right, I kinda just assumed build time was the issue.

In any case, I think it would be nice to have incremental builds, something that the team is working on although I haven't heard much about it lately

Thread Thread
 
aurelkurtula profile image
aurel kurtula

@nickytonline I used to use jekyll to keep my personal notes, hence I updated it very frequently. It worked great before I got 90 posts (90 markdown files) then it was a drag. Clearly a normal blog - updated 1-3 times a week, would not feel the problem.

It be cool if Gatsby worked like "Ok there are no changes to the 90 posts, so let me build only the 99th".

Clearly it's not meant to be used for daily note-taking but it be nice to know if that's something the developers might have in the pipeline

Thread Thread
 
nickytonline profile image
Nick Taylor

According to the tweet Arden posted in this thread, it looks like you're gonna get your wish 😉

Collapse
 
emasuriano profile image
Emanuel Suriano

Great article! I always see Gatsby and think: What are the benefits comparing it with next.js? The only thing that I could think is that it has a bunch of tools built-in (for example, GraphQL) but besides that in my opinion, next.js could easily replace Gatsby.
I want to hear your opinion on this comparison: Gatsby vs next.js!

Collapse
 
ardennl profile image
Arden de Raaij

I went through the tutorial of Next.js and have a few quick observations:

  • Next.js leverages 'Universal Javascript' and can be used to create a (partially) server rendered app as well. Gatsby strictly generates static assets.
  • Gatsby.js comes with GraphQL baked in, circumventing graphQL might be difficult. Next.js has an async/await function to pre-populate your components props with data you can pull from anywhere. If you want to use GraphQL you can combine next.js with Apollo.

  • In general, Gatsby is more opinionated. It has it's own plugin ecosystem (including data handlers), aggressive pre-fetching, the whole PRPL pattern and the works. It still leaves you very free in how you write and style your components though. Especially for static site generating, Next.js is more barebone and you'll need to configure which links you want to pre-fetch and which assets you want to lazy-load.

I can't say anything on performance with building because I've yet to actually build something with Next.js yet.

Also, there's React Static, another contender in the ring. I might give that one a go as well.

Collapse
 
emasuriano profile image
Emanuel Suriano

Great answer, I agree with you.
So we can affirm that if we want to build the same application in Gatsby and next.js, we will have to put a lot more effort in the next.js one.
But in the case, we want to expand the application to have any dynamic behavior, Gatsby won't suit.

Collapse
 
ardennl profile image
Arden de Raaij

That's a great question! I've yet to have any experience with Next.js and to be honest, up until now I didn't realize what it was exactly. A comparison is a great idea and something I'll pick up soon. Thank you for the inspiration!

Collapse
 
amanmahendra889 profile image
testttt

nice

Collapse
 
amanmahendra889 profile image
testttt

test

Collapse
 
imthedeveloper profile image
ImTheDeveloper • Edited

Excellent post! I've recently been working through a JAMstack design with a client utilising the following architecture stack:

  • Netlify for build and hosting
  • Gatsby for reasons your post points out!
  • Contentful for areas where we need our dynamic CMS
  • Gitlab for code and markdown version control
  • Algolia for site wide searching
  • React for the front end
  • Jest and Nightwatch for testing

It's been utterly awesome to work with and really shows the power of the JAMstack.

Collapse
 
ardennl profile image
Arden de Raaij

That's great! I'll need to have a look at Algolia as well, and hooking it up with Contentful is the next step. Ah testing, could you maybe elaborate a bit on what and how you test? It's something I've been actively ignoring so far and I know that's not good.

But I agree, the JAMstack is an excellent concept and makes projects a lot of fun to work with. I'm looking forward to integrate it more in my professional environment.

Collapse
 
imthedeveloper profile image
ImTheDeveloper

We will be using Jest and enzyme for our basic testing. There's a nice overview of that here: hackernoon.com/testing-react-compo...

We are also looking into using nightwatch / phantom / casper (we aren't fully committed to one of these yet so its up for debate) to automate the testing of some our mission critical customer journeys through out website. The client has quite a large testing team which focus their testing mainly on the mobile app, but they haven't really had the website as part of their scope historically. Whilst this seems like a missed opportunity to utilise them as a resource for web testing, it is also actually leaving us with optionality. I would much prefer to have automated unit, integration and to an extent our pre-canned UAT tests. The human eye should really only be cast over some of the newer components we release, with everything else checking/failing before or during our build pipeline.

We created our initial site using graphQL, Gatsby and Markdown. The switch to Contentful instead of Markdown was a breeze when we had all of the graphQL queries already modelling what we needed.

Collapse
 
seanpowell profile image
Sean Powell

Likewise. I’ve been working in a similar stack. It really is amazing to work with. Now, we’re just starting to use Netlify’s open source CMS which uses git to handle content versioning. Did you guys look at that at all before picking Contentful? I think Contentful looks awesome too, just curious if there were any pros/cons between the two.

Collapse
 
imthedeveloper profile image
ImTheDeveloper

I think there are a few nice perks, such as visualising the models you produce as well as the media library aspects. End of the day it felt a bit more friendly for the marketing guys to understand and use (They arent changing or configuring YAML). The developer team were happy to use either and I think if you are working with a pure dev team then there is no issue using Netlify openCMS, but where there are "business" users involved, the confluent UI proves to give the right level of abstraction away from coding (Yes even markdown files scares some people!). It also feels a lot closer to the traditional CMS for content creation, they like to see the layout and previews, images rendered before fully publishing etc.

We also found the pricing model at contentful to be really friendly, to set up a proof of concept and allow the business users to mess around creating their content with the benefits mentioned in the previous paragraph made it an easy sell when it came to moving into a small subscription. There's also the support model wrapped around all of this and since the content is served over multiple channels, the internal due diligence from service management and security teams forced our hand to an extent to keep away from a self hosted open source product.

Collapse
 
aurelkurtula profile image
aurel kurtula

A very nice post. I'll definitely play with Gatsby soon

Collapse
 
ben profile image
Ben Halpern

This got me really into Gatsby. I'm pretty familiar with all of the Gatsby tech independently, but even though I knew what it was, I never took the time to look this closely at it. Thanks for the post.

Collapse
 
ardennl profile image
Arden de Raaij

That's awesome, you're welcome! It took me a while to pick up Gatsby as well but as I mentioned I found it really hard to ignore all the happy developers. Since I do enjoy working with React it was really easy to get into and the experience has been stellar so far! I'll do some more technical posts on Gatsby soon.