Why we’ve decided WordPress isn’t enough

WordPress has brought CodersClan a long way. It’s been a fantastic tool, which has helped us to build some incredible sites for our customers.

But every tech stack needs updating. We feel that WordPress just isn’t enough...

(Well, mostly.)

Our tech stack is our toolkit. Every craftsman wants to work with the very finest tools available, so we’re always trying to advance our stack to the highest possible standards.

A long time ago, we started by using standard WordPress PHP templates, changing the files through FTP. We then evolved to create our own themes with PHP blade templating, SCSS, continuous integrations and dynamic templates, using advanced frameworks like WPEmerge and Sage. It’s served us well. But even the best tools need sharpening every now and again.

A few months ago, we realized that we’re working on really high-end projects using a framework that we’ve taken to its limits. So, we decided to experiment with React, and specifically with Gatsby.

After building two internal websites and one customer website with Gatsby and Contentful, we’ve decided that Gatsby might be the tool we need to shape and refine the high-end projects our customers expect.

Why? Let us explain.

Some brief name-dropping

Before I get too deep into this, I must introduce you to the key players I’ll be talking about: React, Gatsby, and Netlify.

• ReactJS is a widely used javascript library used to develop web applications and websites. It uses a concept of single page application similar to that of Angular, Next and Vue.
• Gatsby is an SSG — static site generator. It’s a framework based on React that’s used to generate static sites. It runs on the JAMstack concept, which uses javascript and markup to generate static pages that will run on any web server capable of serving files.
• Netlify is a static file host, similar to S3 but with plenty of additional features which help streamline the development process. It makes lives a lot easier with auto deployment, merge requests, previews, and other nice stuff. Plus, it’s free, which is always a bonus!

Our new stack will be using headless Wordpress as a backend (just as a CMS), a React framework named Gatsby for the frontend, and Netlify as the new hosting.

Why the change?

From a customer perspective, Gatsby has four main benefits:

• Better performance. The number one reason to move to a static website is the performance. Both user experience and Google page speed insights gain better results due to the static nature of the site and the advanced technologies that come with React.
• Increased security. Static rendered pages don’t have WordPress vulnerabilities and there are no server-side attacks like SQL injections as there’s no actual public server. They’re also much easier to protect against DDOS attacks.
• SEO improvement. Besides getting an SEO boost just by increasing performance, Gatsby also creates a dedicated website version for search engines and brings a toolkit for SEO adjustments.
• Faster development. In some cases, it will be easier to develop new sections and components in React than in Wordpress because the frontend development is decoupled from the backend.
• Community. Gatsby also enjoys React’s community which helps with newer libraries and advanced development tools.

We’ve not abandoned WordPress entirely, though. There are three major reasons we’ve decided to stick with WordPress as our backend:

• Familiarity. WordPress has served us well for years. We don’t want to abandon features we know and which serve us well. We’ll carry on using many of our favorite WordPress features (for example, we’ll be using the same known CMS, Yoast plugin, ACF and WordPress menus). With WordPress as the backend, nothing changes from an admin perspective making sure our customers (and us) don’t spend learning a new system.
• ROI. While using Saas solutions like Contentful / Prismic / Datocms makes more sense from a development standpoint, the pricing quickly climbs into hundreds of dollars.This just doesn’t make financial sense when WordPress gives us a low, fixed price cost without limitations.
• Having a backend — just in case. The technical advantage of using Wordpress is that if needed, we can use backend functionality in both ajax calls or build time. This makes integrations with other platforms possible. CMS as a service can’t provide this.

From our own perspective, we also get additional benefits as a development team:

• Decoupling of frontend and backend development. Since the frontend is using React and the backend will just provide a rest API for the frontend, we will use separate repositories for backend and frontend. Frontend developers will be able to work on a component without even having the API ready, and just connect the API once the backend work is done. Also, since the repositories are separated, there won’t be any conflicts between frontend and backend work.
• Development Team. Since we took Wordpress to the extreme, it’s much harder to find skilled developers capable of working with our WordPress stack.There has been an increase in skilled developers who are extremely good at working with React.
• Market advantage. We’re a spearhead technology team, working with (and towards!) the very best of the best. We’d like to be easily identified as such. Because it is years ahead of standard WordPress development, React gives us a serious competitive advantage.

Let’s not leave Netlify out of the equation. Netlify hosting also gives us significant advantages:

