Comment by pembrook | Hacker News Reader

Comment by pembrook | Hacker News Reader

Parent Full thread

> Static makes so much sense for sole-author sites with technical owners.

Totally agree for this narrow use case. But you're also correct that if you're a startup with a marketing site--going the Gatsby/Hugo/etc. route is a total disaster. Have seen so many technical founders make this mistake.

What happens is you realize, crap, my team needs to publish content for SEO and build new landing pages...and they aren't able to do my esoteric Git + Hand coding + Markdown/Front Matter + build process steps. So then you get sold some convoluted "HEADLESS CMS," which claims to solve your problems, but is actually a total freaking nightmare to setup and maintain (god forbid you ever want to change anything).

Have witnessed this charade more times than I can count. Seriously, just use Webflow. I know HN is highly disgusted by the idea of something being marketed as a "no-code" tool. But Webflow basically is a static site generator + headless CMS, just with a UI layer for non-technical folks. When you click publish on updates to a Webflow site you're basically automating the recompile and deploy steps.

To offer the other side of this, at $dayjob we just got done getting out of Webflow and into hand-coded HTML. That stack comes with a number of severe headaches.

* The UI layer is complete and total garbage. It is unbelievably slow and clunky and it makes doing anything with it a chore.

* The UI is complicated enough that it would be easier to teach the non-technical folks to use markdown.

* Uncomfortable amounts of lock-in. You can export your entire site of course but retrieving your "CMS" records is not so straightforward.

* If you need to do anything interesting, the UI benefit is gone, because now you get to write code AND use their awful platform.

* Expensive, with a recent price hike with no increase in the functionality or quality.

The recompile and deploy steps can be automated in ways that don't require hitching yourself to this behemoth.

I’ve been running a news site with Hugo for the last four years. You setup a CMS that lets the non-technical people make content changes without you. For design changes, you always are going to need someone who knows how to code, so it’s not a big deal to use Hugo.

Of all the problems we’ve had running a website, Hugo has not been one of them.

99% of ppl pushing headless CMS are ppl who get paid for building *and more importantly, maintaining* headless CMS sites.

Yes, they have their place but it's far morw niche than the hype wants you to believe.

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users. The only problem is the price-tag which means you’ll be outpriced for small personal projects but it’s still a good deal for startups and bigger companies.

I'm surprised you'd say Webflow has the constraints vs. Framer. Framer definitely seems promising but is way too limited and basic at the moment. They don't even have an API, and the CMS just feels super sandboxed. Good luck doing any of the programmatic SEO stuff you can do with Webflow. I'm confident they'll get there in a few years though.

Or you can have a look at React Bricks, too. Devs create content blocks as React components with inline visual editing and sidebar props, with constraints so that the design system cannot be broken. Content editors can use these Lego bricks of content with freedom, without breaking the design.

I’ve been down this path enough times that I built https://sitepress.cc/, which lets you embed content in a rails app with features that are present in Jekyll, Middleman, etc. like Frontmatter, site hierarchy traversal, etc. It keeps content as files in the app/content directory, but when it’s time to pull data in from the Rails app for SEO, it’s all right there in the Rails app. There’s no “Headless CMS” crap to jump through.

For me, this is another way of keeping everything in a monolith, and which requires a lot less context switching. If I’m building a feature and I want to create marketing or support content for it, it’s all right there in the same repo. I just create the markdown files I need, commit them to the repo, and I’m don.

The thought of switching between a static content site or something like Webflow just seems silly for a small team or project.

I agree and made that mistake myself... Framer is another good alternative to consider.

They need Cloud Cannon!

Reply on news.ycombinator.com