Gutenberg is WordPress’s most favoured feature in the upcoming 5.8 update of WordPress. Auttomatic (WordPress team) has been working on it for past 4 years and despite negligible support from WordPress community WordPress keeps on pushing it. Gutenberg has got to be the most dreaded plugin on WordPress repository with a mere 2 Star rating with 300k active users.
So, why the hell would anyone stop using Elementor / Divi / Beaver / Oxygen builder and switch to Gutenberg.
There are many, many reasons to make the switch. The bottom line is page builders are simply not suited for the 202X decade.
Page builders are built on dying technology
Almost all of the page builders are built on outdated technology and it is just a matter of time when they phase out because new technology can do so much more. It will be really difficult for these Page Builders to upgrade their technology as they have addons and other businesses who rely on their dated framework to support their plugins.
Elementor
Elementor is built on Marionettee and backboneJS. BackboneJS is a dying technology which was at its peak in 2013. I do not see any modern project using backboneJs.
Compared with reactJS on which Gutenberg is built on, backbone never gained momentum. Elementor uses backbone in their page builder creation screen which is good for the time but it has tremendous UX issues and lacks flexibility. The frontend is mostly jQuery based which is another point we’ve added in the list.
Divi Builder
The Divi builder came in 2016 using the React 15 framework. The React made a switch to open source in 2016 and released react 16 which is remarkably different from React 15 framework. Official react doc says react 16 is 3x faster than react 15.
From personal experience, react 16/17 are way simpler to build complex logic and perform better than react 15. Furthermore as Divi will most likely be using NPM modules, these modules update and stop supported outdated features. Moving from react15 to react16 would be like completely rewriting the Divi and based on their developer documentation, all addons need to be changed to suit their updated version.
Beaver Builder
The beaver builder cam in April 2014 and it is built on jQuery. jQuery use DOM (HTML elements) manipulations for animation and it is remarkably slow when compared with other scripts, ( more details below ). The beaver builder uses a lot of outdated libraries which not only increase the size of the site but also are slow and not suitable for touch events. This plugin is also using native javascript at some places (which is a plus point) but the front end is mostly built using jquery.
Excessive dom size
For as little as a block divided into 2, native HTML is one div and two child div with 1 line CSS. The disadvantage is that the DOM/page size increases a lot and browser takes more time to render and eventually the site UX is slow.
A simple layout : Div > Div + Div , 2 lines only
Elementor
For it takes as much as 5 divisions.
Section -> Container -> row -> column wrap -> column
Divi
It takes 5 divisions to achieve this.
Section -> Row container -> Row -> column container – Column
Beaver
It takes as much as 7 divisions and it is not using display flex for layouts.
Content Wrap – Row Content – Column Group – column – column content – module – module content
There is a trend here to use container, wrapper, column. This was popular structure back in the days when Twitter’s Bootstrap 3 which is around same time these plugins initiated.
Over dependence on jQuery
jQuery was a library created by legendary “John Resig” back 2006 for personal use. It became extremely popular as it provided a uniform way to access DOM elements on pages for animations and other effects. Fast forward in 202X, jQuery is pretty useless, all browsers now have a uniform way to access DOM elements, run complex javascript via web components and more. Most modern javascript libraries use Shadow DOM which is fast and browsers have less trouble rendering them. [ ? ]
Further more, the touch screen mobiles came after jQuery, so jQuery was hacked into adding touch support as it was not natively built. So you will find many jQuery scripts not supporting touch events.
Another thing is a huge majority of jQuery scripts read “Document Read event” which means they are not suitable for deferred and asynchronous loading, these scripts have to be loaded along with the page HTML in a specific sequence. This creates a big issue as browsers can not load them at a later stage, hence the overall appearance of the website is slow. Now you may plan in future to migrate site to HTML and then host on JamStack but you can not use such generated HTML which depends on jQuery and DOM events for triggers.
Another disadvantage of jQuery is that elements are rendered from the serverside there is no virtual dom and this also adds to unnecessary HTML on page which remains hidden for the user.
Not suitable for rest API
All Modern applications are built on REST API but all the page builders are built on WordPress hooks. The scripts are outdated which can not be initialised outside of pages. Except for Visual composer WP Bakery, we have not found any page builder which supports REST API or can be initialised via AJAX. Elementor has declared this as a limitation of their plugin.
Conclusion
With WP 5.8 and FSE around the corner next month. It might be right time you visit Gutenberg again. For many years WordPress developers have remained frustrated with lack of a page builder in WordPress core. We’ll be doing a detailed review on Gutenberg in another post. Thank you.
What about WP Bakery?
I would rate WP Bakery as better than Elementor. Even though it uses outdated technology, it is 1 plugin which I found would even work in the upcoming decade. Elementor needs to realise that they have to upgrade to support rest API’s.
Ok sure, all valid points.. but it’s almost 2023 now and the reason why people keep using other page builders, ACF, etc is because Gutenberg sucks. bad. Maybe it’s faster because it’s all built in WP, but it is not a true drag and drop WYSIWYG page builder and will require a developer if you want any new functionality, new blocks, new templates, etc. Not only that but the UI and UX managing it is.. well.. awful. WordPress should stick to being a CMS and not trying to be a page builder. Leave the page building to companies where that functionality is its core business.
Yes, I can not deny anything in your argument that is actually true in so many ways. The fact that WordPress took the risk of developing their entire framework on DraftJS by Facebook was a mistake. DraftJS was later “abandoned” by Facebook due to bugs and issues. They (fb) started a new project now called “LexicalJS” which is a much more refined version of the editor but WP is now stuck with DraftJS.