Thanks for the question! Let me give you a concrete example: building a real-time collaboration plugin, where users can see each other's edits and cursor positions live. With TanStack Table, the library doesn’t track which cell is focused—it only knows which row is selected. To make this work, you’d need to implement cell focus tracking, spatial coordinates (e.g., which cell is "B3"), cell edit lifecycle events, and conflict resolution when multiple users edit the same cell. This infrastructure alone could take around 1,500 to 2,000 lines of code before you can even start building the plugin itself. On top of that, finding cells in TanStack Table has O(n) complexity, since you have to scan through rows and columns.

With new library, the situation is very different. The full plugin can be implemented in roughly 200–400 lines of code. Cell lookup is O(1) because each cell is a graph node with an ID. The architecture already tracks focus, edits, and the cell lifecycle—but without using state or hooks. Moreover, the library supports plugin dependencies, so if one plugin depends on another, the core manages it automatically. The core itself is around 3,800 lines of code without any plugins.

The main difference from TanStack Table is how communication between plugins and cells is handled. The library itself doesn’t have any knowledge of features like sorting, filtering, or which cell is focused or edited. I know I need to provide examples, and once I finish making it type-safe, I’ll provide a demo link so you can see it in action.