Those technical problems are largely a result of trying to shoehorn collaboration onto older local-only PC era apps that store data in the form of simple files. For really rich collaboration you want something designed for it from the ground up, and Office is not. Office pre-dates even the Internet.

That has nothing to do with where the code lives and runs. There are unique technical challenges to doing it all at the edge, but there are already known solutions to these. If there was money in it, you'd have a lot of local first and decentralized apps. As I said, these technical challenges are not harder than, say, scaling a cloud app to millions of concurrent users. In some cases they're the same. Behind the scenes in the cloud you have all kinds of data sync and consistency enforcement systems that algorithmically resemble what you need for consistent fluid interaction peer to peer.

▲

jjcob 4 days ago | parent [-]

It's not a technical challenge, it's a fundamental problem.

When multiple people work on a document at the same time, you will have conflicts that will become very hard to resolve. I have never seen a good UI for resolving non-trivial changes. There is no way to make this merging easy.

The only way to avoid the merge problem is to make sure that the state is synchronised before making changes. With cloud based solutions this is trivial, since the processing happens on the server.

The local first variant of this would be that you have to somehow lock a document before you can work on it. I worked on a tool that worked like that in the early 2000s. Of course that always meant that records remained locked, and it was a bit cumbersome. You still needed to be online to work so you could lock the records you needed.

▲

api 3 days ago | parent [-]

It’s barely different from having multiple fat single page web apps editing a file in the cloud. All of those have local replicas of the data and present as if everyone is editing at once.

There are multiple ways to do this, like CRDTs plus raft based leader signaling for conflict resolution. The latter signaling requires almost no bandwidth. Raft based time skew adjustment works too if your problem domain can accept a small amount of uncertainty.

Like I said a lot of these same kinds of algorithms are used cloud side. All the big cloud stuff you use is a distributed system. Where the code runs is irrelevant. The cloud is just another computer.

	▲	jjcob 3 days ago \| parent [-]
		All these algorithms arent going to help if user A changes a headline from Arial to Helvetica while user B changes it to Helvetica Neue. There is no way to tell which of the changes should win. That's why most applications decided to require users be online for edits. when you have to be online, the chance of simultaneous edits becomes so small that you can just show an error message instead of trying to merge. The online requirement also ensures that you are notified of conflicts immediately, which is vastly preferable to users. Nothing worse than working on a document for hours and discovering someone else also worked on the same document and now you have two edited copies that someone needs to consolidate. That's the reason why offline first is becoming increasingly unpopular.