[btown]

I haven't used it, only read through documentation, but IMO Fluid's problem is not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least.

Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as:

    doc1 = Automerge.change(doc1, 'Mark card as done', doc => {
      doc.cards[0].done = true
    })

Contributor Martin Kleppman (of Designing Data-Intensive Applications fame) has great overview slides here: https://martin.kleppmann.com/2021/06/04/craft-conf.html . If anything, Automerge suffers from a "there's multiple ways to have a server backend, including P2P and centralized, and no one right way" anti-lockin problem, which is refreshing and also frustrating for people who just want to try something out. This is a solvable problem though!

[helixc]

Thanks for introducing Automerge, and pointing out the pros/cons! Will dig deeper.