Real-time collaboration

Open a ShareCode code space, send the link, and something small but surprisingly satisfying happens: a second cursor blinks into life next to yours. You are not taking turns. You are not squinting at a screen-share. You are both writing into the same live document, at the same time. Their edits slide in between your characters as they type, and you can be rewriting a function at the top of the file while they fix the tests at the bottom, neither of you stepping on the other. The rest of this page is about what that feels like to use — and, because we get asked, how it actually works underneath.

What you actually see

Each connected person gets a coloured cursor and selection. As they move through the file, you see where their attention is — which makes it natural to say “I'll take the parser, you take the tests” and then watch it happen. There is no save button: the document is always the latest merged state of everyone's edits. If your network hiccups, your changes are buffered locally and merged the instant you reconnect, so you never lose the lines you typed while offline.

Here is what that looks like in the real product — the live editor and the share dialog you use to pull someone in. Click either screenshot to open the viewer, and use the arrows to step between them.

🔍 Click to enlarge

🔍 Click to enlarge

Why edits never collide

The hard part of collaborative editing is what happens when two people change the same line within milliseconds of each other. ShareCode solves this with a conflict-free replicated data type (CRDT) via the Yjs library. Instead of sending “replace line 12,” each edit is expressed as a tiny operation tied to a stable identity inside the document. Because those operations are designed to commute, every client can apply them in any order and still arrive at exactly the same text. No server has to decide a winner, and no edit is silently dropped.

The relay server in the diagram above is deliberately dumb. It forwards the binary CRDT updates between connected clients and does not parse, inspect, or store the contents of your code. The current state of the document is persisted to Firebase Cloud Firestore so you can close the tab and return to it later — but the live merging happens at the edges, in each browser.

Presence, cursors, and awareness

The coloured cursors and “who's here” indicators ride on a separate, ephemeral channel called the awareness protocol. This data — cursor position, selection, display name — is never written to the document or stored on disk. It exists only while you are connected and vanishes when you leave, which is exactly what you want for something as transient as where someone's caret is.

Sharing a code space

Collaboration only starts once the other person is in the room, so we spent real time making the share step painless. Hit share on any code space and you get a single dialog (the second screenshot above) with every way you might want to hand the link off:

• Copy the link. Every code space has its own short URL (something like sharecode.in/ngG4). One click copies it, and anyone who opens it joins the same live session.
• Send it by email. Drop in a recipient address, add an optional short message, and ShareCode sends the link for you — handy for interviews and mentoring, where you want the invite to land in an inbox rather than a chat. Replies come back to your account email.
• Share through an app. The Share with device apps button opens your device's native share sheet, and there are one-tap buttons for WhatsApp, Telegram, X, LinkedIn, Facebook, and Reddit — so the link goes wherever your team already talks.
• Scan the QR code. Point a phone camera at the code in the dialog and the same code space opens on that device — useful for jumping from a laptop to a phone, or getting a room full of people into one session quickly.
• Embed it on your own site. The dialog hands you a ready-made <iframe> snippet, so a live, editable code space can sit right inside your blog post, docs, or course page.

That embed code looks like this — paste it anywhere HTML runs and the editor renders inline, fully interactive:

<iframe
  src="https://www.sharecode.in/ngG4"
  width="100%"
  height="500"
  style="border:1px solid #e5e7eb;border-radius:12px"
  title="ShareCode CodeSpace"
  loading="lazy"
></iframe>

Because the embedded space is the real thing — not a screenshot — readers can run and edit the code without leaving your page. It is the same code-space ID in the URL and the iframe, so whatever you share is exactly what they see.

Operational transformation vs. CRDTs

