I'm an Interdisciplinary WordPress Developer at Bluehost, where I focuses on helping build WordPress and supporting the WordPress community.
This website is my first step into JAMstack and second attempt at a maintainable, personal, headless WordPress website.
Earlier this year I built a version of this site using Quasar Framework, which is a great, exhaustively full-featured framework, but also wasn’t the right tool for the job and cumbersome to maintain on my own.
For months I’ve been impressed with Gatsby. It’s got incredible performance, incredible image handling and brilliant prefetching. It would take vast, complicated amounts of caching, tweaks to media handling and other tricks to get a full WordPress site as fast as a JAMstack site.
So my original plan was to spend time at the end of the year to build “a blazing-fast site” in React and Gatsby.
When I discovered Gridsome, a Vue-based tool similar to Gatsby, I was all-in on JAMstack.
Why the JAMstack?
The approach pioneered by Gatsby of creating the trifecta of:
- Rendered HTML files
- Flat Data files
reignited my interest in static websites.
The first hit always loads a static HTML file. Once a page is loaded, internal requests dynamically load components and data as a single-page application. Pre-rendering a single-page application has always felt a precarious and expensive hack.
At day’s end, JAMstack sites are the SEO and security benefits of fully-rendered files with the speed and interaction benefits of a fast, single-page application, without radically rethinking how we write code, where we create and store content and without requiring a hefty server.
With Gatsby & Gridsome, there’s the added benefit of using GraphQL to interact with a normalized data layer, whether that data originated from Markdown files, a REST API, a GraphQL API or YAML files.
Why after trying Gatsby and Gridsome, I chose Gridsome
Gatsby, the React-based, first-to-market JAMstack library, is a strong offering, with a robust ecosystem and some more natural synergies for reusing components and code between the new WordPress 5 Block Editor and a site frontend.
But I’m not a huge fan of the opinionated approach in gatsby-source-wordpress. I’m not a huge fan of how it reshapes data, nor some of the code naming conventions and file organization throughout the Gatsby ecosystem.
My personal take is that React is highly powerful, occasionally obtuse and inconsistent in docs quality. That’s my general takeaway from a few hack sessions on Gatsby as well, though their docs do a better job of catering to entry-level developers than much of the React ecosystem, I still found them inconsistent in quality compared to Vue.
While I see where Gatsby has pioneered some new concepts, I found the View Structure in Gridsome much more straightforward, and despite the fact Gridsome hasn’t yet shipped Taxonomies, Service Workers and some other niceties Gatsby offers, I found half-a-day in Gridsome got me farther than a day in Gatsby.
Part of what makes Gridsome so nice is Vue Single-File Components, including
<page-query> elements for running GraphQL queries against the data store. I the approach to splitting Vue/Gridsome apps demands much less context-switching than React/Gatsby apps.
Many PHP-heavy projects have adopted Vue for frontends (Laravel Nova, Pagekit CMS), so perhaps Gridsome makes more sense to me because some of the Gridsome developers have built popular, premium WordPress themes.
I’m excited to see more prosumer/consumer JAMstack sites and WordPress-side plugins to help make it happen. Before this stack can really begin to enter mainstream for use with WordPress, features like Post Previews, easy rebuild on content changes and other long-difficult tasks like external authentication will need to get easier… but now there’s even more reason to work on them.