My first impression of Gatsby Days LA, was how different it felt compared to other conferences, especially WordCamp. The main difference being, WordCamp feels more focused on the user experience while Gatsby Days was more focused on the developer experience. Of course, this is a general assumption and there’s a lot of overlap between the two. It’s just heavier on the dev side at Gatsby Days which is refreshing for me personally. That said, the biggest thing both events have in common is a vibrant and active community.
It’s clear that Gatsby Cloud is a major priority for the Gatsby Team. Everything from the session topics, integration roadmap, and the future goals of the Gatsby team, Cloud as a product is going to be the next big thing in the Gatsby ecosystem if it’s not already.
The Gatsby Cloud initiative makes a lot of sense for a few reasons and it’s ultimately a good thing. The obvious one is that it gives Gatsby a steady revenue stream which is great for any Gatsby developer, even those not using Gatsby Cloud. I’m a firm believer that the innovations made may the open-source team solving problems for cloud as well as the engineering team behind it will make its way into open-source. They’ll be working on the largest, most complex Gatsby sites out there. The problems they solve will be challenging and the entire community will benefit from their hard work.
Another interesting thing about Gatsby Cloud is when you think of other static site generator frameworks offering similar services. Open-source runs through almost every project a modern web developer touches today, but the platform to which they run those frameworks typically has no association with the framework. Gatsby Cloud changes that. It offers expertise from the framework creators as a product. Some of the most successful companies have done this and one of the most notable is Apple. They own the hardware and software they offer to their customers. That decision gave them an edge for creating a product unique to their customer’s needs. It’s efficient to offer both but it may also be crucial to compete with other frameworks in the growing SSG market. I’m excited about the future of Gatsby Cloud. It’s a purpose-built tool for Gatsby developers, it’s crazy fast and solves a ton of problems.
It’s important to note that Gatsby Cloud is not an all-in-one solution. As I mentioned, it’s a purpose-built tool created to solve problems. Hosting is not one of those problems. Gatsby Cloud concentrates on the two most difficult things: Builds and Previews. For hosting, more than a few providers are offering this and they do an excellent job. Hosting static sites with Netlify, AWS Amplify, ZEIT, and more is still best practice when using Gatsby Cloud. It’s good to recognize this as even we (Shifter) offer integrations to deploy static WordPress sites to Netlify.
In almost every keynote at Gatsby Days, builds were mentioned. As enterprise users or sites with a deep dataset move to Gatsby, the build times get longer and longer. Gatsby Builds offers a unique caching system and build an environment that can reduce the build time from hours to minutes.
I’ve thought about ways to replicate this with a DIY or roll-your-own setup on AWS Amplify or Netlify but you’re going to miss a lot. First, you’ll own the stack and config. I spent a lot of time tweaking my environment on AWS Amplify to match Gatsby Cloud build times but it’s not an easy task. Second, if you did match the same container enviornment you’ll need to maintain it and you still don’t have features like Preview.
During a few keynotes, there were some goals mentioned like build times below 10 seconds or instant. I don’t think we’re too far off considering how Gatsby Cloud works. Near-instant build times may also be something we see soon but I don’t think it will be a result of perfecting our current workflow or process. To get there they’ll probably need to approach it in an entirely different way.
The number 2 hot topic of Gatsby Days was preview. it’s personally my favorite feature because it focuses on the end user and makes Gatsby a viable option for a lot of teams and developers who may not be able to use it otherwise.
Gatsby Preview offers a way for users to view changes on the front-end as they happen on the backend without builds. Create a new post of page and view the preview link as a staging environment to view changes before going live. Before this, viewing any changes would have to happen locally, on a development server you maintain, or create a built and hope for the best.
The Shifter team faced this same problem a while back. We wanted to give our users a way to create their static sites and view them before they were published. So, we created some options for how artifacts are deployed. Users on Shifter can create static sites, preview them and deploy them only when they want to. We call this feature Shifter Preview and Auto Deploy. The biggest difference between preview on Gatsby Cloud and Shifter is that our users are running WordPress and what they see there on WordPress preview is what they should get with Shifter’s static site generator.
I learned a new term at Gatsby Days too. CCS or Content Creator Experience was new to me and I’m glad I was introduced to this term because I’ve referenced this persona a lot. When talking about JAMstack and WordPress, a common example is developers using Markdown. Developers love Markdown, end-users have no idea how to use it and they don’t want to use Git to publish new blog posts. That’s why WordPress is still a favorite among content creators. That whole interaction is the CCX.
There’s a lot of opportunity between WordPress and Preview on Gatsby Cloud. The one area that sticks out is how they work together. Some keynote speaks gave examples of custom functions they create to help content creators (improving that CCX!) but there’s nothing standard yet. It seems strange for the Gatsby Cloud team to create an official WordPress plugin but it may be the best way to go for reducing friction between the two platforms. There will be an official Gatsby Theme for WordPress that’s currently under development but that’s not specific to Gatsby Cloud.
WordPress and Gatsby
The interest in using WordPress with Gatsby is by far the greatest among any CMS provided in the community. Any contributions to Gatsby that improve the experience are welcomed. Is it essential to the success of Gatsby? I wouldn’t say yes, but embracing the WordPress community and helping those users onboard to a new framework that complements the work they are already doing is going to go a long way.
There are a few key areas that Gatsby needs to improve the WordPress experience.
Documentation and Starters
Gatsby needs to offer more official starters and courses to help onboard new users from WordPress to Gatsby. It seems that most of the WordPress developers using Gatsby are engineers or software developers. The next phase of Gatsby’s growth will depend on making it easier for average users to get started.
The #NoCode Mission
During the first keynote by Kyle Mathews, he mentioned that #NoCode was a goal for Gatsby. They want to eventually allow users to create WordPress sites, connect it to Gatsby Cloud and launch it without writing any code. I think this is absolutely something that can be done and the parts we need to make this happen may already exist. It’s just a matter of designing a system for this purpose.
Themes and Plugins
The ecosystem of quality themes and plugins is small. That’s to be expected with a new but growing community. There is a big difference between starters and themes but most users don’t know the difference. The WordPress community thrived and boomed once themes took off. Could it also happen with Gatsby? I think so.
Gatsby Source WordPress Plugin
The new Gatsby source WordPress developed by the Gatsby team seems to be the first official step towards connecting the two communities. When Jason Bahl joined Gatsby he brought a wealth of knowledge from his WPGraphQL experience to the Gatsby team. It will still be a favorite for anyone sourcing content from WordPress, especially outside of Gatsby, but the new official source plugin rewrite is designed just for Gatsby and WordPress.
The new source plugin is a dramatic improvement over the current options. I was hesitant to think it was a necessary rewrite but after getting a demo by one of the plugin lead devs, Tyler Barnes, I was impressed with the direction it’s going. The new source plugin offers more options for working with large datasets, developing sites locally, and deeper integration with WordPress. For example, if you have a thousand media uploads in your WordPress site but you’re only using 1 of them, you only query and pull the one you’re using.
The future of Gatsby and WordPress looks like a good one. There will always be clickbait articles saying one will replace the other like JAMstack will succeed WordPress but I don’t believe that’s the case. They are dependent on each other for a lot. Embracing everything between the two communities for expertise, sales, inspiration and more will be important to their success.