Ask HN: How does your web app handle public facing pages?

There are two main schools of thought I've seen on this:

1) Use Wordpress. Have the web app on a subdomain, for example app.example.com and any public facing pages on example.com, and use a CMS like Wordpress serve up any external/public pages (home, about, contact, etc).

Cons:

- You have to use Wordpress. Many front-end devs would prefer to work in a modern framework/library like React/Vue/Angular. (I'll get to the headless CMS in a moment)

- Very hard to use custom designs. If your company has a design library and pre-built corresponding components, then you basically have to have two sets of code.

- VERY difficult to do things like allow a signup/signin modal that is connected to your webapp, rather you have to send users to your signup/signin pages, e.g. app.example.com/register. I also don't know how you handle tracking if you use Segment and the likes.

Pros:

- Easy for non devs to edit content

- Many themes available if you are starting from scratch and can be flexible on design.

2) Use your front-end JS library or just plain old HTML/CSS and build out custom external pages.

Cons:

- Takes more time and effort to build out the pages, since you aren't using a pre-built theme. There are HTML themes you can buy but I've always found them extremely bloated and difficult to wrangle into a front-end framework, and almost always end up tossing them by the wayside.

- Can be difficult for non-devs to edit content. You have to use a headless CMS like Contentful for fetching any content that you may want to change frequently (header text or images for example).

Pros:

- Easy to integrate any custom functionality (tracking, a/b testing, data fetching, etc)

- Much more pleasant development experience. All the code can live in the same repo.

---

I would love to hear some of HN's thoughts on this as well, as I've seen both approaches frequently and would like to know if there's something I'm missing about approach #1 especially.