I have been so impressed by Gatsby.js. For those of you who don’t know about it: Gatsby takes content (like from a cms) and compiles a static website. It has the SEO benefits of server-side rendering, with the speed benefits of static assets, and everything is built in React.
There are starter builds that let you take your current WordPress site and get a gatsby build up and running. I dove in and took jschof.com and rendered it out as a gatsby site using gatsby-starter-wordpress. Here was the result…
Out of the box Gatsby starter with gatsby-starter-wordpress
Here is an (almost) out of the box starter build. I can’t guarantee this link will last long- I’m not too familiar with the longevity of surge.sh domains. (surge.sh is an amazing thing in itself, check that out too!).
It is taking my jschof.com site as its source and pulling down all the pages, posts, categories, and tags and setting up a skeleton of a site. It has a simple template built to create the blog page and a nav bar. I tweaked the nav bar.
The process took five minutes to install the gatsby-starter-template build environment. It took 30 seconds to spin up the gatsby development server. It took 90 seconds to build the site. And about 10 seconds to push this build to surge. Now, this is because I have 10 posts and 2 pages to my site.
Why I want to use Gatsby and Gutenberg and WordPress
- If you start clicking around you’ll see why Gatsby has a reputation. The site is blazing fast. If you pull it up on a mobile device, it’s about the same. As far as I understand it, each page that’s built is an entry point in itself, and after the page is loaded, the rest of the site is being preloaded so clicking through the site requires nearly no loading time. Somehow this is the perfect union of static files and single page app.
- It’s also easy. I got this site up with minimal fuss. I got it deployed without nearly any configuration.
- I like how I can let WordPress do the content editing, let gatsby do the view. This is very much like a headless WordPress setup.
Gatsby’s weak spots (a.k.a why I’m not using it… yet)
First, If you click around, you might notice that the content is acting strange. Images are still pointing to my old url. embeds aren’t working quite right. Inline links take me back to my original blog. This is because the Gutenberg editor renders out all of “the content” into one string, and the editor assumes all this content will always be inside of WordPress. Gatsby grabs this content and places it on the page, but it has no idea what’s in the content. this leads to an issue that is common in Gutenberg discussions: how do we let WordPress and other consumers of the content know what’s in the content string? That is being discussed a lot. If we have an image in Gutenberg, how do we handle that image and its url in another setting?
The best solution right now is to manually parse through “the content” when you get it in Gatsby and programmatically change those image urls to Gatsby urls, but after a few somewhat successful attempts at this, I kept running into issues with edge cases. This is a ways from being solved.
Second, if you go to ‘About me’ you’ll also notice that the styles are gone. Actually, all Gutenberg block styles are completely missing. This is because WordPress enqueues the styles separately. Since Gatsby is supposed to be ‘headless’ in a way, I need to copy the styles over from WordPress so Gatsby can include them. This begs the questions: where do styles go then? WordPress needs them, so we need to at least enqueue them for editing purposes. But Gatsby needs them to render them in a build. I could inline the styles, but then you have duplicate inline styles on a page that reuses the styles. If I include them in Gatsby, then the block really isn’t reusable in other sites without also porting the styles over, which feels gross.
The best solution right now seems to include a section of inlined <style> tags with the necessary styles when the blocks are rendered. That would work anywhere… but as you develop the blocks, or even if you edit the blocks, you would lose the content of already saved blocks when you try to edit them again. When you pull them up again you will run into the dreaded “This block encountered an error” as it tries to compare the current block markup to what is saved.
These are pretty big issues to overcome. Currently Gatsby is clear that they just don’t support inlined images. What I find interesting is that the decisions of the blocks markup and data being completely contained in “the content” string is going to be a constant irritation to developers trying creative implementations of WordPress.
Third: you need to rebuild and publish with every change. There is no server that’s rendering out WordPress views on every request, and there’s no caching. So if you create a page, you need to update your static files. Initially this is fine, especially if your site is small, but I’ve heard of some Gatsby sites with 20 minute build times. (Admittedly, many have been able to reduce that by strategically building portions of their site).
Lastly, there’s no place for comments. PHP functionality won’t work here- there’s no server of course. You’ll need to rely more on 3rd party services.
It’s so close
I think the idea is so close to being an amazing marriage. There are just some issues that don’t have good solutions.
Ideas? Solutions? Let me know in the comments or @ me on twitter.