Dev Journal #2 - Is Gatsby Dead? Not Really, But I'm Moving to Astro Anyway

Introduction

Since 2019, my blog has been powered by Gatsby, a framework that introduced me to static site generation and provided a solid foundation for content-driven websites. While it’s been reliable and performant, my evolving development workflow has led me to explore new tools that better align with my current direction.

Enter Astro, a modern framework built for the content web that caught my attention with its Islands Architecture. After exploring its capabilities, I decided to build my new project, Thanmatt Labs, using Astro as the foundation.

Setup

Before diving into development, I faced a crucial decision: should I also migrate my blog to Astro? This would mean managing two separate Astro projects in different repositories, which seemed inefficient for maintaining a consistent design language across my UI components.

The solution became clear which I create a monorepo that contains both my blog and Thanmatt Labs, along with shared UI components and other potential packages.

Here are the other approaches I considered besides the monorepo project:

1. Create a commons repo and make it as a git submodule

   • This is the simplest solution in my opinion. However this would only benefit for my UI components not other packages, like an admin CMS package where I will store my markdown content for my blog and projects collections.
   • Even if I did this, I have to redeploy the each app manually because a submodule is separated from my app repos

2. Publish these packages to a registry like NPM or GitHub Packages

   • Same thing, I have to redeploy my apps after upgrading those packages
   • Might be a simple use case for publishing my very own UI library;
   • but might be more complicated for my other use cases like admin package where I would store my content there and create a centralized CMS
   • Might need to set up a dedicated CI/CD for my packages for automated publishing

3. Set up a monorepo project instead

   • Might be an overkill especially for a personal project with only one developer, me.
   • I don’t need to manually redeploy my apps if I updated something in my packages because they’re in a same repo
   • CI/CD might be too complicated especially if I have two apps now
   • Much simpler to manage my packages and even apps because they’re now all in one repo

After weighing the complexity and tradeoffs, I chose the monorepo approach. This decision aligns with my goal of building cohesive personal projects with a shared design language while maintaining centralized content management.

Beyond the practical benefits, this presented an exciting learning opportunity. While I’ve worked with monorepos before, setting one up from scratch and configuring complex CI/CD pipelines was new territory for me.

Why leave Gatsby?

This is my experience so far with Gatsby and other people who have used Gatsby might have different experiences, and these are my thoughts.

The Gatsby plugin ecosystem has become problematic, with many outdated and unmaintained plugins introducing dependency issues and security vulnerabilities. The frustration of discovering that a plugin you need like gatsby-plugin-google-analytics has been deprecated after reviewing its documentation is all too common.

Constant dependency warnings when installing packages became increasingly annoying. These vulnerabilities accumulate over time, creating maintenance overhead that distracted from actual development work.

I really can’t say Gatsby is officially dead. The GitHub repository shows ongoing contributions, particularly around security fixes, and they maintain a security policy for vulnerability reporting. They’re aware of the npm audit issues plaguing the ecosystem. The contributors continue to do excellent work maintaining the project despite these ecosystem challenges.

What I’ll miss most about Gatsby is its out-of-the-box GraphQL support, which made fetching CMS data incredibly convenient, though this preference might be subjective given my familiarity with GraphQL.

Gatsby was groundbreaking in its time and served me well. I’d consider returning if they address the plugin ecosystem issues, bundle size problems, and community engagement challenges.

Making the Switch

Moving to Astro felt like the right choice for reducing friction and focusing on building rather than wrestling with tooling issues.

The Project

Thanmatt Labs serves as both a project showcase and an experimentation playground. Like my blog posts, the content is written in Markdown, but these project summaries belong to a separate collection dedicated to documenting my builds.

To simplify content management, I’m developing an admin CMS package within the monorepo that will handle both blog posts and project collections. While this remains a work in progress, my immediate focus has been on deploying and designing Thanmatt Labs.

Challenges

Building this project presented several challenges, some resolved and others still in progress:

Resolved Challenges

1. Mobile responsiveness

   • Prioritized mobile-first design since most users likely access the site on mobile devices
   • Chose Tailwind CSS and Shadcn UI for component flexibility while providing solid starting points
   • As someone who is not a good designer, I leaned heavily on Dribbble for landing page inspiration

2. Learning curve

   • Explored monorepo tools including Turborepo, NX, Lerna, and pnpm workspaces before settling on pnpm workspaces for simplicity
   • Adapted to Astro’s framework-agnostic approach, which differs significantly from Gatsby’s React-centric model

Ongoing Challenges

1. Content strategy

   • While project summaries form the core content, I’m still defining what additional content would provide value to visitors
   • Considering case studies, technical deep-dives, or interactive demos

2. Performance optimization

   • Still learning optimal data fetching patterns in Astro
   • Implement page caching strategies to minimize load times

3. CI/CD configuration

   • With only one app currently deployed, CI/CD setup remains simple through Netlify
   • Planning for selective deployments and automated deployment triggers when shared packages are updated

My experience on Astro

Unlike Gatsby’s React-centric approach, Astro is framework-agnostic. However, I can still leverage React components within my Astro project thanks to the Islands architecture.

This architecture centers on selective hydration, it renders most content as static HTML while adding JavaScript only to components that require interactivity.

Imagine a webpage as an ocean of static HTML (fast, no JavaScript) with islands of interactivity scattered throughout. Each “island” represents an interactive component with its own isolated JavaScript, while everything else remains lightweight HTML and CSS.

In my Astro project, React components that need interactivity become these islands, getting hydrated only when necessary.

Astro’s framework flexibility shines here, you can integrate Vue, Svelte, or other frameworks alongside React simply by updating the configuration file. This multi-framework support contrasts sharply with Gatsby’s React-only limitation and represents one of Astro’s key advantages.

What’s next

My positive experience with Astro has solidified my decision to migrate this blog as well. This transition will enable component reuse from my UI package, this ensures design consistency across all my projects.

Upcoming Plans

• Blog migration: Expect a revamped blog site built on Astro
• CMS development: Focus on completing the local admin CMS server for simplified content management
• Design evolution: Likely keeping the current blog layout while updating individual components like cards for consistency
• Richer content: Integrate MDX for interactive code examples and embedded demos in blog and project posts
• Framework agnosticism: Create small experimental projects using different web frameworks like Svelte and Vue with Astro

The journey from Gatsby to Astro represents more than a framework switch, it’s about building a more cohesive, maintainable ecosystem for my personal projects.

Check out the current state of Thanmatt Labs and watch for upcoming improvements!