If javascript/non-native CRDT implementations are responsive enough compared to existing algorithms for collaborative editing like OT, what incentives or cases exist to demand high performance native implementations?
To be clear, I think this is exciting stuff and your article is great. I'm just curious if there are any open research problems in this area that would make them more appealing in production.
This sort of data structure is extremely hard to well optimize in javascript because a lot of the performance comes from finicky datastructure optimizations to keep allocations down in the fast path. JS implementations will be "fine", but I think there'd be a 20+x performance uplift between yjs and a zero allocation style rust/C implementation using btrees / skip lists.
So on the server I'd rather have a native implementation - which would also remove the need to bundle a JS VM in databases. And if we have that, it should be pretty easy to pack the same code into wasm for the browser.
And this is all assuming a JS-native web world. I also want CRDTs for native apps like Bear. And it'd be much easier to use a rust library than link to v8.
To be clear, I think this is exciting stuff and your article is great. I'm just curious if there are any open research problems in this area that would make them more appealing in production.