As much as we love WordPress over here at Tilted Chair, there might come a day when WordPress’ dominance on the web wanes. (And for his part, WordPress creator Matt Mullenweg isn’t exactly instilling confidence in the platform by exploring astounding new frontiers of petulance virtually every week. That, of course, is neither here nor there…)

As such, we spend a good amount of time exploring modern and emerging alternative website platforms. We’re on the cutting edge over here at TC. We’re hip, as the kids say.

One platform that keeps popping up over and over is Webflow. And we’re not going to lie: it’s dazzling. (Just look at that homepage.)

Webflow just feels like a big idea: it’s basically what would happen if a more refined and controlled WordPress made a baby with a SaaS product. Look at those animations. Look at those beautiful hover behaviors. Look at those transitions. Wow.

Nothing is perfect, though, and that’s kind of the point of this article.

Webflow, despite its amazing current state, does have some issues. And we wouldn’t be so brash as to assume that the Webflow product team might read this, but in the event that someone who is considering the platform does, we hope that this evaluation provides some good insights into what some of the limitations of the platform might be.

So, without further ado: here are 10 things I hate about Webflow.

#1: No “deep” class stacking

This is the most complicated of our list of grievances, so please, bear with us.

Finsweet’s Client-First has published comprehensive documentation about Webflow development best-practices, and in it, they cover the concept of class stacking. (Don’t worry if you’re unfamiliar with Finsweet…we’ll get back to them later.) Class stacking is the practice of “stacking” CSS classes on top of HTML elements. Some amount of class stacking is required in Webflow to avoid having unbearably complex individual classes, and lots of them. Client-First covers the necessity for and proper use of class stacks (or as Finsweet calls them, “combo classes”) in the aforementioned article about combo classes:

We define the “base class” as the first class in our list of stacked combo classes in a combo class. We add a class on top of the base class to create a unique variation.

The added class that gives the unique variation uses the class prefix of is-.

The stacked combo class will only work when combined with the base class(es) before it. In the video below, understand that is-brand does not work alone. It only works as an addition to the base button class.

However, here’s the hangup: the order in which classes are stacked on an element matters, and it’s the very reason that deep class stacking isn’t possible/useful in Webflow.

If, for instance, you tried to go the deep stacking route—something we do in WordPress all the time—and stacked seven classes, one after another on an HTML element, it’s not possible to go delete the fourth element without deleting the three elements that come after it in the CSS class list.

If this is getting a little abstract and complicated, let’s switch to a real-world example.

Here’s a stack of classes pulled directly from the article HTML element containing the very text you’re reading right now:

This is deep class stacking at its finest.

Each of the listed classes does one thing: the grid-50 class is a global class that gives that element a width of 50% on desktop, the tablet-grid-50 class does the same thing but on the tablet viewport, the mobile-grid-100 says that at 767px and smaller, assume 100% of the viewport width, article-body is a custom class that allows us target that element specifically, and padding-top-0 is one last global class that kills the padding at the top of that element.

Furthermore, all of these classes can be removed or re-ordered with no complications whatsoever.

This is not possible in Webflow.

Here is the same set up of classes, but in Webflow:

This same approach in Webflow effectively creates one giant combo class comprising all six classes listed here. Meaning, whatever styling changes I make to this arrangement of CSS classes applies only when all six of these classes are present together, and in this order. Furthermore, you can’t eliminate a class in the middle without first eliminating the classes that come after it.

Meaning, if I wanted to go in and change the mobile-grid-100 glass to mobile-grid-50, I would have to delete padding-top-0 and article-body to get to the mobile-grid-100 class to delete it and then add the mobile-grid-50 class as a replacement.

This is not a challenge that exists when writing raw CSS (like we do in WordPress).

#2: No repeater fields in CMS libraries

When building in WordPress, we use repeater fields—or as they’re called in Carbon Fields, complex fields—literally all the time. Here’s an example of that feature in use on our own website:

The complex field allows us to render an undefined number of elements.

You see that little “+” tab next to the “3”? That means we can continue to add as many more tabs as we like without informing the website of just how many there will be. Carbon Fields doesn’t care, it will simply render as many as are activated and populated.

There is no such feature in Webflow’s CMS libraries:

It’s something that’s been asked for repeatedly by Webflow users for nearly a decade now, and yet, still has not been added yet.

#3: Can’t really use complex :nth-child pseudo-class

nth-child is a super useful CSS pseudo-class that allows us to add styling to repeated elements of a more complex HTML component. To avoid elongating the article any more than absolutely necessary, we’ll allow Mozilla to explain.

How and when are nth-child pseudo-classes used?

Here’s a great example of a simple nth-child pseudo-class being used on the WordPress website we built for Cerca at the Domain.

As it turns out, Webflow has added support for the most simple uses of nth-child pseudo-class—first, last, even, odd—which is great.

However, more complex nth-child formulas are not possible in the Webflow Designer menu.

Let’s say, for instance, that you wanted every third p element to have a light gray background color based on its position in the sequence relative to the other p elements in the component. Using the nth-child pseudo-class, you could implement something like this:

