Collaborative editors are imperative; files are declarative. If I want to edit a Google Doc, my edit must be expressed in terms of the Google Docs interface. I

Collaborative editors are imperative; files are declarative. If I want to edit a Google Doc, my edit must be expressed in terms of the Google Docs interface. If there's a Vim macro that could make that change in moments, it doesn't matter, because I'm not editing text: I'm consuming an API through a web UI. This is why, when I write a Google Doc, I usually draft it in Vim, compile to markdown, and then paste the formatted text into the doc. My clipboard offers me an interoperable workflow that the Google Docs UI does not. This is why tools like Kubernetes use declarative yaml instead of interactive buttons and knobs. If your medium for communicating information is yaml, you can generate that yaml however you want, and update everything instantly. If your medium for communication is restricted to a set of buttons and dials, you're severely limited in terms of how you express information. > OK, you're on Office 365 and I'm on Google - so we'll have to work a little harder to set up access. You're going to have to use files, is what. You're going to download your Google Doc as a .docx file and upload it into 365. And then, unless you want to convert to .docx again, you're going to have to switch to 365 entirely. Google and Microsoft cannot interoperate imperatively with each other's APIs, but they can both parse the same declarative document files. "When should we pass data vs exposing an interactive interface" is an essential question in software architecture, and someone's making the same mistake here that you see in so much over-abstracted enterprise Java. Sometimes an interface just makes things worse.