Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby? — Smashing Magazine

Gatsby in the Modern Web Stack

In this episode of the Smashing Podcast, host Drew McLellan sits down with Marcy Sutton to unpack what Gatsby is and where it belongs in front-end development. Gatsby is most commonly described as a static site generator, but that label undersells how it works and what it brings to a project. Sutton helps clarify the distinction between a plain static builder and the data-driven, build-time rendering Gatsby actually performs.

Beyond Static Sites

At its core, Gatsby is a React-based framework that compiles your site into static HTML at build time. The key advantage over a simpler static generator is the data layer. Gatsby can pull content from multiple sources — Markdown files, a headless CMS, or any external API — consolidate that content through GraphQL, and then feed it into your pages as they are generated. What you ship to the browser is pre-rendered HTML and assets, but the authoring experience is that of a dynamic, component-driven application.

Sutton emphasizes that the static output doesn't mean the sites are static in behavior. Once the HTML loads, Gatsby enables full client-side rehydration. That means users get the performance and reliability of cached, static files, but once the JavaScript boots, the site behaves like a single-page application — no full page reloads for navigation, smooth transitions, and instant response to interactions. This hybrid model is what makes Gatsby a popular pick for content sites that also need interactive features.

The gatsby build command is where the magic happens. Gatsby crawls your site's route tree, executes the GraphQL queries on each page, and outputs all the necessary HTML, CSS, and JavaScript. For large projects, that sort of compilation can take a while, which is why Gatsby provides incremental builds that only recompile the pages you've changed rather than regenerating everything from scratch.

Fit in the Development Stack

Gatsby is not an "all-in-one" platform like a CMS or an app server. Sutton likens it to the "JAMstack" model, where the architecture makes heavy use of client-side JavaScript, reusable APIs, and prebuilt Markup. The role Gatsby plays in a stack is to take over the front-end presentation layer and the build pipeline, while the content and business logic live elsewhere — in a CMS that sends data via GraphQL or in third-party services integrated via serverless functions.

This architecture is appealing if you care about performance out of the box. Gatsby applies aggressive optimizations by default: code splitting, lazy loading, image optimization, and inlining critical CSS. The developer doesn't need to hand-tune those details; the defaults are good enough for a solid Lighthouse score. For accessibility and security, serving mostly static files removes a great deal of server-side attack surface that traditional server-rendered applications contend with.

The flip side is the learning curve. If your team has not worked with React, GraphQL, or the concept of a headless content architecture, there's more to absorb. Sutton notes that the Gatsby ecosystem is large, and quite a bit of "glue logic" — setting up data sources, configuring plugins, picking a styling solution — is still required even though the generator automates a lot of the output.

When to Choose Gatsby

Gatsby tends to shine in scenarios where your content is already structured or can be easily fetched from headless sources, and where performance and security matter more than needing a fully dynamic, request-time application experience. It is less ideal for extremely user-specific, state-heavy applications like a real-time dashboard or a startup that requires active database updates on every visit. For a blog, an e-commerce storefront, a documentation hub, or a portfolio — Gatsby is positioned as a modern, efficient choice.

For those new to the idea of moving away from a traditional CMS, Gatsby introduces concepts that require comfort with modern tooling. But Sutton's experience suggests the community support and the production quality of the sites span a wide range of needs. The full conversation covers her impressions of the developer experience, the value of Gatsby for accessibility enthusiasts, and the state of tooling for front-end development.

What Gatsby Actually Is

Gatsby is a website generator built on React. At build time it compiles React components into static HTML files that load quickly for users. When JavaScript is enabled, that static site then “rehydrates” into a full React application, giving developers the performance of a static site and the interactivity of a client-side app. For Marcy Sutton, lead engineer on Gatsby’s Developer Relations team, that dual nature is the core appeal. “You really get the best of both worlds with fast builds that you’re compiling HTML files that will load fast for users,” she explains.

That architecture matters for accessibility too. Sutton, who previously worked on the axe-core accessibility testing library and as an accessibility engineer at Adobe, sees a JavaScript-heavy framework as a place where accessibility awareness can reach more developers. “Working on one site is cool. You can solve some really interesting problems,” she says. “For me, I wanted to advocate accessibility much more broadly and try to make frameworks the best they can be from the inside.”

Static Generation With a Client-Side Layer

Unlike traditional static site generators that produce only HTML files, Gatsby ships a JavaScript layer that handles client-side routing. Gatsby currently uses Reach Router under the hood with its own implementation. On first load, the HTML files are present — so even if a user has JavaScript disabled, the content is still there. When JavaScript is enabled, a hydration step kicks in. Links in a Gatsby site will pre-fetch resources from the target page, making navigation faster.

Sutton notes that this behavior is largely automatic through the Gatsby Link component, which outputs real anchor tags so the HTML remains valid. Pre-fetching is tied to user interaction: scrolling into the viewport or hovering over a link triggers the fetch. The team is actively discussing whether keyboard focus should also trigger pre-fetching, an intersection of accessibility and performance that Sutton finds particularly interesting.

