Visual composer is a bad choice for web development. Here’s why.
We sometimes have clients ask why we custom develop our sites rather than using a tool such as Visual Composer. After all, as a tool which basically allows users broad customization tools for editing the front end of the website, it seems like a great option. The front end is what users see and understand, so that’s what they prioritize. However, as we’ll see, Visual Composer leaves many users at a disadvantage when it comes to back end development, and it even limits front end development in unexpected ways.
Basically, Visual Composer means that you aren’t really architecting the site’s information—you’re just building on a page-by-page basis. Visual Composer gives you a lot of freedom to build whatever you want, but that freedom is a two-edged sword. In some cases, clients get comfortable with how Visual Composer works, but in other cases the number and variety of options are so broad that, instead of having easy-to-edit content templates, the user just gets overwhelmed and has difficulty editing the content at all.
Specifically, if you have a lot of pages that you want to stay the same, maintaining consistency is an issue because you need to edit each one individually and not inject deviations into the designs.
We have multiple marketing clients whom we’ve taken on after another development company built their site on Visual Composer. The client doesn’t understand how it works well enough to do anything themselves, and typically they can’t do what they want to do anyways because Visual Composer doesn’t support it. So we have to try to inject custom development work into Visual Composer to make what they want happen—which is much more costly and difficult than starting with custom development in the first place.
An analogy I use frequently is that Visual Composer is like having a blank sheet of paper. You can draw whatever you want! How good of an artist are you?
So, why do people use Visual Composer?
Since we don’t use it ourselves, I can only guess here, but my assumption is that it’s easier to use for the “developers” (and to be fair, presents a lower up-front cost to their customers). I use the word “developer” here loosely, because there’s a distinction between those who work only within a theme’s or plugin’s options and settings, but don’t do any coding—GUI work only. Development companies sometimes work with these front-end people instead of having to vet and hire actual developers that know how to code a theme from scratch. These individuals are a more rarified breed, and as a result are also more costly to work with. The pay-off? They actually know what they’re doing.
Personally, I take a lot of pride in the fact that, at build/create, we’ve taken the time to build our team around a core of true developers that know how to code themes and plugins themselves. It means we not only build better sites in the immediate term, but the sites also provide a more stable long-term foundation for future Ann Arbor website development—both because the code base is more solid, but also because we actually have the capability to develop future functions and features in-house.
Ok, so that’s Visual Composer. What are the benefits of Custom Development then?
We do custom theme development because it provides a higher quality, more unique design, better information architecture, and a stable long-term foundation for the site. Here’s how these break down:
Unique Design
If you use a stock theme, you can only change it so much. This is usually limited to colors, some fonts, but not structural changes to the templates or menus themselves. You have to take what you get and work within those constraints. When you’re doing custom theme development, you aren’t starting with a stock theme. That means we can tailor the design to your specific needs as a company.
This can affect everything from simply having a site that doesn’t look exactly like every other site out there, to more important considerations like developing better integrated design elements and features that wouldn’t fit into a one-size-fits-all solution.
Information Architecture
Visual Composer entirely lacks information architecture. Remember the blank paper analogy? You can draw all you want on a bunch of different sheets of paper, but those compositions are a universe unto themselves. They aren’t part of an intelligently architected system that would allow the various content-types and fields to talk to each other.
In practical terms, what does this mean? It means you can’t cross-link one piece of content with another unless you do it manually in every single place where it needs to happen—an unsustainable burden for most businesses. This comes up when we get into things like cross-linking Services with Clients and/or Case Studies, or related blog/news posts by category, etc.
Visual Composer also limits ways in which you can build a sophisticated mapping strategies. For many of our clients, we’ve created control settings that govern what displays in certain context. The most relevant example of this is for blog posts or articles where we reference specific feeds by category, date, popularity, etc…
Further, if we need to update the design of a template that is broadly used throughout the site, having the templates be part of the theme development and information architecture means that an update can be applied universally across all instances of that content object, instead of having to manually make that change on each instance of a piece of content where ever that content appears.
Site Stability and Longevity
Doing custom theme and content-type development also means that we have a more stable foundation for the long term. Visual Composer regularly has updates released for it, and if the developer is (I assume) also using a stock starter theme, that theme will have updates as well (and WordPress will have updates, as will all of the plugins).
Some of that is fine—updates can be a good thing if it brings new functionality! But if everything on your site is subject to ongoing updates, and if all of those pieces are one-size-fits-all solutions, then each of those pieces is going to go a different direction as they all try to serve every possible edge-case without ever specifically addressing your needs. You wind up on a raft, out-to-sea, with all the logs on your raft drifting apart underneath you while you try to hold them together.
Instead, we do custom theme work, then intelligently architect your content using post-types and custom-fields. This means we only need to keep up with the core WordPress updates (generally a positive!) and updates to the key plugins we use. As a result, your site isn’t slowly breaking down over time.
In fact, our sites are so stable, that we’ve had clients come back around for complete redesigns after 4+ years, and instead of starting from scratch, we just redesigned their theme, because their site’s foundation was so solid there was no need to re-do the whole thing. This stability not only saves you money by giving your site longevity so that you don’t need to rebuild as soon, when the time for a redesign comes, it’s also a cheaper redesign because you don’t have to start from scratch!
Stability aids new functionality.
Stability allows us to continue developing new functionality on top of the site. This can be as simple as adding new content types and templates to the site as we build it, or it could involve more complex tools like user-login to restricted content areas with unique dashboards for different user-account types. We’ve built tools that help clients run their businesses, manage their events or conferences, coordinate their team, or integrate 3rd party software or applications via API (for example—more advanced support and chat features).
Remember the distinction I made earlier between “front end” and “back end” developers? If you’re hiring a team that only knows how to do front-end work on Visual Composer, how are they ever going to handle your needs when you want them to write a script that is parsing a feed from your MLS or working with your Chatbot’s API to better integrate those functions with your CRM? These are the kinds of things that you need a long-term partner to accomplish.
But what about flexible content management for individual pages?
A final note on this: we do recognize that for some pages, you really do want some (reasonable) page-builder capabilities. Your “About” or “Our History” pages are a great example. You are telling a story, you want it to be editorial in style, and you want the flexibility to vary the layouts on these pages, because these pages are one-off compositions.
For these sections, we also include page-builder capabilities in our themes with a simple system that we’ve developed ourselves and which is integrated right into WordPress’ core functions and plugins. We’ve stopped short of Visual Composer’s obscene bloat, but we’ve left in place the kind of sensible, light-weight page-builder tools that allow us to easily make beautiful and flexible layouts for you—and if you’re a good artist, you can paint a beautiful picture of your own (or copy one of ours and modify it).
Conclusion:
You may already have is a site that is built using Visual Composer, and if you’re trying to update it, it’s understandable that you’d want to stick with it for the next round of designs. However, if you go this route again, you will likely get a refreshed version of the same thing, with the same limitations, and the same long term problems.
On the other hand, with custom development, you have the opportunity to take your site in a new direction, and get a better result, and work of a quality that will put you in better standing against your competition.
Custom Development definitely costs more upfront than Visual Composer work. In fact, there is such a difference in the work that I really see it as an apples-to-oranges scenario. But beyond the upfront costs, you have to consider both the long-term costs involved with dealing with Visual Composer as the site breaks down, and the opportunity cost of having the project be less successful than it might have been.