Hubspot vs. Front End Dev

Jan 28, 2015

Over the past few weeks I’ve been getting up close and personal with Hubspot.

Hubspot sells itself as sort of an all encompassing marketing CMS/platform for building out “brochureware” sites, landing pages, blogs, email marketing and (shudder) social integration. Truthfully, it does do all those things, probably quite well from a certain perspective and from a purely marketing point of view, Hubspot is and ideal solution to a lot of problems that a marketer would want to solve. It claims easy to update pages, A/B test, analytics out the wazoo, “tracking” of “leads” (something I know very little about) and I’m sure all sorts of wonderful other bells and whistles.

I am, decidedly, not a full blood marketer. I like to think that I have a breadth of skills, I have lots of interests in the gamut of tech and design, marketing knowledge being one of them. I’m not great at it, but there is an interest. However, I do have a larger skill set in web design, user experience, and front end development so my view does skew that way. So it is with that lens that looking at Hubspot as a service I can say that it seems hostel in it’s approach to those who’s job it is to actually design and build the web.

Update: I should note that this is not to say you can’t develop in Hubspot. It is a platform and service, like any other it has it’s idiosyncrasies. The hope with this post is to underline the constraints of the platform from a front end developer’s point of view. If you have to build a site in Hubspot I recommend reading this article: A Guide to Building Customized Templates on the HubSpot COS It helped out far more than most of the actual Hubspot documentation.

No Git Support

If you want a developer friendly system today this is a must. I have come to rely on git in my work. The combination of easy to learn, well established, and excellent for team use make git a no brainer for most team development environments. Hubspot doesn’t allow git, or source control at all, this is a red flag.

Poor File System

Instead of git Hubspot uses COS uploader, a poorly documented CLI that watches a folder for file changes an uploads it to Hubspot’s file system. This is not a sync service. Mistakenly uploading a file requires using the time consuming Web UI to find the file and remove it. As an added bonus, the structure bears no resemblance to the location files on their system.

Lousy Framework

Even when done well frameworks can be problematic for developers. For all the wonder that is Bootstrap, as soon as a project is ready to move beyond bootstrap there is a system in place that now requires it. Anytime a framework is forced upon you by the nature of the templating system, it’s time to take a step back and evaluate what you are to committing to.

Structurally AWFUL templating

Making a system easy for “non tech” users is a challenge. Hubspot seems to go with the idea that it’s templating makes the service more accessible to these users. And while it might succeed, the result of this is a poorly structured DOM littered with nested <span>s (of all things). These spans are what Hubspot uses for it’s own styling and grid system. As an added bonus it also invalidates otherwise compliant HTML!

Everything is a work around

All of the above took me a week of work to discover in their system. The fact is; Hubspot wants customers to use their basic web tools and pay them to build out sites. There are so many obstacles to working in Hubspot as a developer it would seem the they don’t want customers who can code/design or build at all. The message is clear, Hubspot is not for you.

For people who build websites control is everything. This can encompass languages, frameworks, libraries, version control, page performance, styling, user experience and more. These decisions all work to determine your process for getting a site from crude ideas to something live and in the wild. Any system or service that blocks choice in these matters is adversarial to building a better web.