Differences from Legacy Theme Development
There are some major differences in the way we will approach block theme development. Here’s an outline of the key differences:
No More Build Steps
Previously, in order to take advantage of technologies like SASS, modern JS, or just performance optimizations, we would have a build step in our theme development to compile these assets. This had its advantages and also drawbacks at the time, but with the modern web environment, many of the advantages build steps brought can be solved natively.
SASS
Sass is a great tool for writing efficient and DRY code. The major characteristic being SASS variables. However today, CSS custom properties are widely supported and allow us to define variables directly.
Browser-prefixing was also a technique to automatically add browser prefixes to your CSS properties, making your styles render consistently across all browsers. Today, browser prefixes are needed much less because browsers release features much more quickly and collaborate on implementations. Therefore, we don’t need a build step to add all of these automatically. The few times they may be needed they can be added manually without much extra effort since there’s not as many needed for cross-browser support.
Optimization / Performance
Build steps were also used to minify CSS and JS, optimize images, and bundle everything together in one file. This led to greater performance with HTTP 1.1.
With HTTP 2, bundling everything together doesn’t necessarily make for better performance. HTTP 2 and also carefully building your HTML assets can let you page download its assets in smaller parallel requests that don’t block the page rendering. Essentially, more smaller requests can actually be good for your performance nowadays. WordPress blocks fit well with this since their assets (CSS, images, and JS) are defined per block and only included in the page when used. So we may get a lot more smaller CSS and JS files in our page, but this shouldn’t affect page performance.
For a long time now, even during legacy theme development, not many images were bundled in the theme and so the build step to optimize images wasn’t even that important back then. As much as possible, images should be handled by WordPress media manager and so we can optimize our images simply by:
- Optimizing the image before uploading (use webp)
- Adding a plugin to optimize and convert to webp automatically
ES6
Taking advantage of the newer ES6 javascript syntax and features was also an advantage, but since this is now widely supported, we don’t need to transpile it in a build step with something like Babel.
No More Deployment Pipeline
Because we utilized build steps in our deployment process, we needed a consistent and automated way of running those steps before deploying to stage or production.
But with no build steps, there’s little need for a complicated deployment pipeline. On the upside, avoiding pipelines like this altogether helps simplify the development setup and amount of things that can go wrong during deployment.
No More Versioning with Git
Versioning our website’s code has always been an essential process to developing modern WordPress sites. But without the build steps and need to trigger a deploying pipeline, it’s worth rethinking why we’re versioning our site.
- Easier collaboration amongst developers
- Ability to backup, track and rollback to the difference states of the website should we need to
- Be an integral part of a deployment process. Usually the push event to a certain Git branch is responsible for triggering deployment.
- Uniform distribution of code to setup and develop projects locally.
In light of our new block based process, let’s re-examine whether these features are worth the complexity of the Git technology.
Easier Collaboration
It is indeed true that using Git to collaborate on code is essential. However, over the years of using Git in our relatively small dev team at Motto, I’ve realized there’s seldom more than one developer actively working on the website’s code base.
Most collaborative work was done on the content level once the site was ready and we needed to create all of the pages and content for a presentable public ready website. WordPress already has protective mechanisms built in to avoid working on the same content at the same time.
With a team our size, 1 person was primarily always responsible for the majority of the development and would often hand off the project to other developers and move on to something else, so merge requests were a rare occurence.
In the case of block-based themes, there is even less raw coding happening and more content editing and so the need for code-collaboration is very low. We can easily navigate the process without the use of a tool like Git. Your mileage may vary depending on the size of team you have working on your WordPress site. For us, it’s not worth it.
Backups
Any proper WordPress host will offer a certain frequency of website backups to its customers. In Motto‘s case we use Kinsta who make a daily backup of all of our WordPress sites. Rolling back to these daily states is very simple and quick so we don’t need Git to fulfill this functionality.
Deployment Process and Local Development
Since we have no build steps to trigger and most of the dev and content work is done directly on a stage, a deployment process is no longer needed. In fact, local development itself isn’t even needed and so there is only really one deployment that’s needed which is going from stage to production.
If the site doesn’t have any user input, like an e-commerce site, we can safely clone our stage site to production using our host’s automatic tools. If it does, we must manually deploy our changes, but this is the case regardless of whether we are using block-based themes or standard ones. The upside is that it’s actually very easy to manually deploy updates because copy pasting blocks in the Gutenberg editor works really well.
Since most of our development is now happening directly in WordPress, there is less and less need for a complicated local development setup, which saves tons of time and headache. Read more about how we’re getting rid of local development.