For a couple years I thought PouchDB might give us a strong relatively standardized 80% solution, but then the CouchDB ecosystem kind of exploded (IBM bought Cloudant and pivoted it to a much worse IBM product; Couchbase continued to pivot away from CouchDB compatibility; Apache's politics got real confused real quickly about what the next version of CouchDB should even be and tried to rewrite it in six different languages).
I still think the multi-version document database approach is probably the easiest 80% solution baseline to work with for many projects, especially with a mixture of developer skill levels and document types. It doesn't save you from needing to solve conflicts, of course, but the default behavior (newest version wins) is a predictable one and generally just works until it doesn't work anymore by which point you should have a better idea of your application's specific domains and which conflicts are more important to resolve than others.
It's unfortunate that "Mongo-compatible" better won the marketplace, because CouchDB had a better focus on standardizing the sync experience between DBs and "Couch-compatible" was nice while it lasted (not nearly long enough).
I think the CRDT/OT library builders got a little bit too lost for too many years thinking that the "conflict-free" initial "C" in CRDT was fate or manifest destiny rather than hopes and dreams (to see dashed against the hard rocks of reality). As someone whose introduction to CRDT/OT was specifically from the lens of source control, I know that I was a skeptic that they'd ever truly achieve "conflict-free". Conflict resolution in source control will almost always be a human-in-the-loop touch point. I don't think you can solve for "conflict-free", I think you just try for more and more ways to sweep conflicts under the rug and I think that's a pretty good summary for part of why we've seen a lot of increasingly complex frameworks in the space that feel like they need increasingly more PhDs in the room to build apps on top of.
I think we're finally starting to see the other side of that mountain, as more (not all, but a lot more) of the developers working in that space do start to realize that you can't eliminate conflicts entirely in a general way for every application domain, you can just offer better tools for how to manage them when they naturally occur. The last few libraries that I've seen on HN have given me hope that we are starting to see more pragmatic and fewer dogmatic projects in that space and maybe soon one will feel like a real 80% good enough contender for general application development.
Amusingly, or perhaps predictively, I think the ones that are going to get there to feeling like an 80% good enough are going to be the ones that most look like a multi-version JSON document database at the high-level API and maybe also in the low level storage mechanics (to run anywhere localStorage does and/or any Mongo-compatible NoSQL store). In theory though, maybe that CRDT/OT-based version gives you a lot of knobs under the hood in between storage and high level specifics to help push individual applications from 80% to 90%+ if you learn how to configure it. That would be better than just an 80% if that happened, and is a reason to stay excited about the CRDT/OT space.
I think the other side of the wishlist is also hoping for better peer-to-peer/device-to-device solutions for the web and web browsers. There was a flurry of work that happened there during the cryptocoin boom that never quite built the 80% good enough solutions for general applications or that weren't too heavily tied to cryptocoin projects that added proprietary complexity. I'm afraid that as the cryptocoin boom has faded a lot of those projects are already abandoned and we are going to see another spike in interest in such tools again for a while. (Unfortunately AI doesn't need peer-to-peer, it needs big pipes to large central datacenters again.)
