June 18, 2026 · 8 min read
We spent 8 months rewriting our editing engine. Here's what we learned and why it actually matters for your day-to-day.
When two people edit the same file, every keystroke has to get transmitted, merged, and rendered on both screens. If you're in the same office, that's maybe 10ms. If you're in SF and your teammate is in Bangalore, that's 200-300ms per round trip. And that's if the network is behaving.
Our first version used Operational Transformation (OT) — same thing Google Docs uses. It works fine for text, but code isn't just text. You've got brackets that need to match, indentation that matters, and syntax that'll break if you're in the middle of a tag. OT doesn't understand any of that, so you'd get这些 moments where the code was temporarily invalid and everything broke.
CRDT stands for "Conflict-free Replicated Data Type" (terrible name, great concept). The idea is: everyone's edits get applied locally first, then merged later when updates arrive. As long as you follow certain rules, everyone converges to the same state.
We looked at using Yjs or Automerge (the two big open-source CRDT libraries). They're great projects, but: (a) Yjs is optimized for text but doesn't handle code structure, (b) Automerge has a big memory footprint for large files, and (c) neither gave us quite the control we wanted over cursor behavior.
So, like idiots, we decided to build our own. Took way longer than expected. But we got there.
Two main pieces:
Fractional indexing for positions. Instead of saying "this character is at position 5", we say "this character is between position 0.5 and 0.75". That means if two people insert characters at the same spot, they both get unique positions without renumbering everything. It's math, it works.
RGA for the character sequence. Replicated Growable Array. Each character knows which character came before it. When updates arrive out of order, we can still place them correctly. This is also how Google Docs works under the hood, roughly.
After rolling this out to everyone in May:
Honesty time: it's not perfect. If you've got a really slow connection (like, edge-of-3G slow), you'll still see lag. The CRDT helps, but physics is still a thing. Also, if you paste a 10,000-line file, things get chunky for a few seconds while we process it. Working on that.
Two things we're building now:
Binary file support. Right now we only handle text. If you want to collaborate on an image or a PDF, tough luck. We're adding that.
Local-first editing. If your internet dies, we save everything locally and sync when you're back. Already works, still has some edge cases. Should ship in v2.9 (August-ish).
If you want to try the new engine, create a free account. It's enabled by default now for everyone. Let us know if it feels faster — or if it breaks, that's useful too.