MJ Codes logo
AstroTailwind CSSSanity.ioTech Stacks
Tombstone with an old desktop computer

When a Framework Dies - PART 1

January 20, 2025 ⏱ 6 min read

Imagine investing countless hours into a framework, programming language, or technology to become proficient in it, only to have it die on you or be abandoned by its creators. This was my experience with Gatsby.js, a React framework for static-site generation (SSG) that I have been using since 2020.

Now imagine if this was a company. It would be costly to migrate to a “modern” and “stable” alternative.

My Experience

As I was adding a “Frequently Asked Questions” section to my portfolio last December, I noticed that I was getting a lot of warnings/errors in the developer console.

When something like this happened, it usually meant that there was an update and all I needed to do was update. Simple. Was I wrong this time? I updated the packages, unfortunately, the core framework, Gatsby.js, was not updated.

After doing a bit of research in the documentation and Reddit, my fear was confirmed. Gatsby is dead. In fact, it has been dead ever since it was acquired by Netlify, with a few “maintenance” updates here and there.

Was I sad that this happened? Of course. I have been told that the first framework a developer learns, always has a special place in their heart. It is also true for me.

Where there is a will, there is a way

However, the end of Gatsby was not the end of the world for me, I had a few choices:

  1. Continue using it and accept that I won’t get the latest React features.
  2. Rebuild the whole site in Next.js, Gatsby’s direct (and successful) competitor.
  3. Or learn a different framework. See this as an opportunity to learn something new and level up.

I chose the third option. However, I had limited choices because what made me love Gatsby was its Static-Site Generation (SSG) first approach. My website is not a real-time app that is constantly speaking with the server, no. So whatever framework I was moving to needed to have SSG first approach as well.

Just as I was about to create a SvelteKit project, I remembered this JavaScript framework called Astro. After reading the documentation and what it tries to solve, it was perfect for my use case and exactly what I was looking for. SSG support, React support, AND if I ever wanted to experiment (or learn) with a new framework like Vue, I could easily do that right within Astro.

The Replacements

Anyway here is the breakdown of what I used and replaced to achieve the same results:

Why I Chose What I Chose

Astro

Astro cover

Like I said earlier, I wanted a framework that was SSG first. This to me was priority number one. Why? I value speed, performance, and responsiveness above many things for my personal projects. Astro seemed to promise that and I am glad I took the bait.

Not only is the deployed project static, but it also ships with zero JavaScript on the client! Yes, you read correctly. Zero JavaScript. JavaScript is only loaded when you, the developer, add JavaScript. Meaning to say, if your site is slow, chances are that it is because of poorly written JavaScript—among other factors of course.

Secondly, talk about timing. Astro seems to be getting more into server-side-rendering (SSR) and I am very impressed with it. “What does this mean?” You might be asking.

Basically, it means that the changes I make to my articles—or any content that is being fetched from Sanity—will instantly appear as soon as I click the “Publish” button.

This is a plus for me unlike the experience I had with Gatsby and NetlifyCMS whereby each change—no matter how small—always led to having the whole site rebuilt. It was annoying especially if I wanted to make rapid changes to multiple posts.

”Wait, doesn't Gatsby have SSR support?” Yes. On paper it does but the reality is that it is not well implemented as it is on other frameworks.

My advice is that if you want a 100% React experience with SSR then just go with Next.js.

If I ever want to experiment (or learn) a new framework like Vue or Svelte, I could easily do that right within Astro.

As I mentioned earlier, Astro supports other frameworks. What does this mean?

Well, since I am already using React within Astro, if I ever want to experiment (or learn) a new framework like Vue or Svelte, I could easily do that within my existing Astro project without the need to create a new dedicated project.

Tailwind CSS

Tailwind CSS cover

It is safe to say that Tailwind is the default standard for styling on modern websites. I'm not going to lie, I was stubborn. I never wanted to leave pure CSS or Sass because that’s where I was strongest. However, after successfully creating and deploying four sites with Tailwind, I just had to fold and use it for my personal projects.

I was reluctant. After all, I thought I could not replicate the original styling from the Gatsby version of my portfolio because I heavily used Sass. I thought Tailwind had its limitations—which it does, by the way—but thankfully, I have yet to run into those limitations.

Tailwind makes writing CSS easier. Ahem, as a side note, I still think knowledge of pure CSS makes one appreciate Tailwind and other CSS frameworks more.

Sanity.io

Sanity Cover

Oh boy, consider this a summary because Sanity deserves its own lengthy article. The core principle of Sanity is in its name. It is the only sane content management system (CMS) I have encountered. I know this because I have used other CMSs, such as Strapi, Contentful, and Netlify CMS (Don’t try this. Just don’t). I even tried WordPress at one point as a CMS. I was not impressed.

Sanity offers a lot: TypeScript support, somewhat complex relationships between entities (sanity types), media storage, and a very generous “free” tier, and there is a lot more. I know this because every time I visit the docs, I am impressed at the information there, and I have only read a few pages about the types I want to use.

Wait, there is more đŸ€Ż. It is highly customizable to suit your use-case/business needs.

If it sounds too good to be true then yes, there is a catch. Well, I wouldn’t say that Sanity is the easiest CMS to learn. When one gets into it, there is a high chance that the learning curve will push them away.

But like I always say, nothing worth learning is easy.

Conclusion

All I can say is that make sure you choose what you invest your time in wisely. That programming language or framework you dearly love might one day become obsolete. We have seen Google killing off/abandoning technologies such as Angular.js (Angular 1). JQuery was no longer being maintained for almost a decade.

This is why I say that it is better to choose Laravel. Don’t be like me 😂.

Thank you for tech-ing (get it? No? Okay đŸš¶â€â™‚ïž) the time to read through this. Until next time.