We spent years telling people to build static sites with Gatsby. Gatsby is now in maintenance mode, the "Jamstack" label that framed the whole category was retired by Netlify itself in 2023, and the frameworks that replaced it blur the line between static and dynamic rendering. So it is a fair question: do you still need a static site generator in 2026, or was that a phase?
Short answer: static-first is still the right default for most content sites, but "static site generator" is no longer a category you choose from a list. It is a rendering mode that the major frameworks all offer. Here is how we think about it when a client asks.
What "static" buys you, still
The arguments for pre-rendered HTML have not changed, and they are still good:
- Speed. HTML served from a CDN edge is the fastest thing a browser can receive. No origin round trip, no database query, no cold start.
- Reliability. There is nothing to go down. A static deploy keeps serving during a traffic spike, a database outage, or a vendor incident.
- Security. No server-side code running per request means no injection surface per request. The attack surface is the build pipeline and the CDN, both of which are easier to lock down.
- Cost. Static hosting is close to free at low traffic and cheap at high traffic.
What changed is that you no longer have to choose static for the entire site. Every serious framework now lets you render some routes at build time, some on demand, and some at the edge, within one codebase.
The 2026 landscape, honestly
Astro is the default choice for content-led sites in 2026. It renders to static HTML by default, ships zero JavaScript unless you opt a component in as an island, supports React, Vue, Svelte, and Solid components side by side, and its content collections handle markdown, MDX, and remote CMS data with schema validation. Astro 5's content layer and server islands mean it also handles the "mostly static with a few dynamic bits" case without a separate framework. If a client's site is marketing pages, docs, and a blog, we recommend Astro without much debate.
Next.js is the default for application-shaped sites. Static generation is one rendering mode among several (static, dynamic, streaming, partial prerendering), and the App Router's server components make it practical to keep most of a site static while the authenticated or personalised parts stay dynamic. If the site shares a component library with a product, or has a logged-in experience, Next.js usually wins. It is heavier than Astro for a pure content site, and you pay for that in shipped JavaScript unless you are disciplined.
Eleventy is the "just a static site generator" option: JavaScript-based, no framework, no client-side runtime unless you add one, very fast builds. Excellent for documentation, small business sites, and anyone who finds Astro's component model more than they need. 11ty.dev is the place to start.
Hugo is the fastest builder of the lot, written in Go, with a template language that is not JavaScript. Strong fit for very large content sites (tens of thousands of pages) and for teams without a JavaScript front-end practice. gohugo.io covers it.
Gatsby still works, and a maintained Gatsby 5 site is not an emergency. But Netlify acquired Gatsby Inc. in February 2023, shut down Gatsby Cloud in September 2023, and the framework has had no major release since Gatsby 5 in November 2022. Its GraphQL data layer, which was its distinguishing idea, is now the thing that makes it hardest to maintain: every source becomes a plugin, and plugins need maintainers. Our advice in 2026 is to keep existing Gatsby sites healthy and to not start new ones; when a site needs real new work, migrate it.
When static-first still wins outright
Static-first is the right architecture when most pages are the same for everyone and change less often than they are read. That covers:
- Marketing and brand sites
- Documentation
- Blogs and editorial content
- Product catalogues that update on a publishing cadence rather than per request
- Landing-page fleets, where hundreds of similar pages are generated from data
For these, the combination of a static-first framework, a headless CMS, and a CDN host is faster, cheaper, and more robust than a server-rendered CMS, and it is what we build.
When it does not
Static-first stops being the answer when pages depend on who is asking or on data that changes per request:
- Logged-in dashboards and account areas
- Search results and filtered listings over large datasets
- Real-time inventory or pricing
- Anything with per-user personalisation above the fold
None of these rule out Astro or Next.js; both render dynamically when asked. They rule out the idea that the whole site is a static build, and they push the decision towards a framework with a strong dynamic story, which in practice means Next.js for most teams.
The questions we actually ask
When a client asks "should this be static?", the discussion comes down to a short list:
- What fraction of page views are to pages that are the same for everyone? If it is most of them, static-first.
- How often does content change, and who changes it? Publishing cadence suits builds; per-request data does not. A CMS with webhooks makes "rebuild on publish" painless.
- Is there a product or app sharing components? If yes, Next.js; if no, Astro or Eleventy.
- How big is the site? Past a few tens of thousands of pages, build time matters and Hugo or Astro with incremental strategies come into the conversation.
- What does the team already know? A team that writes React should not be asked to learn Go templates to save a minute of build time.
Where that leaves Gatsby sites
If you have a Gatsby site today, the question is not "static or dynamic" but "maintain or migrate". Static-first was the right call when the site was built, and it still is; the framework underneath it is the part that has aged. A migration to Astro keeps everything that made the site static and fast and removes the GraphQL plugin layer that now makes it fragile. That is usually a smaller project than teams fear, because the content and the design survive intact.
We are happy to argue the case for your specific site. Contact us and we will tell you which of the above we would pick and why.