How DingTalk Built a High‑Performance, Collaborative Online Spreadsheet from Scratch

Hello, I am Ye Zhai from DingTalk. Thanks to the D2 committee for the opportunity to share.

Today I will present "DingTalk Spreadsheet — Building an Online Excel from Zero to One".

Excel has a 30‑year history and a massive feature set. In recent years, web‑based alternatives such as Google Sheets and Office 365 have emerged, and DingTalk Spreadsheet is one of them.

After nearly a year of development, the product implements about 70% of Excel's functionality and is about to launch. I will discuss the technical challenges and solutions from a frontend perspective.

Module Composition

Collaboration engine – exchanges data with the server to enable multi‑user editing.

Core model – a local database providing high‑performance CRUD operations.

Controller – the service layer where most business logic resides.

Table component – a React component rendering the main interface via Canvas.

Table application – the final product users interact with.

Story 1: Scalable Table

The basic data model, called the "chessboard model", represents rows and columns as a 2‑D array (often implemented with a quadtree). Adding features like cell styles, formulas, or merges requires updating the model for every row/column operation.

To avoid scattering updates, we introduced a RangeMan module that manages rectangular ranges (Range) for styles, formulas, and merges. All functional modules register their ranges with RangeMan, which updates them automatically when rows or columns are inserted or deleted.

RangeMan decouples core table logic from business features, enabling extensions such as filtering, sorting, and conditional formatting.

Story 2: Collaborative Table

Collaboration relies on two concepts: CP (Check Point) – the full snapshot of the table, and OP (Operation) – an incremental change. OPs are transformed against each other to maintain consistency.

The first algorithm, GOT , performs OT (Operation Transformation) on the client side only. It works but suffers high rollback rates under dense concurrent edits.

The second algorithm, COT , moves OT to both client and server, allowing the server to transform incoming OPs before broadcasting. This raises the scalability ceiling at the cost of duplicated transformation logic.

Both algorithms are implemented in Rust, compiled to WebAssembly, and shared between frontend and backend to guarantee identical behavior.

Story 3: High‑Performance Table

To achieve smooth, long‑duration usage we render the main table UI with Canvas instead of the DOM, avoiding the heavy overhead of the browser's rendering pipeline.

The rendering pipeline is layered: grid layer, content layer (background, text, decoration), and selection layer. Only the layers affected by an operation are re‑drawn, minimizing work.

We employ a double‑buffered canvas strategy. Two off‑screen canvases, each slightly larger than the viewport, hold pre‑rendered content. Scrolling simply copies the needed region from the buffer; when a threshold is reached we repaint the buffer in a web‑worker.

A custom text layout engine handles measuring, line‑breaking, word‑splitting, and alignment inside cells, since Canvas does not provide automatic layout.

Conclusion

We built DingTalk Spreadsheet by borrowing mature desktop designs (RangeMan, rendering pipeline, typography algorithms) and integrating cutting‑edge web technologies (WebAssembly, Workers, Canvas). The result is a complex, high‑performance, collaborative web spreadsheet.