I recently moved my portfolio site from a static site generator to Webflow. I know what you're thinking, isn't that for designers who can't code?
Sure Webflow bills itself as a no-code tool, but I've found it to be so handy that I've started using it for client work instead of WordPress.
Why, you ask? Because frankly, when it comes to freelance side work, I just don't have the capacity to build bespoke WordPress themes and deal with all the headaches that entails. I'm more of a markup nerd and prefer to spend most of my time pouring over my HTML & CSS than trying to wrangle PHP & MySQL.
Since I've been working with it a lot lately, I wanted to share what I've found as a designer who can code. There are pros & cons of using Webflow for production sites.
Pros
Publishing
Dammit Jim, I'm a designer, not a dev-ops. I hate moving WordPress sites to production, and I'll never be comfortable with dealing with server stuff. It's just not my bag.
Which is why I love how publishing works in Webflow. If I've done a major refactor to a page design, I don't have to deal with FTPs (or that one time I had to use git to push changes live, gah!). If I'm using an SSG, I don't have to remember how it works; I keep switching between Jekyll, Hugo, and 11ty, so it's like starting over every time. I don't have to copy my newly compiled site folder onto my FTP.
In Webflow, I just hit publish, pick the domain, done. I can ship so. much. faster. Which means I'll bother to sit down and publish regularly.
SEO
Page settings have all the SEO fields built in, making it easy to customize & preview. I'll take this UI over Yoast any day of the week, especially since I hate loading WordPress up with a bunch of 3rd party plugins.
Easy Password Protection
I'd been using a static site generator for my portfolio for years, but recently came up against the need to password protect parts of my site. But since I hadn't built it on WordPress (which I use all the time in my day job, but almost never for personal projects), I was kind of stuck unless I wanted to restructure and password protect a subdomain. Also, that brings me back to my loathing of all things cPanel. Webflow is like a merging of a CMS and an SSG in a way often that suits my needs.
Cons
Knowing how to code
Certain things annoy me in Webflow, and a lot relates to how I prefer to structure my CSS. I have to write custom code for things like selections and focus outlines (yes, I like to customize them, and yes, I make sure they're still accessible). I often need pseudo elements for link interactions.
And then there's the cascade. Say I want to target a <li> that's a child of a parent ul.classname. My only options are to either target something like all <li> elements or give each one a class name of its own. So instead of writing .classname li {}, I'm stuck with .classname__child {}, which now has to be added to each <li> in the markup.
To avoid this, I write my own styles and chuck them in the head in the project settings. It's not ideal, and now I'm writing an awful lot of code in this "no-code" tool.
Weirdly though, I can target individual elements in a rich text element. So I can select all h2's within a rich text element with a class name. This could get rolled out to other elements, no?
Look, I just don't want every element on the page to need a class. It's just not very clean, in my opinion.
No Static Page Templates
Maybe I've just been designing for WordPress for too long, but I'd prefer static pages have a page template option. You can create a template for CMS pages, but the only way to get consistency for top-level static pages is to duplicate one with the layout you need, then update the content.
I've recently found a way around this by adding a password protected style guide folder that houses page templates in a pattern library with the brand guide. I try to practice this in my WordPress sites anyway using multisite, so it made sense to bring it into my approach to Webflow builds as well. Now my clients can just duplicate the template they need when creating a new static page.
It's still extra work, and I'd rather have a saved static page template option.
Combo Classes
Again, this could be my WordPress bias showing, but let's talk about this use case that trips me up all the damn time in Webflow: background images.
Let's say I want a module to have a background image. It's not a collection item, so it's not a dynamic image. It's a static page with a module pattern that gets used in a lot of places. I only want one .module class. I do not want to maintain a stylesheet with .module .module—variantname1, .module .module—variantname2, .module .module—variant3... you get the idea.
WordPress handles this by inlining the style. It'd be great if I could make it a symbol and then override the background. But symbol overrides don't allow that as an option.
Also, considering pseudo elements, I can't be the only one who uses nth-child regularly enough to bridle at the idea of using a combo class in its place.
The CMS
Ok, on the one hand, this is a blank slate to do with as you wish. On the other hand, it's missing basic missing functionality for the collections that I feel should be standard things I can call in a database. In WordPress, linking next & back between post types is baked in. In Webflow, I have to jump through hoops setting up manual links in custom fields. Meh.
Accessibility Concerns
Webflow has a bunch of prebuilt components. This seems cool at first; but once you start to inspect them, you realize they aren't all accessible. Which blows my mind really, in this day and ages.
Their buttons are just styled links, not <button> elements, so elements that trigger interactions aren't semantic. The carousel doesn't support keyboard navigation. It's nigh impossible to get a skip link to work, again making life hard for keyboard users. I had to wrangle the hell outta that to get it to work here, and I don't like the way the code ends up having to be structured. I always end up with unnecessary divs.
Again, this isn't a difficult thing to implement, normally. And since Webflow is meant to cater to designers, not developers, these components ought to have accessibility best practices baked in. I don't expect their target market is going to get too deep into the weeds on this, nor should they need to.
Honestly, I enjoy using Webflow, but this part bothers me the most. Accessible components should be priority number one, not a nice to have in the product's wishlist.
Update: Since I originally wrote this, Webflow's actually refactored a lot of their components to make them accessible! I haven't run any tests yet, but it seems that the pre-made components are built for accessibility now. I am really glad to see that they're committing to updating their product with accessibility in mind.
The bottom line
It seems like there's a lot that I don't like about Webflow, why on earth did I just move my site onto it?
Simply put, it works for me, right now.
It's easy, I can change things quickly, and I'm kinda over the need to lovingly craft bespoke code for every little thing. That's for my day job, not my free time.
I still write a lot of code in Webflow, don't get me wrong. But it's a helluva lot faster than setting up a local WordPress environment, linking it to a git repo, and then coding everything from scratch. Or worse, unraveling a bunch of boilerplate theme code.
I've figured out how to work around the glaring accessibility omissions and don't rely on the pre-made components if I can at all avoid it. Because again, I understand how to code those things accessibly. I would not recommend the platform to anyone who doesn't, since you run the risk of shipping an inaccessible site.
I still do like Webflow, and I'll keep using it for sites with an impossible schedule and a tiny budget. Most of my freelance work doesn't need a full-on database and CMS; they're 2-4 page, small business brochure sites. They don't want Squarespace but don't need WordPress. Webflow fills that niche perfectly.
Webflow definitely has the potential to be something amazing. And I'm betting on improvements being made along the way. Until then, I'm still writing code.