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 with data “burned in”
- Flat Data files to replace slow API calls
reignited my interest in static websites.
The first hit always loads a static HTML file. Blog post? Static file. About page? Static file.
However, once a page is loaded, the site is transformed into a single-page application. Using a modern router, requests to internal pages will dynamically load components and data as-needed instead of linking to the flat, rendered file. Pre-rendering a single-page application has always felt somewhat precarious and expensive hack to get the benefits of both indexable content and sites that are fast to deliver.
At day’s end, JAMstack generators deliver 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.
I started working with Gatsby and wanted to love it. But I found the way WordPress data was reshaped in
gatsby-source-wordpress more frustrating than beneficial — I got to the point where I made custom API calls and manually inserted data into the store because it was easier.
In general, I found the nomenclature and codebases in Gatsby a bit obtuse and unpredictable for my own background, whereas I find the Gridsome codebase highly-predictable and sensibly organized. Perhaps because some of the Gridsome developers have built popular, premium WordPress themes.
While I write JSX and React at work, I still find I prefer writing Vue — it flows from my fingertips more naturally, but it’s more than that. React has borrowed some of the great ideas Vue pioneered with Single-File Components and is making some great strides with hooks and suspense to offer powerful tools to developers… but I often find writing “good React” much more time-intensive than writing “good Vue.”
In the end, my personal reasons for choosing Gridsome boiled down to:
- Reduced Context Shifting – Having the data query, template markup, style and logic all well-organized in a single file is hard to beat. Because most Vue code starts with hierarchical
<template>markup, I find it’s easier to eyeball if a component is right-sized or overgrown than scanning styled components and other common React syntax.
Gatsby is a strong fit if:
- You love React, Angular or Ember.
- You love JSX syntax and CSS-in-JS.
- You need all the features and plugins right now.
But for me Gridsome was a better fit for a number of reasons:
- You love Vue or jQuery.
- You love the Cascade in CSS and syntax closer to HTML
- You can live without taxonomies and plugins for everything, for now.
Headless WordPress: For Consumers?
I’m excited to see more prosumer/consumer JAMstack sites and WordPress-side plugins to help make it happen.
But there are some shortcomings still to iron out before this kind of tech hits mainstream:
- It Takes More Than Glue To Build Bridges – Most steps to getting a WordPress-powered JAMstack site setup are fairly simple, but add up quickly.Setup WordPress.
- Commit code to Git repository.
- Connect repo to build service (Netlify/Amazon Amplify) or build server.
- Create secure connection between WordPress & build service.
- Configure DNS & serve generated site via CDN.
- Authentication Still a Challenge – More on secure connections: Authenticating securely to the WordPress REST API outside the WordPress Admin is still hard. Sure, you can setup a read-only API token. Sure, you can isolate server IPs, lockdown firewalls and use Basic HTTP Auth. Sure, you can use serverless functions as a middleware layer. But there is no Plugin to install or one-click solution — whatever you do, you have to build.
- You Still Need a WordPress Theme – WordPress still requires you install a theme. In time, I’d love to see a standard “HeadlessPress” theme to handle some universal configuration.
- Generating Content Previews – To get a Post Preview from the WordPress Admin as content would appear in your JAMstack site requires rebuilding the template using PHP (and maintaining two disparate codebases for the same design) or normalizing the data in PHP to be ingested into JS components.
Some of these problems — such as API authentication in WordPress — aren’t unique problems to JAMstack sites. I fully expect Previews-as-a-Service, authentication gateways and standard helper Themes/Plugins to grow over time.
In future posts, I’ll dive more into how I built this site and some best practices for setting up a JAMstack generator with WordPress!