Why I Finally Moved On From Gatsby
For years, Gatsby was my default rendering framework. I used it for everything, from tiny sites to over-engineered projects, and I was confident in that choice because I was getting perfect Lighthouse scores in the process. But over time, the relationship soured. I found myself constantly fighting plugins, applying hacky workarounds, and waiting longer and longer for the dev server to start. It began to feel like I was fixing more than I was building. Starting a Gatsby project became tedious, and perfect performance scores could no longer compensate for that friction.
This past Valentine's Day, I wanted to launch a simple site where people could send anonymous letters through a personal link. Time was tight, so I made the difficult decision to skip Gatsby entirely and build a single-page application with Vite and React instead. To my surprise, that combination was far more efficient than expected while maintaining nearly the same great performance measures. It was a hard conclusion to swallow after years of loyalty.
Where Gatsby Stumbled
Kyle Mathews began work on Gatsby in late 2015, and the framework quickly gained traction thanks to its unique data layer and static site generation approach. It raised a $3.8 million seed round in 2018 and became a frontrunner in the Jamstack community. So where did it go wrong?
Many point to the introduction of Gatsby Cloud in 2019. As Gatsby aimed to build a sustainable business model, the core framework was optimized to work seamlessly with this proprietary cloud — which, in practice, made deployments elsewhere far more difficult. Documentation for third-party hosting was neglected, and exclusive features like incremental builds were reserved for Gatsby Cloud customers. Hosting anywhere else felt like being penalized.
Meanwhile, Next.js was winning developers' hearts and minds, both in surveys and npm trends. Gatsby Cloud struggled to compete with Vercel and Netlify, and in February 2023, Netlify acquired Gatsby. Netlify's CEO, Matt Biilmann, later acknowledged that Gatsby wasn't winning the framework battle, admitting they were "probably a bit boxed in" by competitors in the platform space.
The acquisition was messy for existing customers. Some teams were charged up to 120% more after migrating to Netlify, or faced unexpected fees. Key Gatsby Cloud features, particularly incremental builds that cut build times from minutes to seconds, weren't ported over as promised. Six months after the acquisition, a Netlify support engineer stated there were no plans to add those incremental features — directly contradicting Kyle Mathews's earlier public assurances. One comment from a Netlify forum thread captured the community's frustration well:
"Yikes. Huge blow to Gatsby Cloud customers. The incremental build speed was exactly why we switched from Netlify to Gatsby Cloud in the first place. It's really unfortunate to be forced to migrate while simultaneously introducing a huge regression in performance and experience."
The acquisition also led to significant layoffs in Gatsby's engineering team and a complete halt in commit activity. These factors show up clearly in the 2023 Stack Overflow developer survey, and the likelihood of developers choosing Gatsby again for future projects plummeted from 89% to 38% between 2019 and 2022, according to the State of JavaScript survey. While Gatsby was still the second most-used rendering framework as of 2022, my expectation is that the decline will continue.
Gatsby's New Direction
In an open issue on the Gatsby repository, Biilmann addressed community concerns about the framework's future. Netlify doesn't plan for Gatsby to lead innovation in the framework ecosystem, but rather to keep it a "safe, robust and reliable choice" for production websites and e-commerce stores. The stated roadmap focuses on three areas: ensuring stability and good performance, integrating with Netlify's broader Composable Web Platform, and opening up Gatsby by decoupling parts tied to proprietary cloud infrastructure — starting with the Adapters feature.
Gatsby has essentially given up competing with Next.js on new functionality. Instead, it will focus on keeping the existing framework stable and clean. Given everything that's happened, that seems like the most sensible path forward — but it's no longer the path I need to follow. I still believe Gatsby is valuable for certain types of projects, but my personal tooling choices have moved on.
What Pushed Developers Away From Gatsby
Gatsby Cloud’s abrupt shutdown was the final straw for many, but the framework itself had been losing favor for a while. Two issues stand out as the main culprits: dependency hell and slow build times.
Dependency Hell
Starting a fresh Gatsby project pulls in a staggering number of packages.
gatsby new
After the initial setup, running npm audit reveals a long list of warnings and vulnerabilities:
18 vulnerabilities (11 moderate, 6 high, 1 critical)
Those warnings are misleading from a security standpoint—a static site has no server-side attack surface, so most of those issues never reach end users. But they point to a deeper problem: Gatsby depends on an enormous number of outdated packages. At the time of writing, a Gatsby project brings in 168 dependencies, compared to just 16 for Next.js.
The real pain comes when you try to update any of those packages. Many are pinned to outdated versions of other libraries that can’t be upgraded without breaking something else. It’s a tangled web of interdependencies where you’re locked out of updates entirely.
That situation has not improved as of March 2024.
Slow Build And Development Times
For me, the most critical factor in choosing a framework is how it feels to work with daily. Gatsby’s development server is getting harder to tolerate: cold starts take upward of 30 seconds, and the server gets slower the longer it runs. Restarting it is required whenever you touch gatsby-config.js, gatsby-node.js, or any data source.
Compare that to a Vite.js + React setup, which can spin up a server in about 500ms thanks to esbuild:
Production builds are worse. Larger projects naturally take minutes, but even a small content change triggers a full rebuild and deployment. That’s exactly what incremental builds were meant to fix—and why many developers migrated from Netlify to Gatsby Cloud. With Gatsby Cloud gone, the case for putting up with slow builds all but disappears.
What Gatsby Still Gets Right
Despite those frustrations, Gatsby still offers things that other frameworks don’t. It just isn’t the general-purpose tool it was marketed as. In specific use cases, it remains excellent:
- The GraphQL data layer. All configured data sources are available in one place, queryable from any component. That makes generating static pages from a CMS or Markdown files almost trivial.
- Client performance. Developer experience aside, Gatsby delivers some of the fastest page loads around. Static pages, pre-rendered links via React Router, and a first-rate image optimization API combine for a genuinely smooth user experience.
- The plugin ecosystem — with caveats. There’s typically a plugin for every CMS. The problem is that many have gone unmaintained, pulling in the dependency conflicts mentioned earlier.
The issues that drove users away aren’t documented; they surface only through experience. Individually they’re manageable, but together they compound into a tedious workflow that sends developers looking elsewhere.
Is SSR Or SSG Even Necessary?
I’m not replacing Gatsby with Next.js or Remix—I’m avoiding rendering frameworks altogether in many cases. That’s because they only matter for two reasons: search crawling and initial load time.
SEO And Crawling Bots
Client-rendered React apps start with an empty <div> until JavaScript runs in the browser. Years ago, search engine bots couldn’t execute JavaScript and would see nothing to crawl.
<body>
<div id="root"></div>
<script type="module" src="https://www.smashingmagazine.com/src/main.tsx"></script>
</body>
That’s no longer true. Google can run JavaScript and index content, and most other major engines have followed suit. Pre-rendered HTML does get indexed faster, but it’s a tradeoff you can make selectively—or handle on your hosting platform with pre-rendering services.
Initial Loading Time
Static pages load faster because the browser skips the JavaScript execution step. That matters most for application pages, not a pure marketing site.
My React + Vite.js single-page application scored a perfect Lighthouse result on the landing page, and pages behind authentication scored near-perfect Core Web Vitals. Using a rendering framework instead would have gained almost nothing.
Where Gatsby Still Shines
Gatsby and similar frameworks are best for programmatically generating pages from structured data—blogs, documentation, and e-commerce. If that’s your project, Gatsby is still a fine choice.
But how do you decide? If you already know Gatsby well, switching to another framework carries an opportunity cost: the time you’d spend learning new tooling outweighs the performance gains. That’s why I chose Vite.js + React for my latest work—it minimizes that cost while avoiding Gatsby’s DX problems.
Final Thoughts
Is Gatsby dead? Far from it. The loss of Gatsby Cloud hurt, and there are few active commits to the repository, but Netlify isn’t about to abandon it entirely.
My own path leads to Vite.js + React for most new projects. I’ll reserve rendering frameworks for the cases that genuinely need server-rendered or statically generated content. The tradeoff—a negligible performance hit in exchange for a much faster, more pleasant developer experience—is one I’m happy to take.
That said, this is my perspective after years of building with Gatsby. Your experience may differ, and I’d be interested to hear how it compares—especially if you’ve found different results in your own projects.
