Goodbye Gatsby, Hello Remix

I have migrated this blog from Gatsby to Remix. Since I had been gradually removing Gatsby dependencies from my codebase, the final migration wasn’t too difficult—but it still took me two days.

The number of modified files and lines of code may seem large, but that’s mostly due to the blog content itself. The actual necessary changes weren’t too extensive. I deployed it to Cloudflare Pages, and since Remix provides an official adapter, everything went smoothly without any issues.

Why Remix?

Why did I switch to Remix? The reason is simple: I got bored with the technology stack centered around Gatsby.

My encounter with Gatsby dates back to GraphQL Asia 2019. It was the first large-scale GraphQL conference in Asia, where I met the developers of Gatsby and Netlify. I was captivated by the innovative design philosophy of using GraphQL as an interface, the rapidly evolving ecosystem, and the enthusiasm I witnessed at the conference. After returning home, I immediately built several websites using Gatsby, and naturally, I migrated my personal blog to it as well.

Five years have passed since then. Over time, I’ve implemented Gatsby plugins, used multiple toolchains, and even read Gatsby’s source code. I became proficient enough that development wasn’t an issue. Writing blog posts using SSG (Static Site Generation) became second nature. The development landscape around Gatsby has also changed significantly. Gatsby Cloud was launched just six months after I returned from GraphQL Asia 2019, and in 2023, Gatsby was acquired and integrated into Netlify, introducing numerous features to differentiate itself from competitors.

Meanwhile, frameworks with entirely different philosophies, such as Remix, have evolved. Toolchains like Vite have strengthened, and Next.js has continued to receive updates. Amidst these developments, many have started moving away from Gatsby (source).

This is a common trend with any mature technology. The very fact that such discussions arise may indicate that Gatsby has matured. However, compared to five years ago, I personally find less excitement and anticipation in using Gatsby.

While feeling this growing sense of stagnation, I noticed that Shopify acquired Remix, and I started seeing more real-world applications of Remix in production. My curiosity about its performance improvements, unidirectional data flow, design philosophy, and internal implementation grew. In the end, my decision to switch was driven by simple curiosity: "Why not try Remix?"

For clarity, this is not a position-driven statement—I am a Site Reliability Engineer (SRE) by profession and have no involvement in Remix’s development.

Goodbye SSG, Hello SSR

Gatsby is fundamentally built around SSG (Static Site Generation). It trades off a CPU-intensive build process—where assets grow over time—for preloading necessary data at build time and embedding it into static HTML. The result is a set of static assets that can be efficiently served via a CDN, achieving reasonable performance. Architecturally, it eliminates the need for a backend, making deployment and maintenance straightforward.

From an SRE perspective, SSG is an ideal operational model with minimal maintenance costs. In fact, when retiring a service, converting a dynamic application into static assets for minimal-cost operation is a valid strategy.

On the other hand, SSR (Server-Side Rendering) moves rendering from the client (browser) to the server, assuming an active backend. Since data isn’t embedded at build time, it must be retrieved at runtime. If a database or cache store is involved, additional maintenance costs arise.

However, in terms of user experience, SSG doesn’t always guarantee the best performance. SSG-built assets are fast because they are cached by a CDN, but for dynamic content (e.g., search results) or cache misses, responses aren’t necessarily optimized.

SSR itself is not a new technology, nor is it exclusive to Remix. The operational drawbacks of SSR have been widely discussed. While one approach is to invest in optimizing backend performance, there are multiple ways to achieve this. Gatsby also supports SSR, and it even offers DSG (Deferred Static Generation) to delay static generation. However, there is still a stark difference between Gatsby, which defaults to SSG, and Remix, which currently does not offer SSG at all. This affects both development speed and feature availability.

The biggest mindset shift when operating an SSR-based service is accepting that bottlenecks will always be in the backend. Optimizing slow queries, addressing N+1 query issues, and refining database constraints become necessary investments. While SSG works fine for simple sites, long-term services benefit from early investments in data modeling and inter-service communication.

Investing in your back end will yield the same performance results as SSG, but it scales to any kind of page. It will require more initial work than SSG, but we think it's worth it for your users and your code in the long run.

SSG simplifies deployment and maintenance. SSR, on the other hand, shifts complexity to the backend and operations in exchange for a simpler client-side experience. The choice between them is a trade-off, not a matter of one being superior.

Unidirectional Dataflow

One of the initial challenges with Remix is understanding the loader/action/component structure. It’s a highly opinionated framework, but that’s what simplifies data management.

export async function loader() {
  // provides data to the component
}

export default function Component() {
  // renders the UI
}

export async function action() {
  // updates persistent data
}

The loader fetches data, the action handles updates, and the component renders the UI based on that data. All of this is structured within a single file. In a way, this redefines the MVC (Model-View-Controller) paradigm, with loader/action/component playing the roles of View and Controller.

This constraint clarifies the data flow—where updates occur, where data is read, and where it is displayed. This structured unidirectional flow benefits the development experience.

One of the core challenges in frontend development is managing state, which constantly changes based on user interactions. Remix aims to synchronize server-side and client-side states, reducing complex client-side state management. While I can’t claim this makes all use cases easier, having the framework handle state synchronization between server and client is a welcome advantage.

What's next?

This is my initial take on Remix, but I’m sure I’ll encounter limitations and constraints over the next five years. I plan to continue using Remix and exploring its boundaries.

If you’re already using Remix in production and have insights or opinions, I’d love to hear from you. Let’s discuss! Also, since I lack deep experience with Next.js, I’d appreciate insights from those who do. Although I have experience operating SSR in production, the deployment environment and workload characteristics vary greatly, so I’d also welcome broader feedback on SSR.

Since my personal blog doesn’t receive enough traffic to expose performance bottlenecks, real-world operational knowledge will be crucial. This blog remains an experimental playground—I'll keep learning by building.