• Preview per merge. Netlify’s preview per merge request means that we don’t have to merge a feature branch to see the result. We get a dedicated URL which we can share with the customer for approval, or can use for QA.
• Out of the box CDN for static files. This actually caches all of the content — not just images and assets, but the HTML itself. This makes the website load even faster than other CDNs.
• One click rollback. In case of a bad deployment or unwanted content publishing, Netlify supports one click rollback.
• Other addons. We love many of Netlify’s addon features, including analytics, server-side functions, website users authentication and forms.

Sounds good, but how does it work?

The main difference when using a static website is that there’s no server side rendering, which means the code compiles during build time. Visitors see a static version.

The way WordPress or any other server side website render works is this:

1. Visitor requests a page (let’s say the homepage).
2. If the homepage exists in the CDN or cache, the static version will be delivered.
3. If the page isn’t cached, the server will run the PHP code of the page. This will use the PHP code of the sections, which will use the PHP code of the components.
4. The components code will have to reach out to the database to fetch the actual content.
5. The server will then compile an HTML version of the page, including the text and links to other assets like CSS and images.
6. The browser will then have to request the CSS files and the images to actually show the page, usually also running several JS code to manipulate the page.

With a static site generator, the process works quite differently:

1. Visitor requests a page.
2. ALL pages are in the cache, no exception. The static page will be delivered.
3. If a visitor switches a page, there will be no browser request. Instead, there will be an AJAX request. This makes the user feel like they are using an application and not a website.
4. The page is built as Javascript code that builds the pages on the browser side using a pre-built static version with the content inline, sometimes including the critical CSS for faster rendering.

Can you break that down a bit further for me?

Sure.

The magic happens during build time. When doing any kind of change, the Gatsby framework will fetch the list of pages in WordPress, their sections, components and content.

It will then build each page, based on the code and content, and will compile it to a static version of the page.

Once all pages have been built, the CI/CD will push them to Netlify’s cache and CDN.

Wait, you build the entire website for any content change??

It’s really not as big a deal as it sounds. Even for a huge website with thousands of pages the build process only takes a few minutes.

Using a webhook from WordPress to Netlify, we can trigger a build every time content is published. The process is seamless for the customer.

Regardless, Gatsby recently announced a new feature of incremental builds that will allow faster build times for the delta only. So re-build isn’t a big deal as it sounds.

OK, you’ve convinced me. It sounds very shiny, very full of unicorns! So…why isn’t everyone doing it?

There are some downsides. While they all have solutions, it’s still a paradigm change which many companies are reluctant to contemplate:

• No backend. Gatsby has no backend, which means that there is no form support and no way to use server-side functionality (like user logins, e-commerce, comments etc).
• Lack of access to WordPress plugins. When using WordPress as a headless CMS, most of the WordPress plugins ecosystem can’t be used. The main issue with this is that page builders such as elementor, WP berkeley and beaver builder are out of the question. We don’t use these builders much, but other agencies do.
• Speed. Though a deployment isn’t a thing to be afraid of, it’s still slower than basic content published in WordPress. It might take a few minutes for content to show for visitors, and sometimes (especially when the CEO is looking), you want to change content as fast as possible.
• Cost. While having a free tier, higher tiers of Netlify hosting costs money — especially for websites with high traffic and a lot of deploys.
• ‘The good enough is good enough’. If your customers don’t need to be dazzled, a simple WordPress with a page builder will be ‘good enough’.
• Novelty. React is cool, but Gatsby is still relatively new compared to WordPress. Some things which are well established and well known in WordPress will require additional learning and effort with Gatsby.
• Training. Migrating to a new tech stack means that everyone needs retraining. This can slow down delivery for the first few projects.

Bottom Line

It’s easy to stick with what we know. Old tools feel comfortable and familiar, and we know how they work.

But things change. Tools get old. If you’re going to do the best work you possibly can, you need to revamp your toolbox every once in a while. Broken tools need throwing out. Blunt tools need sharpening. New tools need adding.

New tools like React and Gatsby are just what we needed to give our tools that cutting edge. React and Gatsby have a lot of potential and promise for the B2B marketing world. We think it’s just what we need to rise above the crowd and create the best websites out there.

If Gatsby sounds cool and if you’d like to join us in making this change to the web development world — check out our careers openings here.