From Gatsby to Next.js: My Journey to a Better Blogging Experience
As a developer, I love experimenting with new technologies on my personal blog. Recently, I made the switch from Gatsby to Next.js, and I’m excited to share my experience with you. While both frameworks have their strengths and weaknesses, I’ll dive into what worked well and what didn’t during my migration process.
Why I Chose Gatsby in the First Place
I initially opted for Gatsby because I wanted more control over the build process and the ability to author my code in a specific way. Blogging tools can be limiting, and I didn’t want my creativity to be constrained by the features they offered. With Gatsby, I could group multiple posts into series, add a fuzzy search bar, and use MDX to insert custom functionality into my posts.
The Learning Curve
However, learning Gatsby wasn’t easy. I was new to GraphQL and its programmatic approach to building websites. It took a lot of practice to get comfortable with Gatsby, but eventually, it gave me the freedom to author my blog as a React application. I could do almost anything I wanted, and it felt empowering.
The Pain Points
Despite its power, I had some pain points with Gatsby. The main issue was GraphQL, especially when combined with type checking. Writing large queries and then writing types for them felt verbose. I longed for a more minimal alternative that would help me work faster.
Enter Next.js
That’s when I started noticing Next.js, which had recently updated to v9.3, including static site generation. From a developer’s perspective, Next.js is much easier to start with. However, migrating my logic was a challenge. I had to adapt to a new environment, and the main hurdle was MDX.
MDX: The Game-Changer
Next.js has an official MDX plugin, but it only adds a Webpack loader. I needed more control over my posts, so I turned to alternative plugins like next-mdx-enhanced, which supports default layout and frontmatter. To extract frontmatter data, I used gray-matter and traversed through the filesystem in getStaticProps.
Creative Solutions
To overcome the limitations of Next.js’s MDX plugin, I got creative. I wrote custom remark and retype plugins to edit the content, adding export statements for layout, JSX excerpt, and data about series. I also used babel-plugin-codegen to generate import statements for every post, making it scalable.
The Final Touches
For generating the sitemap, I used nextjs-sitemap-generator, which worked well. Creating the feed required more effort, but I reused functionality from extracting metadata and used the feed package to create the feed.
Lessons Learned
Choosing the right tool for the job is difficult, especially without experience. Using Next.js for static exporting is still relatively new, but I’m glad I took the leap. MDX proved to be the biggest obstacle, but with the upcoming release of MDX v2, I’m excited to see how it will solve some of the problems I faced.
Monitoring and Debugging with LogRocket
Debugging Next applications can be challenging, especially when users experience issues that are hard to reproduce. That’s why I use LogRocket, which provides full visibility into production Next.js apps. With LogRocket, I can monitor and track state, automatically surface JavaScript errors, and track slow network requests and component load time.