Reactive Programming and the Spreadsheet

Spreadsheets are the original reactive programming environment. Change one cell, and every cell that depends on it updates automatically. That's reactive programming, and hundreds of millions of people use it every day without knowing the term.

The problem isn't the reactive model. It's the container. Every spreadsheet application presents data the same way it did in 1979. Rows and columns, A1 to infinity. The grid was a brilliant design for its time, making structured data accessible to anyone who could read a table. But forty years later, the grid is still the only interface, and it's holding back what reactive programming could become.

What if cells weren't trapped in a grid?

CoCube takes cells and expressions from spreadsheets, throws out the 2D grid, and replaces it with a tree of nodes.

Each node contains named cells instead of lettered columns. A node might have cells called , , , and . Setting to and to renders a rectangle on screen. Setting to makes it blue. These aren't configuration options in a settings panel. They are cells, the same as in a spreadsheet, and they support the same kinds of reactive expressions.

You can set to . Now changing updates both dimensions reactively. You can set to change based on whether someone is hovering over the node. You can nest nodes inside other nodes to build complex layouts. The tree structure replaces the flat grid, and cells replace the notion of "properties" or "settings."

Everything is a cell. Everything is reactive. Everything is composable.

From static grids to visual software

In a traditional spreadsheet, the output is always a table. You can chart the data, but the chart is a secondary view bolted onto the grid. The grid is the source of truth, and everything else is a projection of it.

In CoCube, cells define the visual output directly. A node's cell controls how it renders. Rectangles, circles, lines of text, any vector shape. The node tree is both the data model and the visual output. There is no separation between "the data" and "what you see."

Building a UI component works the same way as building a spreadsheet formula. You define cells, write expressions that reference other cells, and the result is a live, interactive, visual component that updates in real time. Buttons, charts, forms, and dashboards are all trees of reactive nodes with cells.

Reactive expressions that reference anything

Spreadsheet formulas can reference cells in the same sheet or across sheets. CoCube's reactive programming model extends this to work across a full tree. Expressions can reference cells in the same node, in parent nodes, or in child nodes.

reads the parent node's width. reads the current node's own height. returns whether the mouse is over this node.

These references create a reactive dependency graph. When any referenced cell changes, everything downstream updates automatically. The spreadsheet's reactive programming model, extended from a flat grid to a full tree.

Local data and collaboration

CoCube stores everything locally on your device using CRDTs for conflict-free synchronization. You can use the tool without ever signing in, but creating an account gives you access to sync and collaboration features.

Because nodes and cells are backed by CRDTs, two people can edit the same component simultaneously from different devices and changes merge automatically without conflicts. Every component you build is collaborative by default, not as a feature bolted on after the fact, but as a property of the data model itself.

What this changes

The spreadsheet grid was a good answer to a 1979 question about how to make structured data accessible. The answer today is different. People don't need to organize data. They need to build with it, creating tools, visualizing workflows, prototyping interfaces, and sharing interactive documents.

CoCube keeps reactive cells, formulas, and references from spreadsheets and replaces the grid with a composable tree of visual nodes. The result is a medium where anyone can build real software using the same reactive programming model they already know from spreadsheets.