Yup I needed to make my own gif repo site just keep track of em all.
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.
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.
This weekend I opted out of running this site on Octopress, the blogging framework I started using last year when I built it. I switched to Jekyll. Jekyll and Octopress are quite similar, heck, Octopress is a fork of Jekyll with features added in to make blogging easier. The reason I did this was because I found myself fighting against Octopress too much and Jekyll is a more barebones framework that I can modify to my liking.
Migrating posts and pages over was as easy as copy/paste, hooray for that! The only real trick was setting up URL structure and SCSS the way I wanted. That took a few hours, but I’m happy enough with the quick results. So much so that I deployed the new Jekyll generated site a few hours after I began migration.
So where did Octopress go wrong for me? The biggest thing was theming. Anytime I modified my theme in the slightest I had to rebuild the source from the theme files. I found that half the time I spent working on the site was just recompiling the source. Jekyll doesn’t have “theming” as such so there was no feeling like I had to separate my theme from my source files. It’s all just part of one site, my site.
Combining my love of of SNES and Apple here are a couple of iPhone 6 wallpapers that I made and currently use. They’re sized to fit and take advantage of Perspective Zoom. Enjoy!