Static site generators are having a moment. Gatsby, the React-based SSG, is growing fast. Netlify is building a business around static hosting. The term "JAMstack" (JavaScript, APIs, Markup) is catching on. After years of everything being a server-rendered app, we're rediscovering that static HTML is often the right answer.
What Gatsby Does
Gatsby generates static websites using React and GraphQL. Write components, query data, run the build, and get plain HTML/CSS/JS files. Deploy anywhere—no server needed.
import React from 'react';
import { graphql } from 'gatsby';
export default function BlogPost({ data }) {
const post = data.markdownRemark;
return (
<article>
<h1>{post.frontmatter.title}</h1>
<div dangerouslySetInnerHTML={{ __html: post.html }} />
</article>
);
}
export const query = graphql`
query($slug: String!) {
markdownRemark(fields: { slug: { eq: $slug } }) {
html
frontmatter {
title
}
}
}
`;At build time, Gatsby:
- Queries data (Markdown files, CMSs, APIs)
- Renders React components to HTML
- Generates optimized assets (code splitting, image optimization, prefetching)
- Outputs static files
The result: blazing fast sites that feel like SPAs.
The Static Site Revival
Static site generators aren't new. Jekyll (2008), Hugo (2013), and others have existed for years. But Gatsby feels different because it uses modern JavaScript:
- React components instead of templates
- GraphQL instead of global variables
- webpack for bundling and optimization
- Progressive web app features out of the box
This appeals to JavaScript developers who want to use familiar tools for content sites.
JAMstack Architecture
The JAMstack philosophy: JavaScript, APIs, and Markup. No servers, no databases, no runtime rendering.
JavaScript: Client-side interactivity (React, Vue, etc.) APIs: Backend services called via HTTP (Stripe, Auth0, headless CMSs) Markup: Pre-rendered HTML
Benefits:
- Performance: Static files served from CDN
- Security: No server to hack
- Scalability: CDNs handle traffic easily
- Cost: Hosting is cheap or free
This works for blogs, marketing sites, documentation, and many web apps.
When Static Sites Make Sense
Gatsby/JAMstack is great for:
- Blogs – Content doesn't change every second
- Documentation – Static content, fast search
- Marketing sites – Need speed for SEO and conversion
- E-commerce (with API backend) – Product catalogs are static
- Dashboards (with API backend) – UI is static, data fetched at runtime
Static doesn't work for:
- Real-time apps – Chat, live updates need servers
- User-generated content at scale – Can't rebuild on every post
- Personalized content – Every user sees different content
Most websites fall into the first category. They don't need servers.
The GraphQL Angle
Gatsby's use of GraphQL is interesting. At build time, you query all data sources (Markdown, CMSs, APIs) via a unified GraphQL schema.
{
allMarkdownRemark(sort: { fields: [frontmatter___date], order: DESC }) {
edges {
node {
frontmatter {
title
date
}
fields {
slug
}
}
}
}
}This unifies disparate data sources. Whether content comes from Markdown files, WordPress, or Contentful, you query it the same way.
The build-time GraphQL pattern is unique. It's not a runtime API (like typical GraphQL). It's a data fetching layer for static generation.
Performance Wins
Gatsby optimizes aggressively:
Code splitting – Each page gets its own bundle, lazy loads others Prefetching – Links are prefetched on hover Image optimization – Automatic lazy loading, blur-up, WebP Inline critical CSS – Above-the-fold CSS inlined, rest async loaded Service worker – Offline support by default
The result: Lighthouse scores of 95-100 without effort. This matters for SEO, conversion, and user experience.
The Headless CMS Trend
Gatsby pairs well with headless CMSs (Contentful, Prismic, Sanity). Non-technical users edit content in a CMS, developers build the frontend with Gatsby, and deployments are triggered on content changes.
This separates concerns:
- Content editors: Use familiar CMS interface
- Developers: Build with modern JavaScript
- Site: Gets performance benefits of static generation
Traditional WordPress sites are slow because they render on every request. Headless WordPress + Gatsby gives you WordPress's editing experience with static site performance.
Netlify and the Deployment Story
Netlify has made deploying static sites trivial:
- Push to Git
- Netlify builds and deploys automatically
- CDN distribution worldwide
- HTTPS by default
- Atomic deploys (no downtime)
Free tier is generous. This is how static hosting should work.
Gatsby + Netlify is a common pairing. The deployment story is a huge part of JAMstack's appeal.
The Build Time Trade-off
The downside of static generation: build times. Every content change requires a full rebuild. For small sites (hundreds of pages), this takes seconds. For large sites (thousands of pages), it can take minutes or hours.
Gatsby is working on incremental builds, but it's not solved yet. If you're publishing content 50 times a day, static generation might not scale.
The trade-off: runtime performance vs build time. For most sites, the trade-off is worth it.
Compared to Next.js
Next.js (React SSR framework) and Gatsby both use React but serve different needs:
Gatsby (Static Site Generator):
- Pre-renders everything at build time
- No server needed
- Fastest runtime performance
- Best for content sites
Next.js (Server-Side Rendering):
- Renders on each request
- Requires Node.js server
- Handles dynamic content easily
- Best for apps with user-specific data
You can use Next.js for static export, but Gatsby is optimized for that use case.
The Ecosystem
Gatsby's plugin ecosystem is growing:
- Source plugins (pull data from CMSs, APIs, files)
- Transformer plugins (process Markdown, images, etc.)
- SEO plugins (sitemaps, RSS, meta tags)
- Analytics plugins (Google Analytics, etc.)
The plugin architecture makes Gatsby extensible without being overwhelming.
Should You Use Gatsby?
Use Gatsby if:
- You're building a content site (blog, docs, marketing)
- You want React + modern JavaScript
- Performance is a priority
- You like GraphQL or want to learn it
Don't use Gatsby if:
- You need server-side rendering for dynamic content
- Build times matter more than runtime performance
- Your team doesn't know React/GraphQL
For many projects, Gatsby is the right choice. For others, a simpler SSG (Hugo, Jekyll) or an SSR framework (Next.js) fits better.
The Bigger Picture
The static site renaissance is part of a larger trend: moving computation from servers to build time and client-side.
- Old way: Server renders every request
- New way: Build time pre-renders, client-side handles interactivity
This works because:
- CDNs are fast and cheap
- Client devices are powerful
- Most sites don't need real-time rendering
JAMstack is a return to static HTML, but with modern tooling and developer experience.
Practical Recommendations
To try Gatsby:
npm install -g gatsby-cli
gatsby new my-site
cd my-site
gatsby developBuild a simple blog. If you like it, migrate a real project.
For most content sites, the performance and developer experience improvements are worth the learning curve.
For documentation and resources, see the Gatsby tutorial and JAMstack resources.
