Building a Real-time Collaborative Text Editor with Javascript and Webrtc

const dataChannel = peerConnection.createDataChannel('collabEditor', {
  ordered: true
});

`. However, contenteditable is notoriously difficult to synchronise because it produces unpredictable HTML across browsers. A better choice is a library like Quill.js, which provides a structured document model called Parchment. Alternatively, you can use ProseMirror, which offers even finer control over the document state and supports collaborative editing natively through its collaboration plugin.

For this project, we will use Quill because it abstracts away the complexity of contenteditable while still giving us access to the raw delta format, which is easy to serialise and transmit.

Capturing Edits and Sending Changes

Quill emits a `text-change` event whenever the document changes. You can listen to this event and send the delta to all connected peers:

quill.on('text-change', function(delta, oldDelta, source) {
  if (source === 'user') {
    dataChannel.send(JSON.stringify(delta));
  }
});

The `source` check ensures that you only broadcast changes made by the local user, not changes that were applied remotely. This prevents infinite loops where an incoming edit triggers another outbound edit.

Handling Synchronization and Conflicts

Operational Transformation

When two users edit the same document simultaneously, conflicts are inevitable. For example, User A inserts a character at position 5 while User B deletes position 3. Without a resolution strategy, the final document will diverge. Operational Transformation (OT) is a proven algorithm that maintains document consistency by transforming operations against each other. OT works by keeping a version number for each operation and adjusting incoming operations based on the current state.

Implementing OT from scratch is complex. Instead, consider using a library like ot.js or the built-in transformation logic in ProseMirror. These libraries handle the mathematical heavy lifting so you can focus on integration.

CRDTs as an Alternative

Conflict-free Replicated Data Types (CRDTs) are another approach that has gained popularity. Unlike OT, CRDTs do not require a centralised server or operation ordering; each peer maintains a local copy and reconciles differences automatically. Libraries like Automerge or Yjs implement CRDTs and offer seamless integration with popular editors. Yjs, for instance, has a Quill binding that makes it almost trivial to add collaboration.

The choice between OT and CRDT depends on your use case. OT generally has lower memory overhead and works well for text-only documents. CRDTs are better suited for complex data structures and offline editing scenarios.

Batching and Throttling

Even with perfect conflict resolution, sending every keystroke over the network creates unnecessary traffic and can overwhelm peers. Implement a batching mechanism that collects edits for a short interval (50-100 ms) and sends them as a single operation. This reduces overhead without sacrificing real-time feel. You can use a simple debounce on the `text-change` event:

let batch = [];
quill.on('text-change', function(delta) {
  batch.push(delta);
  clearTimeout(batchTimer);
  batchTimer = setTimeout(() => {
    dataChannel.send(JSON.stringify(batch));
    batch = [];
  }, 50);
});

Architecting for Scale and Reliability

Managing Peer Connections

If more than two users join the same document, you face a mesh network scenario where each peer must open a connection to every other peer. This scales poorly because the number of connections grows quadratically with the number of participants. For sessions with more than 5-6 users, consider using a Selective Forwarding Unit (SFU) or a Multipoint Control Unit (MCU) to relay data through the server. Alternatively, you can designate one peer as the broadcaster and have others relay through it.

State Persistence

WebRTC is ephemeral by design. If a user refreshes the page, they lose all connection state and the document reverts to its initial state. To prevent data loss, you need a server-side persistence layer. Store the document state in a database like PostgreSQL or Redis after each batch of edits. When a new user joins, they fetch the current state from the server before connecting via WebRTC. This hybrid approach gives you the best of both worlds: low-latency peer-to-peer editing and durable storage.

Security and Privacy Considerations

Encrypting Data Channels

WebRTC data channels are automatically encrypted with DTLS (Datagram Transport Layer Security). This means the content of your edits is safe from eavesdropping even as it travels through unknown network hops. However, the signalling channel is not encrypted by default, so you must serve it over HTTPS and WSS (WebSockets Secure). Never transmit plaintext offers or answers over unencrypted HTTP.

Authentication and Access Control

Just because a peer can connect does not mean they should have edit access. Implement a token-based authentication system where users obtain a signed token from your server before they can initiate a WebRTC connection. The token should contain the user’s role (editor, viewer, admin) and the document ID they are allowed to access. Validate this token on both the signalling server and within the editor logic to prevent unauthorised modifications.

Preventing Injection Attacks

If you use contenteditable, malicious users could inject arbitrary HTML, including scripts. Even with a sanitised editor like Quill, you should validate all incoming deltas on the receiving end. Quill’s delta format is strict, but you can add an additional sanitisation step that removes any unexpected attributes. Never trust user input, even from a peer you have authenticated.

Testing and Debugging

Simulating Multiple Users

Testing a collaborative editor requires at least two browser instances. Use incognito windows or different browser profiles to simulate separate users. Tools like BrowserStack allow you to test across different browsers and devices simultaneously. Pay special attention to edge cases such as rapid successive keystrokes, simultaneous large pastes, and network interruptions.

Monitoring Data Channel Health

WebRTC data channels can drop due to network changes or NAT timeouts. Implement a heartbeat mechanism that sends a small `ping` message every 5 seconds. If no response is received within 10 seconds, assume the connection is dead and attempt to re-establish it. Log all connection state changes to a monitoring dashboard so you can detect patterns in connection failures.

Performance Optimisations

Compression

Text edits are small, but when many users are editing, the volume of messages can add up. Enable compression on the data channel if your library supports it. You can also compress the JSON payload on the application layer using a library like `pako` (zlib in JavaScript). This reduces bandwidth consumption by up to 80% for repetitive edit patterns.

Selective Synchronisation

Not every edit needs to be sent to every peer. For example, when a user types quickly, only the final state after key-up matters, not every intermediate character. Use an idle detection mechanism: if the user is actively typing, buffer the changes and send only the consolidated delta when they pause. This drastically reduces the number of messages while maintaining a smooth editing experience.

Lazy Rendering

If the document becomes large (hundreds of pages), rendering the entire content for each incoming edit can cause UI jank. Implement virtual scrolling or pagination so that only the visible portion of the document is re-rendered. This is especially important for mobile devices with limited processing power.

Deployment and Production Readiness

Choosing a Signalling Server

For production, you need a robust signalling server that can handle thousands of concurrent connections. Node.js with socket.io is a popular choice because of its scalability and built-in fallback mechanisms. If you prefer a managed solution, consider services like Stream or Twilio, which offer WebRTC infrastructure out of the box.

Testing with Real Networks

Local testing hides network latency and packet loss. Deploy your editor to a staging environment and test with peers on different continents. Use tools like Wireshark to analyse WebRTC traffic and identify bottlenecks. Pay attention to the ICE candidate selection process; some peers might take long routes due to misconfigured STUN/TURN servers.

Monitoring and Logging

Add structured logging for all WebRTC events: connection state changes, data channel open/close, and edit operations. Use a centralised logging service like Datadog or Loggly to aggregate logs from all peers. This helps you debug issues in real time and identify patterns that lead to connection drops.

Conclusion

Building a real-time collaborative text editor with JavaScript and WebRTC is a rewarding endeavour that stretches your understanding of networking, state management, and UI performance. By leveraging the power of peer-to-peer connections, you can create an editing experience that feels instant and scales without expensive server infrastructure. The key components are a reliable signalling mechanism, a structured editor surface like Quill or ProseMirror, and a robust conflict resolution strategy using OT or CRDTs.

As you move forward, consider the trade-offs between fully decentralised and hybrid architectures. For small teams, pure WebRTC with a lightweight signalling server is ideal. For larger deployments, adding a server layer for persistence and selective forwarding gives you the control you need. Whichever path you choose, the principles outlined here will serve as a solid foundation for building production-ready collaborative tools.