Here at WebDevStudios (WDS), we work on all kinds of projects that use all kinds of base themes and tools. Our internal theme, wd_s, uses Advanced Custom Fields (ACF) in a really cool way that makes it work like a page builder. We also have an internal project converting all of our ACF blocks into Gutenberg blocks. Additionally, we have another internal project converting all of our ACF blocks into Beaver Builder blocks. We really are ready for anything at WDS. It all depends on what’s right for the project, or more importantly, what the client wants for the project.
With all that in mind, I wanted to take some time to discuss both sides of the current debate: page builders vs Gutenberg. To do this, I took a concept and developed it in both to compare and contrast the processes for both. Here are the results.
Our Concept
Before we start building, we need a concept. For this project, I chose a need I came across on my personal blog: the ability to embed a Github Gist into a standard WordPress post. Because I’m either brave or foolish, I use Gutenberg on my personal site. I found inserting a Gist into a blog post is a giant pain as there isn’t a built-in embed block for Gists. As Gru would say, “Light bulb!”
The idea is simple. Build a block/module that allows the user to embed a Gist using two fields, the username for the Gist’s creator and the URL to the Gist itself. After deciding on the idea itself, it took me about 15-20 minutes to pseudo code the idea. Because I was working with two different systems, I wanted a core blueprint to follow as I went along so the blocks were as one-to-one as possible.
Now it is time to build.
The Beaver Builder Module
I started with the Beaver Builder module because I’m more comfortable with PHP than I am JavaScript, and because I’ve been spending a lot of time on the Beaver Builder project lately. The build took me 25-30 minutes, and uses just 27 lines of code (including comments) for the actual module logic. Most of the work came in setting up the fields themselves. Had I not had some experience in Beaver Builder lately, and a stubbed out module ready to copy and paste to get me started, things would have taken a lot longer.
The Gutenberg Block
Next, I built out the Gutenberg block. To speed things up, I used Ahmad Awais’s fantastic Create Guten Block tool. Without it, creating a block would have taken ten times as long. In total, building the block took me around 30 minutes of actual work. Unfortunately, because of the nature of Gutenberg development and my time away from the project, you need to add in 4-6 hours of retraining and debugging to that process. This was largely due to the changes Gutenberg has gone through since I last developed a block myself. That’s where we get to the key differences between Gutenberg and page builders like Beaver Builder.
The Differences
JavaScript vs PHP
The key difference between Gutenberg and Beaver Builder comes down to one main concept: JavaScript vs. PHP. Building a custom module in Beaver Builder was easy because I’m very comfortable in PHP. I didn’t have to retrain myself in anything but Beaver Builder’s specific methods. With Gutenberg, I had to refresh myself in React development, the ever-changing Gutenberg methods of developing custom fields, and JavaScript in general. While some of this retraining comes down to my own personal skill set, the JS vs PHP issue is one a lot of WordPress developers will face. WordPress is a PHP-based system at its core. JavaScript may be creeping in with Gutenberg, but themers are used to avoiding JS unless they absolutely need to use it. That is changing rapidly, and is potentially a big stumbling block.
Compiling and Tooling
Because of the use of JavaScript, a whole new set of tooling is needed for developing a Gutenberg block that isn’t needed with Beaver Builder. This includes Webpack and other JavaScript tooling that is familiar to the modern Front End Engineer, but can be a hassle to get up and running. In my case, all of the tooling was handled by using Create Guten Block (CGB). That saved me hours of setup and configuration. Not every developer is aware of tools like CGB, so that could be a barrier of entry for developers new to Gutenberg.
The Similarities
Plugins Are Required
When developing either a Gutenberg module or a Beaver Builder module, you’ll need to build a plugin. If that’s something you’re not quite comfortable with yet, you’ll want to bone up on it. For Gutenberg, CGB handles the plugin scaffolding for you. For Beaver Builder, there is a tutorial on the Beaver Builder website that will get you up and running.
Programmatic Fields
Both Beaver Builder and Gutenberg set up their fields programmatically. This can be a bit of a pain, especially with Gutenberg. Thankfully, Beaver Builder does a lot under the hood for you. Gutenberg, not so much. You’ll have to code out the logic of the fields yourself. In both cases, most of my work was setting up the fields, not implementing the algorithm itself.
Shared Algorithms
As stated before, the block and module I built used the same concept. Although written in two different languages, I was able to use the same algorithm. This is an important thing to note as you plan out your sites. Should you need to switch gears for whatever reason, not all work will be lost.
Which Should I Choose?
Now that we’ve looked at both, what do I recommend you build your site with? That’s a bit of a loaded question. The short answer for right now is if you’re looking for a block-based page builder, the choice is Beaver Builder. Gutenberg simply isn’t ready yet. It is still in development and while it may be feature-frozen right now, it still has a lot of work to go through before it’s ready for prime time.
That being said, if you want to stay on top of what is happening with WordPress Core and be ready for the future, you need to start playing around with Gutenberg if you haven’t already. While raw, Gutenberg offers a lot of power. What’s happening with Gutenberg now is only Phase 1 of the project. Pretty soon it will completely overtake the WordPress world and you’ll want to be ready.
If you’re still confused by all this page builder Gutenberg stuff, contact us. We’re ready to help you with whatever’s right for your project.
Hey Adam,
Thanks for this write-up. As someone that currently tries to ignore Gutenberg as much as possible, it is good to read about the experience of developers with a similar skill set.
Cheers!
I think most developers ignore it. When running a (plugin or theme) business developers especially with small teams do not have time to keep track of changes in the Gutenberg.
Once there will be a stable API more developers will try to learn and use it, at least this is how i am planning to tackle it ;).
i agree with you