A great thread by @elotroalex laying out the case for Wax -- which I'm working with right now and support! But tech platform choices come down to trying to make the best decision balancing conflicting needs & priorities. Here's why I haven't used it much before now: https://twitter.com/elotroalex/status/1341391317851627520

I have an intense aversion to magic and wizards in DH. I feel strongly about people who actively run projects having full ownership of them. I want the people in charge of projects I'm involved in to be able to freely make content & even (*gulp* if needed) structural changes.

So personally, I'm not down for @elotroalex workflow of "send me spreadsheets and Word files and I'll make you a site". Because then they'll usually keep coming back to you with changes and updates. If you've shown you'll do it all for them, they'll come to expect that from you.

Most of the people I've worked with who want to do a DH project don't necessarily want to learn about computation as such, and making them learn something they're not incentivized to do is an uphill battle (see also: me and Python for the years until I needed it).

So I've prioritized making sure people can manage basic content and, usually, structural things for their own project. And that's meant making projects using CMSes. Do they understand the CMS underpinnings (LAMP stack, etc)? Nope. But I'm okay with that, given the alternatives.

The downside to this CMS-oriented approach, though, is long-term maintenance. (Even more so than portability/off-line/sneakernet; self-contained LAMP stack on a USB stick is a thing.) At Stanford we're lucky to have a locked-down centrally-maintained Drupal that covers a lot.

But most places don't have Stanford Web Services. So I've come to terms with taking on the maintenance cost on projects that are active -- only as long as there's a limited number of active projects at a given time. Once a project is "done", though, it needs another solution.

That said, migration sucks, so I've started thinking more about how to anticipate that "archival" version from the beginning, at least for projects that never needed all the complexity of a CMS to begin with.

My dream is more user-friendly front-ends for Jekyll, to support authoring / updates / changes while the project is "active", even if it involves more complex and technically-fragile components. When the project is "done", just disable that overlay (& re-enable if needed later).

I'm not sure there's actually a way to fundamentally alter the trade-off between minimizing computer and maximizing labor (as I titled the paper I submitted to @elotroalex and @roopikarisam minimal computing DHQ cluster). You just have to decide how to distribute the pain. /fin