In this “guest post” (aka rant I copied out of Slack) Ansel Santosa, Senior Engineer at Pioneer Square Labs, explains some issues integrating Webflow (a web-based website editor) into a web application.
For highly customizable static websites, Webflow has become our first choice at Pioneer Square Labs (A Seattle-based startup studio). Obviously, a well-designed homepage is an important early deliverable for our spinouts. Marketing Manager Peter Denton says, “I look at Webflow as a Website editing tool that feels better than anything I’ve ever used. I can actually build on our designers V1 and integrate my marketing stack.”
However, the next most important customer-facing software that we ship is a web app. Integrating Webflow into that app is where things start to get dicey.
I hate working with Webflow and I suspect I’m not alone among engineers. In particular, it’s painful to use it as the public-facing companion to a SaaS app. Most of our spinouts use Webflow for the main website (marketing site) and our boilerplate stack for their web app. Both of these silos link back and forth and often completely intertwine (specific pages get pulled into the app depending on how interactive they are). This is the use case that Webflow is worst at.
- It requires that our marketing site redirect certain URLs to our app and vice versa.
- NOTHING can be shared between the two silos. Want to use your site’s Webflow header on a page you did from scratch? You have to reimplement and keep it in sync manually.
- The marketing site doesn’t have access to data from the app. There’s no way to include a session-aware login menu in your global nav, for example.
- Did your designer tweak some of the colors? Be prepared to re-tweak those colors in a lot of places
These aren’t hard problems to solve, and the problems affect the designer’s side of Webflow too. They just fundamentally don’t encourage people to design their sites with reusability in mind. It took Webflow 4 years to implement a global color palette and even now it’s kind of an after-thought buried under a menu and a checkbox.
Here are the big things that Webflow needs to change IMO:
Add an application-aware load balancer
Configure your domain on Webflow, tell it what routes you want Webflow to handle and what your app handles, route accordingly. (or create a set of server middleware libraries that do the reverse)
Support a stylebook
Webflow should actively encourage designers to set up and use a global stylebook complete with fonts, colors, spacing, and everything else contained in the beautiful brand PDFs that our designers create.
Join the CD pipeline
Export Webflow-generated content as buildable artifacts. Stylebook variables as Sass/Less, CMS content as JSON, etc. Allow engineers to deploy custom code to their Webflow sites via automated pipelines so that custom integrations can be properly managed, version controlled, and deployed.
I recognize that designers and biz folks love Webflow (mostly because it means they don’t have to deal with engineers). But for companies whose product is web-based software, I don’t think it solves the right problem. Instead of being the single pane of glass through which the full team can interact with the product, it drives an even bigger wedge between the engineering team and everyone else and puts the responsibility of working around the problems created by that gap on the very engineers who were isolated.