CMSes and Landing Page Builders Have Failed Us

You're in a Slack chat. Three groups are discussing the website.

Marketing wants to launch a campaign yesterday.

Engineering is concerned about performance and maintainability.

Design is worried about brand consistency and user experience.

Sound familiar?

The Eternal Three-Way Tug of War

The world of landing page builders and CMSes has a big problem: it's a place where three stakeholders constantly butt heads:

  1. Marketing teams need to move fast and iterate quickly. They want intuitive interfaces and the ability to publish without depending on engineering.
  2. Engineering teams care about code quality, performance, and maintainability. They want clean architectures and hate the bloated, unpredictable output of visual builders.
  3. Design teams focus on brand consistency and user experience. They need tools that enforce design systems while allowing for creativity.

There's no CMS or landing page builder I've used that keeps all three happy. And I've used many.

Isn't This a Solved Problem?

You might be thinking: "Haven't we figured this out by now?" After all, there's an entire industry and 30+ years of software development history behind this domain.

The funny thing? We all groan when we see Yet Another CMS?. They're ten a penny. And yet... it's rare to see any CMS trying to tackle the really hard problem - keeping engineering, marketing, and design in harmony.

It's a People Problem

"This is a people problem, not a tooling issue! You need better communication!"

Yes, it's true - every technical problem is a people problem in disguise. But ultimately, we need software that supports rather than hinders collaboration. Even if your teams are perfectly aligned, if your tools fight against that alignment, you're in for a world of hurt.

The Current Landscape: Five Flavors of Frustration

Let's look at how the current market tries (and fails) to solve this:

1. The WordPress Universe

WordPress deserves its own category due to sheer scale. It offers a vast ecosystem of plugins that can help with every aspect of running a CMS. But it often becomes a maintenance nightmare, with security issues, conflicting plugins, and performance problems that make engineers weep. Designers wrestle with janky UI builder plugins and often need engineering help to get any semblance of consistency.

2. The GUI Builders

Unbounce, Wix, Squarespace, Webflow - marketing teams love them because they can launch pages quickly. But they're often slow and bloated and download Megabytes of client side Javascript. They’re a siloed sandbox that’s difficult to customize, an engineering nightmare to extend and ooze janky design inconsistencies. I’ve even seen marketing teams spend hours trying to recreate brand styles in these tools only for the pages to look close but not quite the same.

3. The Static Site Generators

Jekyll, Hugo, Middleman, Astro, 11ty - engineering teams adore them. They're fast, secure, and maintainable. But try getting your marketing team to write Markdown in GitHub. You'll be getting angry Slack messages until the end of time. Design aren’t a fan either - how can they build prototypes fast? These generators are fine for simple blogs but what about interactive pages? What about charts, graphs, interactive tables? What about calculators? Quizzes? Another issue - this area of software is vast and with every new static site generator there’s a new learning curve. I’ve used many, only to hit a brick wall with customisation with every single one of them… except 11ty.

4. The Component-First Approach

Builder.io stands alone here. It focuses on the JavaScript ecosystem and plays nicely with modern frameworks. But it forces engineering to author components in JavaScript (a language designed in 10 days) and leaves both marketing and design teams dealing with its quirks.

5. The Headless Revolution

Sanity, Contentful, and friends brought us API-first content management. Engineers love the clean architecture. But marketers are left without real visual editing tools unless engineering builds (and maintains) them.

The Modular Approach

After wrestling with these problems for years, I've been building something different. Something that actually makes all three groups happy.

  • For Marketing: A GUI landing page builder with live preview
  • For Engineering: A command line landing page builder - Rails for static sites - that leverages the JS ecosystem
  • For Design: Components that enforce brand consistency while enabling creativity
  • For Everyone: Content changes tracked in Git, tech-agnostic back end server environment, and no JavaScript framework headaches

This isn’t building another CMS or landing page builder from scratch.

It’s gluing together existing technologies:

  • Modular: My own command line tool - use convention over configuration - Rails for static sites
  • Netlify or Cloudcannon: Deploy the site to a fast CDN with a visual editor
  • HTMX: Build interactive components using any server side technology
  • WebC: HTML-like component authoring on the client side
  • Tailwind: Modular and encapsulated styles with a huge ecosystem
  • 11ty: Blazing fast, extensible static site generation
  • Flowbite, Preline UI, Tailwind UI: Bring your own component library - some free, some paid.

Want to See More?

I'm building Modular in public, and I'd love to show you how it works.

Book A Free Demo With Me!

Or you can just DM me MODULAR.

Appendix - Comparison Table

How do all these options stack up? See the image below. Last column is Modular.

Comparison of different CMSes, landing page builders and static site generators with how they fix problems for marketing, engineering and design.


John Gallagher

Helping Engineers Understand Apps In Production. kill3pill.com

3 个月
回复

要查看或添加评论,请登录

John Gallagher的更多文章

社区洞察

其他会员也浏览了