Rebuilding My Site with Next.js

Reflection on Gatsby

When Gatsby came out, I was thrilled to use it on a project. Building a static site generated from dynamic content was an idea tossed around by colleagues early in my career. The thought of reaping the performance benefits of serving static files while retaining the editing ability of a traditional CMS and server rendering was quite exciting.

I built the first version of my personal website using Gatsby and a headless WordPress instance as its data source. In practice, Gatsby was a great solution that I'd use again in a heartbeat for small client info sites. However, there were some downsides to my experience.

Inversion of Control—AKA Magic

Gatsby is handling a ton of things under the hood with its complex plugin system. There's a plugin for seemingly anything you'd like to do, and they're mostly reliable. However, when things go wrong, it can be difficult to diagnose the issue. And unfortunately, some plugins have been abandoned by their creators, so solutions might require forking the codebase.

Webpack is Slow

Webpack has been the industry standard bundler for years, and despite being horribly complicated to customize, it has gotten the job done for most of my projects during my career. However, there are newer, faster bundlers on the scene, such as Vite, which my recent teams have used on new projects. Without realizing it, I've gotten used to its speed, so going back to Webpack feels super slow! I made an attempt to rebuild my site using Gatsby, and Webpack made it feel old and clunky.

No Backend

Gatsby is a JAM stack framework, so what you ship is a client-side-only application. This means any server-side functionality has to be built separately. When I began building my site, I didn't anticipate needing a backend, but I figured I could use microservices if I did. One day, I decided to add a contact form, and surprisingly, I struggled to find a microservice that was suitable for my needs. I quickly grew tired of the search and opted to just build a quick API using Laravel, which kind of defeated the purpose of using the JAM stack altogether.

Why Next.js?

Next.js has grown in popularity over the years since Gatsby came onto the scene. At the time of writing this, Next.js now has twice the Github stars that Gatsby has, at over 109,000 stars. Popularity isn't always an indicator of what's best, but it does signify what technologies your future colleagues might be using. Gatsby is great, but I'd rather put forth effort mastering a technology I'm more likely to use during my future career.

Static and SSR

Popularity aside, Next.js has the feature I love most about Gatsby: static site generation. Page loads feel just as snappy as Gatsby and on top of that, Next.js has server-side rendering (SSR), so real-time dynamic content feels more like static content. That's because it's fetched on the server and sent along with the initial page load and can be cached for other users. Gatsby would have to perform an additional fetch after the page load resulting in load spinners and slight frustration. I should mention that this isn't a feature I necessarily need for my blog, but it would be nice to have for bigger projects.

Quick API Endpoints

Regardless of how small your site starts out, you may eventually want a backend. As mentioned before, my Gatsby site started out completely static, but eventually I wanted a contact form, so I built the form API using Laravel on a separate server. This server became a wasted resource that I ultimately took down.

With Next.js, an API endpoint can be added as easily as any other page. And, unlike my Laravel solution, an API endpoint wouldn't require an additional server. Next.js API endpoints are basically little Node.js lambdas, making them easy to create and reason about. This makes Next.js appealing for both small and scaling projects.

Conclusion

Gatsby was way ahead of its time and definitely paved the way for Next.js. I don't know if I'll ever start a new project with it or not. We'll just have to wait and see what the Gatsby team ends up doing with the framework.

Next.js seems like a better technology to invest time and effort towards mastering, since it's such a versatile framework. With it, you can build tiny websites or massive applications. For the time being, it will be my go-to framework until the "next" big thing comes our way.