Lately some customers asked us to mantain Visual Composer in their WordPress projects and everytime we had to count the shortcomings of this solution.
That’s why I’ll try to list them and describe why we prefer Advanced Custom Fields.
Pricing
Pricing is the first boundary in many people’s projects. In this comparison I’ll try to reproduce stacks with similar capabilities both with Visual Composer and Advanced Custom Fields.
Visual Composer
- Regular licence (one site) price is $34
- A plugin to make tabs content (I’ve found this) for $13
- A plugin to easy copy and paste rows (I’ve found this) for $11
Total: $58
Advanced Custom Fields
- Personal licence (one site) price is $25
- A plugin to have reusable content as components (we use this). This plugin is an extra tool, but it makes developers’ life and site maintainability easier. The price is $14
Total: $39
Visual Composer, with this toolset, costs almost 40% more.
Memory
The first thing that strikes a developer who would try Visual Composer for the first time is the dedicated memory to PHP. If you use Visual Composer without other plugins, it needs at least 128MB. If you want to add something else, you will have to grow memory usage to 256MB.
To do this, you’ll just have to add this line in your wp-config.php:
1
define('WP_MEMORY_LIMIT', '256M');
You should know that it won’t be just your server to suffer an extra load, but also your browser, and that’s even worse.
As soon as you’ll activate Visual Composer, you’ll immediately notice how your browser will seem laboured. This will be especially evident in your best performing environment: your development machine.
Without considering the backend KB weight, let’s see how much more time an average complex page takes to be downloaded and executed in the browser:
Visual Composer: ~ 3.29x, ~1.71x*
Advanced Custom Fields: ~ 1.29x, ~0.86x*
Plain Wordpress: ~ 1x, ~0.71x*
| * Without browser cache | ** With browser cache
Complexity
Visual Composer is extremely complex (I’ve seen synthetic manuals, written only for publishers, made by 40 pages of cheatsheets).
This is not a bad thing in and of itself, but if you have chosen a WordPress solution, that’s probably because of the simplicity of its interface.
In all my work experiences I never had to explain the Advanced Custom Fields interface for more than half an hour. The first time I met Visual Composer, it took me a full day to decipher it and begin to work on the project.
Visual Composer has too many tools and they’re all available in a single interface, directly available to the publisher. I write “too many” because it doesn’t allow you to select and use just what you need for your purpose.
Backwards compatibility and maintainability
Keep in mind that Visual Composer directly produces the HTML output for your pages. That seems an advantage, but it can be a big deal, when it comes to backward compatibility.
Visual Composer generates DOM elements and outputs CSS and JavaScript code added by designers; this code rely on VC’s classes and structure.
Recently I’ve had to update Visual Composer by a minor version (from 4.7 to 4.11). Result: most of CSS and frontend JavaScript were to be fixed and many plugins of the ecosystem (some of them declared compatible with 4.9 version) were broken.
Why? Latest version of Visual Composer changed the generated DOM structure and its class names, breaking backward compatibility and causing a difficult maintainability.
Advanced Custom Fields‘ interface is safer and maintainable because publisher inserts just data, while we (developers) generate the HTML templates filling them with those data.
Development Environment
We are developers. And so we want to work in a comfortable environment.
Summing the complexity of a Visual Composer project to the number of places where a developer must put his hands with ambiguous promiscuity of skills (something inside the editor, other inside theme, etc …), we can easily obtain the so-called developer lock-in.
This means that only the developer who created the application is able to extricate himself in it, and the skills transfer, perhaps to another development team, is complex as well as very expensive.
Advanced Custom Fields allows us to output ourselves the wished HTML as well as imagine our layout with isolated components and maintainable by their specific CSS (BEM anyone?), their specific PHP interface and their HTML partial.
The problem with Advanced Custom Fields
Advanced Custom Fields has not only positive aspects.
In order to achieve the wished editor workflow semplification, we have a more complicated engineering work under the cover. It will be harder for the developer to have well structured code and custom fields (as well as the custom components) and surgically act on each of them to yield to a specific result.
With Advanced Custom Fields (almost) nothing is out-of-the-box, but the user (either in frontend and backend) will not load with a useless burden.
In brief
- Visual Composer costs 50% more
- Visual Composer needs double memory for PHP
- Visual Composer is two times slower, for browsers
- Visual Composer has too many features directly available, all together, to backend user
- Even among minor version backward compatibility is not guaranteed
- With Visual Composer development environment is promiscuous and out of control as well as not modular
- Advanced Custom Fields requires greater engineering and (almost) nothing is out-of-the-box