For the last two and a half years, Hugo has been my static website generator of choice for several projects including this one. I have a lot of praise for it, including its blazing fast performance and the general quality of its code base and documentation.
The change to Gatsby is driven by a profound desire to make the most of my time, to stay relevant and sharp as a developer while having more time available for all my creative activities.
In my pursuit of a streamlined development ecosystem that would be modern, elegant and enjoyable, future proof, performance and feature packed and would provide adequate answers to all my web and app development needs, React and its mobile extension React Native had been growing on me over the last few years.
Not the least of them is the ability to easily pull content and data from any content system (markdown, headless CMSs, APIs, databases). Beyond a single source of content, Gatsby makes it possible to architecture a project around a content mesh, stitching together data from multiple sources. I can already envision the opportunity to source a product catalog from an e-commerce platform such as Shopify while managing other content assets with a headless CMS like Contentful.
Being the only contributor to this website, I am sourcing all content from markdown as was already the case with Hugo. However, for commercial projects, Gatsby offers great flexibility in the selection of the right content management approach for a given project and client.
My first experience with Gatsby has also confirmed some of the other stated strengths of the framework, such as static PWA performance out-of-the box, automatic code and data splitting, prefetching, optimized SEO, and a rich plugin ecosystem.
At this point, reducing build times is my biggest concern. Gatsby is not slow but even with the modest amount of pages making up this website, it is clear I have left some build performance on the table. While not prohibitive in this case, identifing optimization opportunities to reduce build times further is one of my top priorities going forward.
Further validating the move into React territory is the existence of other rising options depending on a project’s requirements and typology, in particular the Next.js framework and its server side rendering capabilities.
Visit the xavierwendling.com project page if you want to know more about its various aspects and its evolution.