7 comments

  • GermanJablo20 hours ago
    I remember reading Part 1 back in the day, and this is also an excellent article.<p>I’ve spent 3+ years fighting the same problems while building DocNode and DocSync, two libraries that do exactly what you describe.<p>DocSync is a client-server library that synchronizes documents of any type (Yjs, Loro, Automerge, DocNode) while guaranteeing that all clients apply operations in the same order. It’s a lot more than 40 lines because it handles many things beyond what’s described here. For example:<p>It’s local-first, which means you have to handle race conditions.<p>Multi-tab synchronization works via BroadcastChannel even offline, which is another source of race conditions that needs to be controlled.<p>DocNode is an alternative to Yjs, but with all the simplicity that comes from assuming a central server. No tombstones, no metadata, no vector clock diffing, supports move operations, etc.<p>I think you might find them interesting. Take a look at <a href="https:&#x2F;&#x2F;docukit.dev" rel="nofollow">https:&#x2F;&#x2F;docukit.dev</a> and let me know what you think.
  • kaiwenwang15 minutes ago
    It appears Moment is producing &quot;high-performance, collaborative, truly-offline-capable, fully-programmable document editor&quot; - <a href="https:&#x2F;&#x2F;www.moment.dev&#x2F;blog" rel="nofollow">https:&#x2F;&#x2F;www.moment.dev&#x2F;blog</a><p>There seems to be a conflict of interest with describing Yjs&#x27;s performance, which basically does the same thing along with Automerge.
    • antics9 minutes ago
      Author here. To be clear, we do not in ANY WAY compete with Yjs! We are a potential <i>customer</i> of Yjs. This article explains why we <i>chose not to be</i> a customer of Yjs, and why we don&#x27;t think most people building real-time collaborative text editors should be, either.
  • antics7 minutes ago
    Hi folks, author here. I thought this was dead! I&#x27;m here to answer questions if you have them.
  • samlinnfer46 minutes ago
    Just use OT like normal people, it’s been proven to work. No tombstones, no infinite storage requirements or forced “compaction”, fairly easy to debug, algorithm is moderate to complex but there are reference open source implementations to cross check against. You need a server for OT but you’re always going to have a server anyway, one extra websocket won’t hurt you. We regularly have 30-50k websockets connected at a time. CRDTs are a meme and are not for serious applications.
    • chrisweekly8 minutes ago
      &quot;CRDTs are a meme and are not for serious applications.&quot;<p>That is one hot take!
  • bawolff35 minutes ago
    Reminds me a bit of google-mobwrite. I wonder why that fell out of favour.
  • presspot2 days ago
    Replacing CRDT with 40 lines of code. Amazing.
  • truetraveller23 minutes ago
    Very likely AI slop, very hard to read. Too many indications. HN should have another rule: explicitly mention if article was written (primarily) by AI.
    • antics14 minutes ago
      I&#x27;m the author. Literally 0% of this was written with AI. Not an outline, not the arguments, not a single word in any paragraph. We agonized over every aspect of this article: the wording, the structure, and in particular, about whether we were being fair to Yjs. We moved the second and third section around constantly. About a dozen people reviewed it and gave feedback.<p>EDIT: I will say I&#x27;m not against AI writing tools or anything like that. But, for better or worse, that&#x27;s just not what happened here.
    • comex7 minutes ago
      It doesn’t strike me as AI. The writing is reasonably information-dense and specific, logically coherent, a bit emotional. Rarely overconfident or vague. If it is AI then there was a lot more human effort put into refining it than most AI writing I’ve read.
    • utopiah19 minutes ago
      Funnily enough I had 2 HN tabs open, this one and <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=47394004">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=47394004</a>