p:nth-child(3n+3) { background-color: var(--light-gray); }

The formula dictates that every third p element gets specific styling:

3*0=0, 0+3=3

3*1=3, 3+3=6

3*2=6, 6+3=9

etc.

This can be an incredibly useful and powerful instantiation of the nth-child pseudo-class.

In Webflow, to define something this complex, you would have to add custom code to the head of either the page or the global site, which means you wouldn’t be able to define nor see the styling when building. Which kind of defeats the purpose of the Designer to begin with.

Small gripe, but something we would love Webflow to do something about.

#4: Can’t have two people in “Designer” mode at one time

Pretty self-explanatory, and seems rather easy to solve: just lock/make inaccessible any pages, CMS libraries, or template files that are currently being accessed by any other user logged in via Designer. (We’re not product people, so if this isn’t as simple as we’re making it seem, please forgive us.)

#5: CMS library limits

The most basic, entry-level, paid Webflow plan doesn’t even include CMS libraries, so the limit is irrelevant there. However, the next step up—the CMS level—does include CMS library functionality, but limits your CMS entries to 2,000.

This may seem like a lot, but we could see some SEO-intensive websites exhausting that limit pretty quickly.

In addition, having a cap on the sheer number of CMS libraries you can employ can be tough if you get handsy with the incredibly useful reference and multi-reference features of the Webflow CMS libraries.

At the end of the day, Webflow has limits.

#6: You don’t really own your website

One of the things we love about WordPress is that you own your website in a way that you simply don’t for sites built on other platforms—and that includes Webflow.

Think about it: with a WordPress website, you could theoretically set up a server in your closet and host your website only for the cost of the electricity it takes to run the server. (If you have solar panels, you could theoretically host your website for free.)

Obviously, that’s not possible in Webflow. (Nor is it possible in Squarespace, Wix, Framer, Hubspot, or any other of the newer website building platforms.)

Webflow deserves a nod here for at least offering the ability to download your site. You absolutely can do that, but what gets exported is a bunch of static files. You effectively have the plain markup of your website, but unconnected to a CMS database.

But—and this leads directly into the following sub-complaint—that means you have to be on Webflow to actually use Webflow.

#6b: It’s more of a SaaS than a CMS

That’s really what it comes down to: Webflow is more of a SaaS than a true CMS (Content Management System).

Another way to put it: WordPress’ open source nature makes it more like Android, while Webflow’s locked-down platform makes it more like iOS.

7. Support suuuucks

For lower-end tiers, there is no phone or web-based support.

That’s right. If you run into trouble with your Webflow website, your only course of action is to reach out to Webflow via email and await their response (which is not always timely).

Take this from someone who’s run into problems on a Webflow website during a highly stressful launch: email-based support isn’t really support, it’s a company pen pal.

#8: Hideous (i.e. SEO-unfriendly) image filenames

Google reads filenames. Don’t take my word for it—take Google’s.

Uploading images to Webflow publishes those images in a CDN. This, in turn, butchers the exported filename by prepending it with a bunch of randomized characters.

For example, Here’s the HTML of one of the images from this very article as rendered by WordPress:

Nice and clean: “https://tiltedchair.co/wp-content/uploads/2025/04/wordpress-class-stacking.webp”. Now, that image represents one more instance of the phrase “wordpress class stacking” contained within the web page’s contents, and that word combination is relatively close to the root domain that we are ultimately trying to optimize for.

Here’s that same image uploaded to a Webflow project:

A folder name made of a bunch of nasty, randomized characters plus a whole bunch more before the original filename. Google has to sift through all of that data before it gets to the filename itself.

Small but valid complaint.

#9: Expense

Very simply, it can get expensive fast, especially when you start adding collaborators, large volumes of content, and additional sites.

#10: A lot of what makes Webflow great is furnished by companies other than Webflow

And that’s not really a dig at Webflow. If anything, it speaks to the masterful job Webflow has done setting the table—it’s just that Webflow doesn’t cook and serve the meal.

Which brings us to the next section of the article…

Enough negativity. Onto some of the good stuff:

#1: It is SO clean

I mean, just look at that interface:

It wouldn’t be hyperbole to say that Webflow has basically mastered the creation of visual controls of HTML/CSS elements. The Designer editor is very nearly perfect.

#2: Finsweet

Finsweet is Webflow on steroids, basically. From Components to Attributes to its Client-First CSS framework, Finsweet has created Webflow-extending features and functions that are basically indispensable at this point. There isn’t a single Webflow project we’ve worked on where we haven’t used Finsweet for one thing or another.

#3: Relume

Relume is another performance-enhancing drug for Webflow projects that has also quickly made its offerings invaluable. From sitemaps to wireframes to the Relume components library, Relume is a Webflow companion we just couldn’t do without.

The Webflow present is bright. The future is even brighter.

Like any good product, Webflow is always getting better. Which leads this author to believe that the current version of Webflow is probably the weakest one, and it’s still amazing.

I’ll look forward to revisiting this article in a couple of years to see where the platform ended up.

My guess is, it’ll be somewhere really great.