The HubSpot Visual Builder vs. Coded Templates

When it comes to building a page template in HubSpot, there are two options: you can either build it using HubSpot’s easy-to-use Visual Builder or hand-code the template. Both options have pros and cons that should be considered before building a new template.

Visual Builder

Starting with HubSpot’s Visual Builder, this is one of the HubSpot CMS’s key features. It allows dead simple drag-and-drop editing of layouts without needing to know much if any code.

For many, this is what building a template in HubSpot is. For what it’s worth, the Visual Builder is the ‘HubSpot way,' so to speak; this is neither a pro nor a con, just something to consider.

Pros

First and foremost, the Visual Builder is easy for developers and non-developers alike. Using a simple drag-and-drop interface, you can pick and choose content types and place the content where you want them within the template, while also adhering to a 12-column web grid—no web development experience needed. If you are a developer who will be handing-off these templates, remember how empowering this can be for your clients.

This drag-and-drop feature, along with fields for adding classes, ids and inline styles, makes it simple and fast for basic template changes to be made. Sidebar too big? Drag the divider to expand the main content area, click Publish and it’s fixed with almost 0 effort.

This brings me to the next pro of the Visual Builder: it allows you to quickly see the rough structure of your page. Sure, some of your CSS may alter the end result, but you also get a nice approximation of how everything fits into your grid—visually—while editing. You can easily get a feel for the proportions of all your containers.

Cons

It’s not all sunshine and rainbows in the land of the Visual Builder, though. The tool’s power comes at a cost. That said, if you’re not a developer, you might not even care—let alone notice. However, if you are, these can cause some headaches and late nights.

The issue you’re most likely to run into is that the template builder creates a TON of unnecessary markup. This can bloat your page weight (sometimes enough to slow load times). It can also mess up your CSS. Want to use Flexbox or CSS Grid? You’re going to have to get creative with your selectors, since flex-children/grid-items must be direct children of the flex container/grid container (for now).

Speaking of layout, the Visual Builder locks you into HubSpot’s grid framework, which, in the 5 years since it was implemented, has failed to keep up with modern web development. You must use a rigidly defined 12-column grid with fixed and unchangeable gutters. What’s more is there’s only one breakpoint (at 768px); above that width you get columns and below that width, everything becomes a simple tube of content. This may or may not work for your design.

This limits the type of layouts you can do within HubSpot. If you have a complex layout, not only are you fighting against the web, but now you’re also fighting against the tools you’re using to build it.

Coded Templates

Thinking ahead, HubSpot didn’t just limit you to their Visual Builder; they had the foresight to know that developers might need/want more or even just prefer an editing experience more like what they’re used to. Enter Coded Templates. These open up as a standard text editor to let you code your heart out. Also, there is essentially no hand-holding with a Coded Template.

Pros

The most obvious pro is that this provides a familiar experience. Anyone who’s written some HTML should feel right at home in the Code Editor. Additionally, you can use whatever build tools you like (as long as you can add a ftp step to the build) if that’s your cup of tea, but that's a blog for next time.

With Coded Templates, you gain access to the raw markup, which means much more control over how everything works. When you use some of HubSpot’s functions, they will potentially add a small amount of extra markup. That said, the way you author it largely determines how it ships.

With that power, you can roll whatever grid framework/tool/pattern you want—including HubSpot’s own, if that’s what you’re into. This gives you all the flexibility you’ll need to build as you normally would, without the tools becoming an additional hurdle.

Additionally, there are pieces of the markup that the Visual builder doesn’t expose that you’ll now have access to. For example, the entirety of the head element.

Say you wanted to have “ | Company Name” at the end of all your page titles. Traditionally, with HubSpot, you would need to manually write that at the end of the page title within the page editor of every single page of your site. However, with a Coded Template, you can use the now exposed `title` tag output to append that to all the titles at the template level.

Cons

Coded Templates aren’t perfect either. The Visual Builder automates a lot of things that are now your responsibility with Coded Templates.

For one, in the above example about the `head,` that markup is part of the boilerplate code that you’re going to need to have and maintain on every template—just like most other CMS. Thankfully, HubSpot does provide a basic scaffolding of this markup every time you make a new Coded Template, in order to make this a little easier to deal with.

The elephant in the room is that not just knowing, but also being proficient in HTML, is now an absolute must. Not to mention HubSpot’s own templating language, HubL. Without those, you’ve got nothing. This requires developers to make any changes to the template. It's worth noting that, depending on how the code is built, the developer could add a myriad of options and customizations into the template to be controlled within the page editor—while still maintaining reigns on just how much can be changed.

¿Porque No Los Dos?

Before you start trying to decide which is best for you, there is one more option—a hybrid of sorts. You can use the Visual Builder to architect the overall page using a series of Custom Modules to compose the details. Custom modules are self-contained coded template chunks.

When building a Custom Module, you have access to a powerful set of field types to enable easy editing of the page within the page editor, while exercising more exact control over the markup. You would build small, composable modules this way, then drop them into a Visual Builder template.

This will largely give you the best of both worlds. Where it counts (the intricate pieces), you’ll have full control over the markup, while delegating the more boilerplate markup back to the Visual Builder to deal with. Sure, this will potentially result in more unnecessary markup than you’d like, but it's still considerably less than fully relying on the Visual Builder for the whole layout.

Time to Choose

I’d love to give you a definitive answer, but really, it just depends. Which one you go with is going to largely depend on personal preference, as well as the project needs/goals. Working with HubSpot every day, we’ve found that the combination method seems to work the best in most cases. That said, we’d love to hear how you tackle building templates in HubSpot down in the comments below.