CRDTs cannot be "bolted ontop".
I really don't like this answer, but it is sadly true - even as an expert in the space (my database https://github.com/amark/gun is one of the few CRDT-based systems out there). And there is a simple reason for this:
Distributed systems are composable, they can be used to build higher-level strongly consistent systems on top. (Note: Sacrificing AP along the way, but then you can have a "tunable" system where each record you save you decide what consistency requirement you need, fast or slow.)
However centralized systems are not composable, you can't go "down" the latter of abstraction by adding more stuff.
But yes, if you have an existing editor or application and you try to just add CRDT, there are a lot of things that can go wrong.
"The flip side of the tradeoff is that you have to express your application logic in CRDT-compatible form"
Previously I assumed this was speaking of xi, but it sounds like this was meant generically (not specific to xi)?
I am curious now, it seems like the decision isn't a matter of CRDTs not working out (technically), and more a matter of the amount of effort not being worth it compared to other more synchronous approaches?
Absolutely the right call to make. Though, the last thing we want is people giving up on CRDT research which is how the hackernews title reads "CRDTs not working". So I was just trying to clarify things for future audience.
On the other hand, the idea of using CRDT for something other than collaborative editing (or certain types of databases where eventual consistency is a reasonable consistency model) is almost certainly not worth the complexity. That's what I wish I had known when I started.
Hey, I'm in Bay Area also, we should meet up. I've seen you've commented here on HN on Rik's makepad WebGL stuff and Joseph Gentle's OT (chatting with him on Monday!), which are both people & projects I'm fascinated by too.