September 04, 2017

7 reasons page builders suck

Page builders are every end-users dream and a developers worst nightmare.  In a developer's world, page builders would not exist.  They introduce a lot of problems as well as more rigid HTML structure, but unfortunately as a developer you end up develop products that are ultimately used by clients and this is not an option.

In this article, I wanted to cover some of the issues page builders cause right now, the best ones available, and what could be done to make them better.

This is by no means an attack on any of these page builders or their developers.  Many of them once served a great purpose, but have either run their course, are victim to consumer needs (explained below), or need newer technologies.

1. Performance

This is something I harp on pretty often, but page builders drastically affect site performance.  Take Visual Composer, the most popular page builder available, and add up its bare minimum frontend assets.  With the frontend stylesheet and javascript file combined you're looking at 700kb+ worth of code.  This is the already minified size and does not account for other assets like icon packs,  jQuery, or othervendor scripts.  If that doesn't scare you, it should.

Our homepage at the time of writing totals 1200kb, which means the above assets would have accounted for 58% of our total page weight prior to adding in our own styles, images, or other plugins.  And for another frame of reference, our stylesheet for this site is 23kb in size, while are scripts total nearly 50kb in size.  This comes to a grand total of 9% of what Visual Composer would add to our site.

That's huge!  More than enough to scare our team away from using it whenever possible.  Why do the assets need to be so large?

2. Predefined styles

Bloated assets are an unfortunate side effect of consumer demands.  Consumers, especially WordPress users, want plugins to work right out of the box.  People want feature-rich plugins that don't rely on them installing a specific theme to go along with it.  In short, page builder developers know that tossing in 10 different icon packs, multiple slider and carousel types, modals, team member styles, and everything else under the sun will net them more sales.

This isn't only true of page builders, but also themes and other plugins available on any marketplace.  Consumers don't know what's best for them here and have no way of knowing otherwise- how could they?  

In reality, page builders should focus only on content organization and a framework to allow a theme to determine the true style of a website.  If you've worked with WordPress, Drupal, or any other CMS for a while, you've probably heard that themes should not overlap with plugin territory.  The same is (or should be) true of plugins.  I could go on, but the topic of theme and plugin developers encroaching on each other's responsibilities probably deserves its own article.

So as it stands right now, consumers can't verify code quality and the major selling point of any plugin or theme is the number of features available (read: code bloat).

Solution: Provide a framework for themes to build on and don't include a bunch of widgets and styles- that's not a page builder's responsibility.  Now, I've got to be honest, this is a half-baked solution unless you're developing purely open source for the community.  These developers work for money and they're going to starving if they're selling page builders without widgets.  One option might be to allow provide structured assets that can be enabled or disabled easily (think Boostrap SASS components).

3. Tag soup and conflicts

One of my other major issues with page builders is the amount of tags they feel they need to insert to properly lay out a page.  This makes code messy, unorganized, and more difficult to style.  

But perhaps more important is providing an easier way for other developers to extend the layout structure.  Themes often include their own grid frameworks as does almost every page builder.  Loading 2 entirely separate grid frameworks or loading Bootstrap twice in one page makes absolutely no sense.  Not only are you needlessly doubling up on stylesheets, but you also run the risk of conflicts.

tag soup

Solution: Most page builders roll out their own framework and prefix their columns, but this doesn't really solve the issue.  Instead, allow a theme to describe its own grid structure would give you the best of both worlds.

4. Unreactive or slow

A bunch of page builders are just god awful slow.  This may seem like nitpicking, but come on- it's 2017.  I don't want to wait 5 seconds for a modal box to open with settings and yet another 3 seconds to save and view my changes.

Slow load time

This happens because when you go to edit an element, the page builder is making an AJAX call to get the necessary form data, has to manipulate the DOM to create and append this form and modal, and finally has to make another roundtrip call via AJAX to get the rendering for this element once you've saved.

Solution:  Simple solution here- use a reactive framework.  There are so many great ones available that make this a no-brainer.  I tend to favor React and Vue quite a bit, but this is largely going to come down to preference.  The only reason I can see for not implementing a solution like this is laziness.

5. Not extensible enough

At the end of the day, a page builder should act as a framework.  No one wants to buy a page builder that ends up looking like everyone else's website.  And no one wants to be locked into using a single page builder, plugin, or theme should they decide to move.

Rarely have I ended up using a page builder and said, "Wow, this page builder has exactly all the widgets and options I need to build this clients site.  No more, no less!"  This just isn't realistic and no one can expect this.  However, we should expect that we can easily disable widgets, features, or components in addition to be able to add them in.

