[oarsinsync]

> I get the advantage of keeping your content in plaintext for portability

Portability is secondary for me. For me, the primary reason for keeping content in plain text is disaster recovery.

When my systems are down, when my applications aren’t working, if my documentation is also inaccessible, this makes things a lot harder.

If my documentation is primarily in plain text / markdown, it’s really easy to be able to read those docs again, even when everything else has fallen over.

[al_borland]

I’ve made some of my tools with this in mind, because they are for a team that has to keep functioning during a disaster recovery situation.

I stubbornly kept the main page as HTML. All libraries are download and sourced locally, instead of using a CDN. I use as little server side as possible, and just use basic PHP when I must. The idea being that in a worst case scenario the users can simply open the index.html on their desktop had have 95% of the functionality. If they run something like xampp, they can get 100%. This app is basically their map to the rest of the infrastructure, with some helper tools. They’d be lost if it went down when they needed it most. That said, it’s never come to this in 15 years and there have been several big DR events in that time. I still like having it as an option in my back pocket.

I recently handed it off to someone else to manage. I should probably share this part of my philosophy as it seems like they are trending toward adding complexity and dependencies, because they’re hip and cool.