{"id":635,"date":"2024-03-06T07:00:00","date_gmt":"2024-03-06T08:00:00","guid":{"rendered":"https:\/\/francecourier.com\/?p=635"},"modified":"2025-06-20T10:58:11","modified_gmt":"2025-06-20T10:58:11","slug":"the-end-of-my-gatsby-journey","status":"publish","type":"post","link":"https:\/\/francecourier.com\/index.php\/2024\/03\/06\/the-end-of-my-gatsby-journey\/","title":{"rendered":"The End Of My Gatsby Journey"},"content":{"rendered":"<p>              <title>The End Of My Gatsby Journey<\/title><\/p>\n<article>\n<header>\n<h1>The End Of My Gatsby Journey<\/h1>\n<address>Juan Diego Rodr\u00edguez<\/address>\n<p>                  2024-03-06T08:00:00+00:00<br \/>\n                  2025-06-20T10:32:35+00:00<br \/>\n                <\/header>\n<p>A fun fact about me is that my birthday is on Valentine\u2019s Day. This year, I wanted to celebrate by launching a simple website that lets people receive anonymous letters through a personal link. The idea came up to me at the beginning of February, so I wanted to finish the project as soon as possible since time was of the essence.<\/p>\n<p>Having that in mind, I decided not to do SSR\/SSG with Gatsby for the project but rather go with a single-page application (SPA) using Vite and React \u2014 a rather hard decision considering my extensive experience with Gatsby. Years ago, when I started using React and learning more and more about today\u2019s <a href=\"https:\/\/www.smashingmagazine.com\/2024\/02\/web-development-getting-too-complex\/#comments-web-development-getting-too-complex\">intricate web landscape<\/a>, I picked up <a href=\"https:\/\/gatsbyjs.com\/\">Gatsby.js<\/a> as my render framework of choice because SSR\/SSG was necessary for every website, right?<\/p>\n<p>I used it for <em>everything<\/em>, from the most basic website to the most over-engineered project. I absolutely loved it and thought it was the best tool, and I was incredibly confident in my decision since I was getting perfect Lighthouse scores in the process.<\/p>\n<p>The years passed, and I found myself constantly fighting with Gatsby plugins, resorting to <em>hacky<\/em> solutions for them and even spending more time waiting for the server to start. It felt like I was fixing more than making. I even <a href=\"https:\/\/www.smashingmagazine.com\/2023\/06\/gatsby-headaches-i18n-part-1\/\">started a series for this magazine all about the \u201cGatsby headaches\u201d I experienced most<\/a> and how to overcome them.<\/p>\n<p>It was like Gatsby got tougher to use with time because of lots of unaddressed issues: outdated dependencies, cold starts, slow builds, and stale plugins, to name a few. Starting a Gatsby project became tedious for me, and perfect Lighthouse scores couldn\u2019t make up for that.<\/p>\n<p>So, I\u2019ve decided to stop using Gatsby as my go-to framework.<\/p>\n<p>To my surprise, the Vite + React combination I mentioned earlier turned out to be a lot more efficient than I expected while maintaining almost the same great performance measures as Gatsby. It\u2019s a hard conclusion to stomach after years of Gatsby\u2019s loyalty.<\/p>\n<p>I mean, I still think Gatsby is extremely useful for plenty of projects, and I plan on talking about those in a bit. But Gatsby has undergone a series of recent unfortunate events after Netlify acquired it, the impacts of which can be seen in <a href=\"https:\/\/2022.stateofjs.com\/en-US\/libraries\/rendering-frameworks\">down-trending results from the most recent State of JavaScript survey<\/a>. The likelihood of a developer picking up Gatsby again after using it for other projects plummeted from 89% to a meager 38% between 2019 and 2022 alone.<\/p>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"708\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"A ranking of the rendering frameworks retention.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      A ranking of the rendering frameworks retention. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Although Gatsby was still the second most-used rendering framework as recently as 2022 \u2014 we are still expecting results from the 2023 survey \u2014 my prediction is that the decline will continue and dip well below 38%.<\/p>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking_usage.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"708\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"A ranking of the usage of the rendering framework.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking_usage.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      A ranking of the usage of the rendering framework. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/rendering_frameworks_experience_ranking_usage.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Seeing as this is my personal farewell to Gatsby, I wanted to write about where, in my opinion, it went wrong, where it is still useful, and how I am handling my future projects.<\/p>\n<div data-audience=\"non-subscriber\" data-remove=\"true\" class=\"feature-panel-container\">\n<aside class=\"feature-panel\">\n<div class=\"feature-panel-left-col\">\n<div class=\"feature-panel-description\">\n<p>Meet <strong><a data-instant href=\"https:\/\/www.smashingconf.com\/online-workshops\/\">Smashing Workshops<\/a><\/strong> on <strong>front-end, design &amp; UX<\/strong>, with practical takeaways, live sessions, <strong>video recordings<\/strong> and a friendly Q&amp;A. With Brad Frost, St\u00e9ph Walter and <a href=\"https:\/\/smashingconf.com\/online-workshops\/workshops\">so many others<\/a>.<\/p>\n<p><a data-instant href=\"smashing-workshops\" class=\"btn btn--green btn--large\">Jump to the workshops\u00a0\u21ac<\/a><\/div>\n<\/div>\n<div class=\"feature-panel-right-col\"><a data-instant href=\"smashing-workshops\" class=\"feature-panel-image-link\"><\/p>\n<div class=\"feature-panel-image\">\n<img decoding=\"async\" loading=\"lazy\" class=\"feature-panel-image-img lazyload\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Feature Panel\" width=\"257\" height=\"355\" data-src=\"\/images\/smashing-cat\/cat-scubadiving-panel.svg\"><\/p>\n<\/div>\n<p><\/a>\n<\/div>\n<\/aside>\n<\/div>\n<h2 id=\"gatsby-a-retrospective\">Gatsby: A Retrospective<\/h2>\n<p><a href=\"https:\/\/github.com\/gatsbyjs\/gatsby\/releases\/tag\/0.2.0\">Kyle Mathews started working on what would eventually become Gatsby<\/a> in late 2015. Thanks to its unique data layer and SSG approach, it was hyped for success and achieved a <a href=\"https:\/\/changelog.com\/founderstalk\/59\">$3.8 million funding seed round in 2018<\/a>. Despite initial doubts, Gatsby remained steadfast in its commitment and became a frontrunner in the <a href=\"https:\/\/css-tricks.com\/what-makes-a-site-jamstack\/\">Jamstack<\/a> community by consistently enhancing its open-source framework and bringing new and better changes with each version.<\/p>\n<p>So\u2026 where did it all go wrong?<\/p>\n<p>I\u2019d say it was the introduction of <a href=\"https:\/\/www.gatsbyjs.com\/docs\/reference\/cloud\/what-is-gatsby-cloud\/\">Gatsby Cloud<\/a> in 2019, as Gatsby aimed at generating continuous revenue and solidifying its business model. Many (myself included) pinpoint Gatsby\u2019s downfall to Gatsby Cloud, as it would end up cutting resources from the main framework and even making it harder to host in other cloud providers.<\/p>\n<p>The core framework had been optimized in a way that using Gatsby and Gatsby Cloud together required no additional hosting configurations, which, as a consequence, made deployments in other platforms much more difficult, both by neglecting to provide documentation for third-party deployments and by releasing exclusive features, like <a href=\"https:\/\/www.gatsbyjs.com\/blog\/what-are-incremental-cloud-builds-on-gatsby\/#gatsby-skip-here\">incremental builds<\/a>, that were only available to Gatsby users who had committed to using Gatsby Cloud. In short, hosting projects on anything but Gatsby Cloud felt like a penalty.<\/p>\n<p>As a framework, Gatsby lost users to Next.js, as shown in both surveys and npm trends, while Gatsby Cloud struggled to compete with the likes of Vercel and Netlify; the former <a href=\"https:\/\/www.gatsbyjs.com\/blog\/gatsby-is-joining-netlify\/\">acquiring Gatsby in February of 2023<\/a>.<\/p>\n<blockquote><p>\u201cIt [was] clear after a while that [Gatsby] weren\u2019t winning the framework battle against Vercel, as a general purpose framework [&#8230;] And they were probably a bit boxed in by us in terms of building a cloud platform.\u201d<\/p>\n<p>\u2014 <a href=\"https:\/\/thenewstack.io\/netlify-acquires-gatsby-its-struggling-jamstack-competitor\/\">Matt Biilmann<\/a>, Netlify CEO<\/p><\/blockquote>\n<p>The Netlify acquisition was the last straw in an already tumbling framework haystack. The migration from Gatsby Cloud to Netlify wasn\u2019t pretty for customers either; some teams were charged 120% more \u2014 or had <a href=\"https:\/\/www.reddit.com\/r\/webdev\/comments\/1b14bty\/netlify_just_sent_me_a_104k_bill_for_a_simple\/\">incurred extraneous fees<\/a> \u2014 after converting from Gatsby Cloud to Netlify, even with the same Gatsby Cloud plan they had! Many key Gatsby Cloud features, specifically incremental builds that reduced build times of small changes from minutes to seconds, were simply no longer available in Netlify, despite Kyle Mathews <a href=\"https:\/\/www.gatsbyjs.com\/blog\/gatsby-is-joining-netlify\/\">saying they would be ported over to Netlify<\/a>:<\/p>\n<blockquote><p>\u201cMany performance innovations specifically for large, content-heavy websites, preview, and collaboration workflows, will be incorporated into the Netlify platform and, where relevant, made available across frameworks.\u201d<\/p>\n<p>\u2014 Kyle Mathews<\/p><\/blockquote>\n<p>However, in a Netlify forum thread dated August 2023, a mere six months after the acquisition, a Netlify support engineer contradicted Mathews\u2019s statement, saying <a href=\"https:\/\/answers.netlify.com\/t\/how-to-enable-gatsby-incremental-build-2023\/99488\/4\">there were no plans to add incremental features in Netlify<\/a>.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-engineer.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"450\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Netlify forum message from a support engineer.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-engineer.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Netlify forum message from a support engineer. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-engineer.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>That left no significant reason to remain with Gatsby. And I think <a href=\"https:\/\/answers.netlify.com\/t\/how-to-enable-gatsby-incremental-build-2023\/99488\/4\">this comment on the same thread<\/a> perfectly sums up the community\u2019s collective sentiment:<\/p>\n<blockquote><p>\u201cYikes. 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\u2019s really unfortunate to be forced to migrate while simultaneously introducing a huge regression in performance and experience.\u201d<\/p><\/blockquote>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-user.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"450\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Netlify forum message from a user\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-user.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Netlify forum message from a user. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/netlify-forum-message-from-user.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Netlify\u2019s acquisition also brought about a <em>company restructuring<\/em> that substantially reduced the headcount of Gatsby\u2019s engineering team, followed by a complete stop in commit activities. A report in an ominous tweet by Astro co-founder Fred Schott further exacerbated concerns about Gatsby\u2019s future.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-fredkschott.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"269\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Fred Schott\u2019s tweet reading, \u2018There have been zero commits to the Gatsby repo in the last 24 days.\u2019\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-fredkschott.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-fredkschott.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Lennart J\u00f6rgens, former full-stack developer at Gatsby and Netlify, replied, insinuating there was only one person left after the layoffs:<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-on-one-person-on-the-team.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"548\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Lennart J\u00f6rgens tweet reading, \u2018Don\u2019t expect the one person remaining to do all the work.\u2019\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-on-one-person-on-the-team.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/tweet-on-one-person-on-the-team.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>You can see all these factors contributing to Gatsby\u2019s usage downfall in the <a href=\"https:\/\/survey.stackoverflow.co\/2023#section-most-popular-technologies-web-frameworks-and-technologies\">2023 Stack Overflow survey<\/a>.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/stack-overflow-survey-rendering-frameworks.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"450\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Stacks overflow ranking of the rendering framework usage.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/stack-overflow-survey-rendering-frameworks.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Stacks overflow ranking of the rendering framework usage. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/stack-overflow-survey-rendering-frameworks.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Biilmann addressed the community\u2019s concerns about Gatsby\u2019s viability in an <a href=\"https:\/\/github.com\/gatsbyjs\/gatsby\/issues\/38696#issuecomment-1817064739\">open issue from the Gatsby repository<\/a>:<\/p>\n<blockquote><p>\u201cWhile we don\u2019t plan for Gatsby to be where the main innovation in the framework ecosystem takes place, it will be a safe, robust and reliable choice to build production quality websites and e-commerce stores, and will gain new powers by ways of great complementary tools.\u201d<\/p>\n<p>\u2014 Matt Biilmann<\/p><\/blockquote>\n<p>He also shed light on Gatsby\u2019s future focus:<\/p>\n<blockquote>\n<ul>\n<li>\u201cFirst, ensure stability, predictability, and good performance.<\/li>\n<li>Second, give it new powers by strong integration with all new tooling that we add to our Composable Web Platform (for more on what\u2019s all that, you can check out our homepage).<\/li>\n<li>Third, make Gatsby more open by decoupling some parts of it that were closely tied to proprietary cloud infrastructure. The already-released Adapters feature is part of that effort.\u201d<\/li>\n<\/ul>\n<p>\u2014 Matt Biilmann<\/p><\/blockquote>\n<p>So, Gatsby gave up competing against Next.js on innovation, and instead, it will focus on keeping the existing framework clean and steady in its current state. Frankly, this seems like the most reasonable course of action considering today\u2019s state of affairs.<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"why-did-people-stop-using-gatsby\">Why Did People Stop Using Gatsby?<\/h2>\n<p>Yes, Gatsby Cloud ended abruptly, but as a framework independent of its cloud provider, other aspects encouraged developers to look for alternatives to Gatsby.<\/p>\n<p>As far as I am concerned, Gatsby\u2019s developer experience (<abbr>DX<\/abbr>) became more of a burden than a help, and there are two main culprits where I lay the blame: <strong>dependency hell<\/strong> and <strong>slow bundling times<\/strong>.<\/p>\n<h3 id=\"dependency-hell\">Dependency Hell<\/h3>\n<p>Go ahead and start a new Gatsby project:<\/p>\n<pre><code class=\"language-shellsession\">gatsby new\n<\/code><\/pre>\n<p>After waiting a couple of minutes you will get your brand new Gatsby site. You\u2019d rightly expect to have a clean slate with zero vulnerabilities and outdated dependencies with this out-of-the-box setup, but here\u2019s what you will find in the terminal once you run <code>npm audit<\/code>:<\/p>\n<pre><code class=\"language-shellsession\">18 vulnerabilities (11 moderate, 6 high, 1 critical)\n<\/code><\/pre>\n<p>That looks concerning \u2014 and it is \u2014 not so much from a security perspective but as an indication of decaying DX. As a static site generator (SSG), Gatsby will, unsurprisingly, deliver a static and safe site that (normally) doesn\u2019t have access to a database or server, making it immune to most cyber attacks. Besides, lots of those vulnerabilities are in the developer tools and never reach the end user. Alas, relying on <code>npm audit<\/code> to assess your site security is <a href=\"https:\/\/overreacted.io\/npm-audit-broken-by-design\/\">a naive choice at best<\/a>.<\/p>\n<p>However, those vulnerabilities reveal an underlying issue: the whopping number of dependencies Gatsby uses is 168(!) at the time I\u2019m writing this. For the sake of comparison, Next.js uses 16 dependencies. A lot of Gatsby\u2019s dependencies are outdated, hence the warnings, but trying to update them to their latest versions will likely unleash a dependency hell full of additional npm warnings and errors.<\/p>\n<p>In a <a href=\"https:\/\/www.reddit.com\/r\/gatsbyjs\/comments\/woccnn\/is_it_possible_to_have_a_gatsby_project_without\/\">related subreddit<\/a> from 2022, a user asked, \u201cIs it possible to have a Gatsby site without vulnerabilities?\u201d<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/is-it-possible-to-have-a-gatsby-site-without-vulnerabilities.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"450\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Reddit comment, \u2018Is it possible to have a Gatsby site without vulnerabilities?\u2019\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/is-it-possible-to-have-a-gatsby-site-without-vulnerabilities.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/is-it-possible-to-have-a-gatsby-site-without-vulnerabilities.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>The real answer is disappointing, but as of March 2024, it remains true.<\/p>\n<p>A Gatsby site should work completely fine, even with that many dependencies, and extending your project shouldn\u2019t be a problem, whether through its plugin ecosystem or other packages. However, when trying to upgrade any existing dependency you will find that you can\u2019t! Or at least you can\u2019t do it without introducing breaking changes to one of the 168 dependencies, many of which rely on outdated versions of other libraries that also cannot be updated.<\/p>\n<p>It\u2019s that inception-like roundabout of dependencies that I call <strong>dependency hell<\/strong>.<\/p>\n<h3 id=\"slow-build-and-development-times\">Slow Build And Development Times<\/h3>\n<p>To me, one of the most important aspects of choosing a development tool is how comfortable it feels to use it and how fast it is to get a project up and running. <a href=\"https:\/\/www.smashingmagazine.com\/2024\/02\/web-development-getting-too-complex\/\">As I\u2019ve said before<\/a>, users don\u2019t care or know what a \u201ctech stack\u201d is or what framework is in use; they want a good-looking website that helps them achieve the task they came for. Many developers don\u2019t even question what tech stack is used on each site they visit; at least, I hope not.<\/p>\n<p>With that in mind, choosing a framework boils down to how efficiently you can use it. If your development server constantly experiences cold starts and crashes and is unable to quickly reflect changes, that\u2019s a poor DX and a signal that there may be a better option.<\/p>\n<p>That\u2019s the main reason I won\u2019t automatically reach for Gatsby from here on out. Installation is no longer a trivial task; the dependencies are firing off warnings, and it takes the development server upwards of 30 seconds to boot. I\u2019ve even found that the longer the server runs, the slower it gets; this happens constantly to me, though I admittedly have not heard similar gripes from other developers. Regardless, I get infuriated having to constantly restart my development server every time I make a change to <code>gatsby-config.js<\/code>, <code>gatsby-node.js<\/code> files, or any other data source.<\/p>\n<p>This new reality is particularly painful, knowing that a Vite.js + React setup can start a server within 500ms <a href=\"https:\/\/esbuild.github.io\">thanks to the use of esbuild<\/a>.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/bundlers-time.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"181\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Esbuild time to craft a production bundle of 10 copies of the three.js library from scratch using default settings.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/bundlers-time.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Esbuild time to craft a production bundle of 10 copies of the three.js library from scratch using default settings. (Image source: <a href=\"https:\/\/esbuild.github.io\">esbuild<\/a>) (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/bundlers-time.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Running <code>gatsby build<\/code> gets worse. Build times for larger projects normally take some number of minutes, which is understandable when we consider all of the pages, data sources, and optimizations Gatsby does behind the scenes. However, even a small content edit to a page triggers a full build and deployment process, and the endless waiting is not only exhausting but downright distracting for getting things done. That\u2019s what incremental builds were designed to solve and the reason many people switched from Netlify to Gatsby Cloud when using Gatsby. It\u2019s a shame we no longer have that as an available option.<\/p>\n<p>The moment Gatsby Cloud was discontinued along with incremental builds, the incentives for continuing to use Gatsby became pretty much non-existent. The <strong>slow build times<\/strong> are simply too costly to the development workflow.<\/p>\n<h2 id=\"what-gatsby-did-awesomely-well\">What Gatsby Did Awesomely Well<\/h2>\n<p>I still believe that Gatsby has awesome things that other rendering frameworks don\u2019t, and that\u2019s why I will keep using it, albeit for specific cases, such as my personal website. It just isn\u2019t my go-to framework for everything, mainly because Gatsby (and the Jamstack) wasn\u2019t meant for every project, even if Gatsby was marketed as a general-purpose framework.<\/p>\n<p>Here\u2019s where I see Gatsby still leading the competition:<\/p>\n<ul>\n<li><strong>The GraphQL data layer.<\/strong><br \/>\nIn Gatsby, all the configured data is available in the same place, a <em>data layer<\/em> that\u2019s easy to access using GraphQL queries in any part of your project. This is by far the best Gatsby feature, and it trivializes the process of building static pages from data, e.g., a blog from a content management system API or documentation from Markdown files.<\/li>\n<li><strong>Client performance.<\/strong><br \/>\nWhile Gatsby\u2019s developer experience is questionable, I believe it delivers one of the best user experiences for navigating a website. Static pages and assets deliver the fastest possible load times, and using React Router with pre-rendering of proximate links offers one of the smoothest experiences navigating between pages. We also have to note Gatsby\u2019s amazing image API, which optimizes images to all extents.<\/li>\n<li><strong>The plugin ecosystem (kinda).<\/strong><br \/>\nThere is typically a Gatsby plugin for everything. This is awesome when using a CMS as a data source since you could just install its specific plugin and have all the necessary data in your data layer. However, a lot of plugins went unmaintained and grew outdated, introducing unsolvable dependency issues that come with dependency hell.<\/li>\n<\/ul>\n<p>I briefly glossed over the good parts of Gatsby in contrast to the bad parts. Does that mean that Gatsby has more bad parts? Absolutely not; you just won\u2019t find the bad parts in any documentation. The bad parts also aren\u2019t deal breakers in isolation, but they snowball into a tedious and lengthy developer experience that pushes away its advocates to other solutions or rendering frameworks.<\/p>\n<h3 id=\"do-we-need-ssr-ssg-for-everything\">Do We Need SSR\/SSG For Everything?<\/h3>\n<p>I\u2019ll go on record saying that I am not replacing Gatsby with another rendering framework, like Next.js or Remix, but just avoiding them altogether. I\u2019ve found they aren\u2019t actually needed in a lot of cases.<\/p>\n<p>Think, why do we use any type of rendering framework in the first place? I\u2019d say it\u2019s for two main reasons: <strong>crawling bots<\/strong> and <strong>initial loading time<\/strong>.<\/p>\n<h4 id=\"seo-and-crawling-bots\">SEO And Crawling Bots<\/h4>\n<p>Most React apps start with a hollow body, only having an empty <code><\/p>\n<div><\/div>\n<p><\/code> alongside <code><\/code> tags. The JavaScript code then runs in the browser, where React creates the Virtual DOM and injects the rendered user interface into the browser.<\/p>\n<p>Over slow networks, users may notice a white screen before the page is actually rendered, which is just mildly annoying at best (but <a href=\"https:\/\/ericwbailey.design\/published\/modern-health-frameworks-performance-and-harm\/\">devastating at worst<\/a>).<\/p>\n<p>However, search engines like Google and Bing deploy bots that only see an empty page and decide not to crawl the content. Or, if you are linking up a post on social media, you may not get OpenGraph benefits like a link preview.<\/p>\n<pre><code class=\"language-html\">\n  <div id=\"root\"><\/div>\n\n  \n\n<\/code><\/pre>\n<p>This was the case years ago, making SSR\/SSG necessary for getting noticed by Google bots. Nowadays, <a href=\"https:\/\/developers.google.com\/search\/docs\/crawling-indexing\/javascript\/javascript-seo-basics\">Google can run JavaScript<\/a> and render the content to crawl your website. While using SSR or SSG does make this process faster, not all bots can run JavaScript. It\u2019s a tradeoff you can make for a lot of projects and one you can minimize on your cloud provider by <a href=\"https:\/\/docs.netlify.com\/site-deploys\/post-processing\/prerendering\/\">pre-rendering<\/a> your content.<\/p>\n<h4 id=\"initial-loading-time\">Initial Loading Time<\/h4>\n<p>Pre-rendered pages load faster since they deliver static content that relieves the browser from having to run expensive JavaScript.<\/p>\n<p>It\u2019s especially useful when loading pages that are behind authentication; in a client-side rendered (CSR) page, we would need to display a loading state while we check if the user is logged in, while an SSR page can perform the check on the server and send back the correct static content. I have found, however, that this trade-off is an uncompelling argument for using a rendering framework over a CSR React app.<\/p>\n<p>In any case, my SPA built on React + Vite.js gave me a perfect Lighthouse score for the landing page. Pages that fetch data behind authentication resulted in near-perfect Core Web Vitals scores.<\/p>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/landing-page-lighthouse-score.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"356\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Near-perfect Lighthouse scores, 99% for performance, 79% for accessibility, 100% for best practices, and 100% for SEO.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/landing-page-lighthouse-score.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Lighthouse scores for the app landing page. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/landing-page-lighthouse-score.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/page-guarded-by-auth-lighthouse-score.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"356\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Perfect Lighthouse scores of 100% for performance, accessibility, best practices, and SEO.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/page-guarded-by-auth-lighthouse-score.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Lighthouse scores for pages guarded by authentication. (<a href=\"https:\/\/files.smashing.media\/articles\/end-of-gatsby-journey\/page-guarded-by-auth-lighthouse-score.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"what-projects-gatsby-is-still-good-for\">What Projects Gatsby Is Still Good For<\/h2>\n<p>Gatsby and rendering frameworks are excellent for programmatically creating pages from data and, specifically, for blogs, e-commerce, and documentation.<\/p>\n<p>Don\u2019t be disappointed, though, if it isn\u2019t the right tool for <em>every<\/em> use case, as that is akin to blaming a screwdriver for not being a good hammer. It still has good uses, though fewer than it could due to all the reasons we discussed before.<\/p>\n<p>But Gatsby is still a useful tool. If you are a Gatsby developer the main reason you\u2019d reach for it is because you <em>know<\/em> Gatsby. Not using it might be considered an <strong>opportunity cost<\/strong> in economic terms:<\/p>\n<blockquote><p>\u201cOpportunity cost is the value of the next-best alternative when a decision is made; it\u2019s what is given up.\u201d<\/p><\/blockquote>\n<p>Imagine a student who spends an hour and $30 attending a yoga class the evening before a deadline. The opportunity cost encompasses the time that could have been dedicated to completing the project and the $30 that could have been used for future expenses.<\/p>\n<p>As a Gatsby developer, I could start a new project using another rendering framework like Next.js. Even if Next.js has faster server starts, I would need to factor in my learning curve to use it as efficiently as I do Gatsby. That\u2019s why, for my latest project, I decided to avoid rendering frameworks altogether and use Vite.js + React \u2014 I wanted to avoid the opportunity cost that comes with spending time learning how to use an \u201cunfamiliar\u201d framework.<\/p>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>So, is Gatsby dead? Not at all, or at least I don\u2019t think Netlify will let it go away any time soon. The acquisition and subsequent changes to Gatsby Cloud may have taken a massive toll on the core framework, but Gatsby is very much still breathing, even if the current slow commits pushed to the repo look like it\u2019s barely alive or hibernating.<\/p>\n<p>I will most likely stick to Vite.js + React for my future endeavors and only use rendering frameworks when I actually need them. What are the tradeoffs? Sacrificing negligible page performance in favor of a faster and more pleasant DX that maintains my sanity? I\u2019ll take that deal every day.<\/p>\n<p>And, of course, this is <em>my<\/em> experience as a long-time Gatsby loyalist. Your experience is likely to differ, so the mileage of everything I\u2019m saying may vary depending on your background using Gatsby on your own projects.<\/p>\n<p>That\u2019s why I\u2019d love for you to comment below: if you see it differently, please tell me! Is your current experience using Gatsby different, better, or worse than it was a year ago? What\u2019s different to you, if anything? It would be awesome to get other perspectives in here, perhaps from someone who has been involved in maintaining the framework.<\/p>\n<h4 id=\"further-reading-on-smashingmag\">Further Reading On SmashingMag<\/h4>\n<ul>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2023\/06\/gatsby-headaches-i18n-part-1\/\">Gatsby Headaches And How To Cure Them: i18n (Part 1)<\/a><\/li>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2023\/06\/gatsby-headaches-i18n-part-2\/\">Gatsby Headaches And How To Cure Them: i18n (Part 2)<\/a><\/li>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2023\/10\/gatsby-headaches-working-media-part1\/\">Gatsby Headaches: Working With Media (Part 1)<\/a><\/li>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2023\/10\/gatsby-headaches-working-media-part2\/\">Gatsby Headaches: Working With Media (Part 2)<\/a><\/li>\n<\/ul>\n<div class=\"signature\">\n  <img decoding=\"async\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" class=\"lazyload\" data-src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\"><br \/>\n  <span>(gg, yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>The End Of My Gatsby Journey The End Of My Gatsby Journey Juan Diego Rodr\u00edguez 2024-03-06T08:00:00+00:00 2025-06-20T10:32:35+00:00 A fun fact about me is that my birthday is on Valentine\u2019s Day. This year, I wanted to&hellip;<\/p>\n<p class=\"more-link-wrapper\"><a href=\"https:\/\/francecourier.com\/index.php\/2024\/03\/06\/the-end-of-my-gatsby-journey\/\" class=\"more-link\">Continue Reading<span class=\"screen-reader-text\"> &#8220;The End Of My Gatsby Journey&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":["post-635","post","type-post","status-publish","format-standard","hentry","category-javascript"],"_links":{"self":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/635","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/comments?post=635"}],"version-history":[{"count":1,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/635\/revisions"}],"predecessor-version":[{"id":636,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/635\/revisions\/636"}],"wp:attachment":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/media?parent=635"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/categories?post=635"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/tags?post=635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}