When we started building this, we had to pick a side in an old debate. There are two proven ways to let many people edit one document at once, and the choice shapes everything else. The older approach, operational transformation (OT), records each change as an operation — “insert ‘x’ at position 12” — and then rewrites incoming operations against the ones already applied so that everyone converges. OT works, and it powered the first generation of collaborative editors, but it leans on a central server to transform and order operations correctly. Getting those transformations right for every edge case is famously difficult, and a bug usually shows up as a document that silently diverges between users.

ShareCode uses the newer approach, conflict-free replicated data types (CRDTs), through the Yjs library. Rather than rewriting operations against each other, a CRDT models the document so that concurrent edits commute by construction: applying them in a different order on different machines still produces an identical result. That property is what lets the merging happen at the edges, in each browser, instead of on a server that has to be the single arbiter of truth. It also makes offline editing natural — your edits are just more operations to merge whenever you reconnect. The cost is that CRDTs carry a little extra metadata per character to track identity, which is a trade we happily make for resilience and simplicity.

What happens when the network drops

Real networks are unreliable, and a collaborative editor that falls apart the moment a connection blips is not much use. Because each client holds a complete local replica of the document, ShareCode keeps working even while you are disconnected. You can keep typing; your edits are captured as CRDT updates and buffered locally. When the connection comes back, those buffered updates are exchanged and merged with whatever everyone else did in the meantime, and all replicas converge again without anyone having to resolve a conflict by hand.

This is the practical payoff of the CRDT model. There is no moment where the editor locks up waiting for the server, no dialog asking you which version to keep, and no risk that a slow connection quietly discards the paragraph you just wrote. The worst a dropped connection does is delay when others see your changes — never lose them.

Keeping it fast — the latency budget

Collaboration only feels real if the other person's edits appear almost as fast as your own. The target is to keep round-trip sync well under a tenth of a second on a healthy connection, because beyond that the lag becomes noticeable and people start talking over each other's edits. A few design choices make that possible. CRDT updates are tiny binary messages, not full-document snapshots, so each keystroke costs very little to send. They travel over a persistent WebSocket connection that stays open for the whole session, avoiding the overhead of opening a new request per change. And the relay simply forwards those messages without parsing them, so it adds almost no processing delay.

Rendering matters too. The editor applies incoming updates incrementally rather than re-drawing the whole file, so a long document stays responsive even when several people are typing into it at once. The result is an editing experience that feels less like “syncing” and more like sitting at the same keyboard.

Where your code actually lives

The live merging happens in the browser, but the document still needs a home so it survives a page reload. ShareCode persists the current state of each code space to Firebase Cloud Firestore. That is what lets you close the tab, come back hours later, and find your work exactly where you left it, and it is why a shared link keeps opening the same document over time. The relay that forwards live updates is deliberately stateless with respect to your content — it never reads, parses, or stores the code it passes between clients. Persistence and relaying are kept as separate concerns, which keeps each one simple and easy to reason about.

A practical consequence worth knowing: anyone with a code space's link can open it, so treat the link like a key. If you are signed in, you can lock a space so that only you can edit it, which is useful when you want others to read along without changing anything. We also recommend not pasting secrets — API keys, passwords, private credentials — into any online editor, ShareCode included.

Common questions about collaborative editing

How it compares to other collaborative tools

If you have used Google Docs, the feeling of ShareCode's editing will be familiar — multiple cursors, instant updates, no save button — but applied to code rather than prose, with syntax highlighting for the language you are working in. Compared to an IDE's built-in live-sharing feature, the big difference is setup. Those tools are excellent once both people have the same editor installed, signed in, and configured, but that is exactly the friction that stops a quick, spontaneous session from happening. ShareCode trades the deep IDE integration for the ability to start in seconds from any browser, which is the right trade for interviews, teaching, and “can you look at this?” moments.

It is also worth being clear about what shared editing does not change: it is still your responsibility to review what lands in the document, because everyone with edit access can change anything. In practice that openness is the point — it is what makes collaboration feel immediate — but it is why the lock feature exists for the moments you want a read-only audience, and why a shared link should only go to people you trust.