While most seem to offer a way to quickly add in widgets, it doesn't feel very well thought-out.  I often find myself wishing I could modify more of their core components.  Other times, the page builder makes use of fields that aren't reusable components and you end up recreating the wheel or forking your own copy just to modify a single line of code.  But this is a terrible long-term strategy.

Solution:  A page builder should provide an easy way to extend any its components.  Using available field types should be as easy as passing in an array of fields and variables.

6.  Vendor lock-in

Many page builders build their layouts and widgets by providing shortcodes or their own syntax to generate layouts and widgets.  This is all fun and games until you disable the page builder or a plugin you were using and get left with a pile of broken shortcodes.

Solution:  At some point, the page builder should provide HTML as output.  Not only for performance but also to prevent vendor lock-in.  This probably suggests a mixture of stored data and HTML as parsing HTML into a page builder could open a lot of room for error.

7.  Developer documentation

I feel like this is a point that shouldn't need to be stated, but so many page builders have documentation sprawled across the internet.  Sometimes bits and pieces are available on the vendor site, sometimes they're available on their Github repo, and sometimes you have to scour a forum to find your answer.

Part of the problem goes back to the issue that page builder developers are being developed for consumers and other developers really are an afterthought.  Marketing is not my forte, but in an ideal world, page builders would be marketed towards developers instead of consumers.  Redux Options (while not a page builder) has a decent group of developers that did this and while I can't speak to how successful they are, they clearly marketed towards developers.  Their documentation is also very developer-centric with helpful examples and articles all organized in one place. 

Solution:  Page builders should be built with developers in mind.  Documentation is an absolute necessity.

Best page builders available

We have no affiliation with these page builders.  And while we list them here, note that none of these are perfect and we recommend you do your own research to see which fits you best.

WordPress

Divi – One of our favorites and very intuitive to use.  It is feature-rich, not too bloated and reactive, but while this is one of the better developed ones out there, there doesn't seem to be any developer documentation.  It's still possible to customize as a developer, but you better have a solid grasp on their directory structure and know what you're looking for.  Also, note that there is no license to include this in end-products so if you plan on selling your product, you can't include Divi with it.

Divi page builder

Elementor – Elementor is very new and also a reactive page builder.  Total asset size is not too bad and editing feels very snappy.  We use this in a lot of client sites now as there is a free version which does just about anything you could ask for.  The downside is that the freemium model seems to be driving them to intentionally cripple pieces of the free version and restrict access to various pieces of the builder.  I was not happy to find a breaking update that was caused by removing a useful hook in the free version.  On top of that, their documentation could use a lot of work and their issues on Github seem to be stagnating a bit with 50+ issues from 2016 alone.  

Elementor page builder

Beaver Builder – A lot of people seem to really like Beaver Builder.  It isn't bloated (big plus) and was one of the first front-end page builders.  The builder is not reactive and feels like it takes ages to make a couple quick edits.  I do like the devs and community there, but it's old now and due for a rewrite.

Beaver page builder

I'm going to say explicitly that I would highly recommend against using Visual Composer.  It is slow, bloated, and not easily extensible.  The developers have netted $7.4 million in sales.  They could take a measly $8000 of that and pay a developer to rewrite the code base and make a viable product for both developers and consumers, but they haven't.

HTML (agnostic)

When it comes to non-WordPress builders, we're kind of SOL.  There are a few packages available, but they're pretty far from perfect.  I'm not going to include page builders that drop in entire sections or headers as these aren't DRY and not realistic in production.

Content ToolsI think Content Tools comes pretty close to being a good editor.  And for basic content like blog posts or long blocks of text, it's not bad.  However, it doesn't have enough basic components and won't work with more flexible layouts.

CKEditor – I have a hard time recommending CKEditor mostly because of its monolithic nature.  But it has a large team backing it and screams stability.  It also has the largest marketplace behind it, meaning adding in features is possible.  Because they also have an API for adding in "widgets," column layouts and other custom components are a possibility.  It's not the most fun to work with, but it's a very realistic option when it comes to client sites.

Moving forward

At Echo 5 we've been working on an agnostic page builder on the side.  When we're not swamped with clients, hopefully we will have some more time to finalize and make it production ready.  

I think we've checked off all of the above issues that most page builders face, but one that remains is how to make it a viable model.  My preference is to open source it and provide a solid tool to the community, but cutting any funding from a project will guarantee it stagnates.  Maybe we'll come up with a freemium model that doesn't cripple the product, but marketing towards developers can be a very different ball game.

What are your thoughts on page builders- did we miss any?  Want to see them all burn to the ground?  Leave your comment below!