“Should a keyboard user who can’t use the mouse and is tabbing through every link to navigate, should that really be fetching content for every single one of those because a mouse user might be a bit more selective about where they put their mouse cursor?”

Developers can opt out of the pre-fetching behavior by using regular anchor tags instead of Gatsby Link, and they can replace components with their own as long as they work with the React runtime. Gatsby is not prescriptive about UI code; anything that fits in a React app generally fits in a Gatsby app.

Performance Defaults and Trade-Offs

Performance is a stated focus for Gatsby, but Sutton is careful to say that much of it comes down to what you bundle. JAMstack sites can be fast by nature, but “no matter what framework or tool you’re using, we still have to be thoughtful in what we’re putting in those bundles for end users.” Gatsby’s aim is good defaults, including the pre-fetching and built-in support for progressive web app features like offline capabilities and manifests.

Sutton says the team continually evaluates whether those defaults are still the right call. “Do we have the data to back that up? That’s the kind of thing as a developer advocate that I’m super interested in, is making sure that what we’re packaging and bundling on websites is actually needed and will really make the best Gatsby site it can make.”

The GraphQL Data Layer and Plugin Ecosystem

What distinguishes Gatsby from a generator like Jekyll or Eleventy is its GraphQL data layer. Combined with a rich plugin ecosystem, that makes sourcing content from WordPress, Drupal, Prismic, markdown files in GitHub repos, or other APIs largely a matter of installing the right plugin rather than writing custom glue code.

Sutton says the GraphQL layer is what makes these integrations possible, and writing plugins is made approachable through Gatsby’s abstraction over an Abstract Syntax Tree (AST). Beyond plugins, Gatsby themes bundle together UI code, GraphQL queries, and configuration — essentially a plugin with its usage pre-packaged and distributable via NPM. Themes are not just about look and feel, unlike in a CMS like WordPress.

“It’s like a plugin with usage kind of bundled together,” Sutton describes. For teams with multiple repositories that would otherwise duplicate the same source queries and configuration, themes reduce repetition. She points to a case study from Apollo that used Gatsby themes along with a Git source plugin to build a documentation site decoupled across repos. Gatsby is actively overhauling its own core themes, with improvements slated for release in the near future.

Content Management and the Cloud Product

For client work, the question of content editing inevitably comes up. Sutton acknowledges that handing a marketer a GitHub repository usually fails. “You see this glaze over from the client of like, ‘No, I can’t believe you just said that.’” Having a CMS gives content authors a familiar environment, but a headless architecture removes the built-in front-end preview that tools like WordPress provide.

That gap is where Gatsby Cloud enters. Sutton describes it as a continuous delivery product rather than a CDN; it handles builds on Gatsby’s infrastructure and can deploy the output to providers like Netlify or Fastly. Gatsby Cloud offers previews and a free tier for personal projects. Because it only needs to build Gatsby sites, it can make optimizations that a more general platform cannot.

The company relationship mirrors precedents like WordPress and Automattic or Drupal’s founding organization. Sutton says Gatsby is working on publishing governance documentation to clarify decision-making, with the goal of keeping the open source project sustainable without locking users into the commercial product.

Learning Resources and the Community

Gatsby’s community is large and diverse, with many people using it as their first introduction to React or to open source contribution. For learning, Sutton recommends the Gatsby Docs at gatsbyjs.org/docs, which are actively maintained, plus tutorials and her own live streams. She cautions that third-party videos can age quickly; Gatsby is evolving fast enough that even its own team struggles to keep materials current.

Sutton recently ran a course called Gatsby Web Creators that started with basic HTML, CSS, and JavaScript and worked up to building a full Gatsby site. Outreach to younger learners became a priority for her in 2020, in part as a response to the disruption of the school year. She shares positive feedback: “I got some feedback from someone that said, ‘My seventh grader’s learning from you, and now they’re really excited about code.’”

Front-End Frameworks and Accessibility

Sutton acknowledges the data showing that sites built with front-end frameworks are often less accessible than those without. Projects like Web a Million, which crawl top home pages for accessibility violations, paint a bleak picture. But she argues that blaming a single framework is too simple. Plenty of sites without frameworks also fail accessibility tests.

Her stance is pragmatic: “You need some JavaScript to make accessible user interfaces, you just do.” Rather than abandoning JavaScript-heavy architecture, she wants the Gatsby team to improve defaults — and as a developer advocate, to act as a messenger between community concerns and the framework’s roadmap. That means making deliberate trade-offs between factors like performance and accessibility, and listening to users about what is painful today.

What Comes Next

Asked whether Gatsby might support frameworks other than React — a Vue version, for instance — Sutton is open but cautious. “I would love a view flavor, that’d be amazing,” she says, but the sustainability concerns are real. Supporting two frameworks means maintaining two implementations, and decisions like that cannot be made lightly. She confirms the team is actively discussing the possibility, though she has no specifics to share yet.

In the meantime, Gatsby Documentation’s resource page is a good path for newcomers. Sutton’s own advice is more general: “Make the most of it wherever that might be.”