[9dev]

You're absolutely underestimating the complexity of proper live preview of changes. This is essentially "hot reload" mode, but on the public internet, because it has to run on a public domain. Getting that right is a challenge, and if you don't know why, you haven't attempted to solve it yet.

[Lammy]

Why would I want my WIP site to be on the public internet? This has been built into Jekyll for years. Probably other SSGs too but I don't know/use them.

  jekyll serve --watch --incremental

[9dev]

Because you're thinking in the context of a solo developer working on their site locally. You don't need a CMS. People that want to collaboratively work on a website, some of which may lack technical skills, need a way of previewing their edits that doesn't involve running shell commands.

[Lammy]

You're conflating the two unnecessarily. There's no reason Jekyll's server has to run on the editor's local machine. See my other comment about jekyll-admin which can be used collaboratively: https://news.ycombinator.com/item?id=47737324

I don't see much of a difference between `jekyll serve` and the e.g. `service nginx start && service php-fpm start && service mariadb start` that would be needed to run WordPress. In fact I don't run my WIP Jekyll site on the same machine that I edit from. Mine is available only on my personal mesh VPN, but it could easily be available publicly if I wanted it to be.

[wltr]

I would appreciate getting into more details. As it sounds like a made-up problem to me. Perhaps you don’t understand how simple it is to have a static website as compared to a dynamic one. Especially to some simple project.

[9dev]

You can always reduce complexity by moving the goal posts. In context of the original proposition—that one of the core values WordPress provides is live preview—we have to assume a reasonably complex website authored by multiple people.

Live Preview means, then, that you need to:

  - have a web-based editor behind secure auth,
  - create an environment resembling CI to rebuild the site on demand,
  - trigger rebuilds when a user modifies the content stored on the server,
  - make the new build available in a draft environment
    - …where it doesn't affect the live site,
    - …only grant access to collaborators,
    - …without breaking assets, links in the pages, CORS, or CSP.

There are more constraints and pitfalls that I'm not going to enumerate here. My point is, this stops being simple as soon as you stop being hand wavy about it.

[wltr]

The solution of this problem could be many, depending on the situation. I have my blog and other static sites synced to all my devices, and the server rebuilds them nightly. In most cases it makes no difference whether I’d deploy it right away, or it would be deployed within a day. Testing the website can be done completely offline, all you need is to sync your changes before the night. Triggering the rebuild on the server (which is deploy) can be done via a Shortcut from an iPhone. No way you can make it as easy with a Wordpress website.