I want to start by saying that I didn’t want to do a Gutenberg vs Beaver Builder comparison, since in their current state I don’t see them as direct competitors. However developing for both tools is different enough I decided to write a comparison between developing for Gutenberg vs Beaver Builder, and why my preference is Beaver Builder.
Despite my preference of developing for Beaver Builder I think Gutenberg is a dramatic improvement over the classic editor and will be the foundation of a new era for WordPress, and you can read more about that in my WordPress Gutenberg Review.
My Development Environment
I’d like to give an overview of my two primary development environments as this is part of the basis for my preferences.
- Personal Development Environment
- I regularly work on a Mac OS X computer and Windows 10 computer. I use OneDrive to share all of my files between the two computers. Each are setup with Node, PHP, Phing, Git, etc. I develop directly on my dev web server (ssh-on-save) and then build and deploy where necessary. This allows me to move from one computer to another with no interruption, and no need to maintain a XAMP stack on each local computer.
- Work Development Environment
- My work environment is very similar, except that I’m working exclusively on a Windows 10 computer and all files are saved on a local network drive so that they can be shared with co-workers. We’re utilizing a dev/stage/prod server setup there as well (with ssh-on-save to dev).
Programming Languages
I also want to make it clear that I love both PHP and JavaScript and enjoy working with them both on a daily basis. The one caveat is that I question if JavaScript development is heading in the right direction. The features being added to JavaScript (at a rapid pace) are fantastic, but with the advent of NPM, and the desire to use modern features (not always supported by browsers yet), a need for build tools has become the norm and dramatically increased project complexity. For several years there was a growing sense across the web development community that jQuery was gross and added bloat to a site and that clean vanilla JS was superior (I don’t necessarily disagree), yet today we seem to have no problem including Bootstrap, React, Redux, among whatever other dependencies we need. This doesn’t even touch on the 1,500+ files used to create a “Hello World” React app (using create-react-app). All of that is to say that I question the wisdom of following suit with the WordPress editor, and my skepticism certainly affects my preferences between developing for Gutenberg vs Beaver Builder.
Why I Prefer Creating Modules Over Creating Blocks
Developer Reference
When learning to develop for a new tool one of the most important things is developer/API reference and examples. Both Gutenberg and Beaver Builder have solid developer reference, however in general I feel that Beaver Builder’s is better organized. Its examples in the reference (and the modules within the plugin itself) are also a great source of reference and the vast majority of the time code can be copied directly into your own custom modules and it will work. Conversely, Gutenberg is attempting to remain as developer friendly as possible and has provided reference in ES5 and ESNext (ES6+ and JSX), but there isn’t always example code in both versions, and there isn’t always context surrounding the code letting you know where/how it should be used.
Build Tools
If you’re serious about making Gutenberg blocks it’s all but mandatory to use build tools (node/webpack/babel/etc). Without this your project could end up enqueuing dozens of JS and CSS files, and none of the ESNext/JSX code will run in the browser. Getting your project setup to properly use these build tools is one of the biggest hurdles to get past when first starting out with Gutenberg, especially if you’re not already using them for other projects (such as React). As mentioned earlier I work off of a remote development server so this type of workflow isn’t ideal as I have to build (or have webpack watching my files and auto-build) and then upload them to my remote server to test. This adds an extra step and is less efficient, and if anyone has any recommendations as to how I could improve this workflow please leave a comment!
Alternatively, with Beaver Builder there is no need for build tools as there is no need for ESNext (unless you just really want to use it) or JSX. On top of that, to prevent dozens of JS and CSS files from being enqueued Beaver Builder renders out all of the necessary dependencies for a given page and caches that as a single JS and CSS file on the web server. So, as long as a module has been built correctly it’s as simple as editing your files, and saving them, and Beaver Builder handles the rest.
Programming Language
The vast majority of code for Gutenberg blocks is intended to be in JavaScript. This is fine in many cases, however it also means that any data used in BlockControls or InspectorControls that cannot be derived from the content itself, or is dynamic in nature must be piped to the front-end. So, any existing code bases where the data already exists in PHP must either be modified to make it available on the front-end (possibly by localizing it) or extend the Rest API so that it can be fetched. In an of itself this isn’t a problem, but it can add development time to a project.
Alternatively, Beaver Builder controls are defined in PHP as a series of nested arrays and they can be dynamically built using data already available in PHP, with no need for extending the WP Rest API or making Ajax API calls. This has been beneficial for me in several projects over the years I’ve used Beaver Builder as I was able to take an existing PHP app and build a Beaver Builder module for it with very little code duplication by utilizing the apps existing APIs.
Rigging a Block or Module
In order to setup the skeleton for a block you need to add necessary fields (components/elements) to a BlockControls or InspectorControls component and then setup all necessary event listeners. This is both a pro and a con as it gives you complete control over how everything is setup, but you also need to setup everything to make sure the state is updated as inputs change.
On the other hand, with Beaver Builder, rigging up a module is as simple as creating nested arrays that define the controls and their behavior – the vast majority of the time there is no need to worry about module state or event handling as that’s all taken care of by Beaver Builder itself. Once in a great while I’ve found the need to create my own field types, but that’s been a rarity. It’s so incredibly easy to setup advanced/complex input controls, such as repeatable sets of controls (called forms, that are re-usable throughout a project, in Beaver Builder).
Experience and Familiarity
Without any doubt I have more experience creating modules for Beaver Builder than creating blocks for Gutenberg. This is largely due to Beaver Builder being around several years longer than Gutenberg. Regardless, as open minded, and objective, as I’m trying to be about Gutenberg this experience, and familiarity, creates a natural bias towards Beaver Builder and this is something of which I’m very well aware. The flip-side of this is that once Gutenberg has been around for as long as Beaver Builder it has huge potential to be much more than it is right now.
The End Product
Gutenberg is now part of the WordPress core so it’s incredibly appealing to developers (including myself) to use a standard that is likely to be a part of WordPress for many years to come. On top of that blocks are super portable between instances of WordPress since there are no plugin dependencies. This is an undeniable benefit of Gutenberg over any third-party page builder product. Lastly, there will naturally be more designers, developers, and editors within the community than any plugin could ever hope to attract.
In spite of how I began this review, stating that I didn’t want to directly compare Gutenberg to Beaver Builder, it’s difficult not to when comparing the end product of a block vs a module and the environment in which each resides. Another way of putting it is that the sum of the editing experience is comprised of more than a single block or module, no matter how great they may be, but rather by the experience of using the editor or page builder as a whole. In each of their current states Beaver Builder has immeasurably more flexibility and features than Gutenberg and I know that my custom modules can easily be used in countless different ways.
In the end, I actually do enjoy creating blocks for Gutenberg; I just prefer creating modules for Beaver Builder.
Leave a Reply