Reactive Programming and the Spreadsheet

Spreadsheet formulas are reactive programming, and hundreds of millions of people have been writing reactive programs for more than forty years without knowing the term. Programming can be easy, and the right user experience makes you forget you're doing it. CoCube takes the spreadsheet's reactive cells, frees them from the grid, and lets you program without realizing that's what you're doing.

The part of a spreadsheet nobody notices

Open any spreadsheet. Type 10 into cell A1. Type =A1*2 into cell B1. Change A1 to 20. B1 updates to 40 without you asking.

That's it. That's reactive programming, named in an academic paper twenty years after the spreadsheet had already made it a household experience.

What is reactive programming?

Reactive programming is a model where values automatically recompute when the values they depend on change. You describe relationships between data instead of describing a sequence of steps to update it. When something upstream changes, everything that depends on it updates in the right order without any manual trigger.

The term was formalized in 1997 by Conal Elliott and Paul Hudak in Functional Reactive Animation, a paper that introduced functional reactive programming, or FRP, as a Haskell library for describing animations as time-varying values composed through pure functions. From there the pattern spread into web UI frameworks like React, Solid, and Svelte, into mobile reactive frameworks like RxJava and Combine, and into the way most modern user interfaces think about state. All of those frameworks describe the same idea the spreadsheet had in 1979.

Spreadsheets got there first, by accident

The first electronic spreadsheet was VisiCalc, released on October 17, 1979 for the Apple II, built by Dan Bricklin and Bob Frankston over the winter of 1978 to 1979. Bricklin thought of it while watching a Harvard Business School professor erase and rewrite entries on a blackboard every time a financial model changed. The insight was that a computer could keep the dependencies between the cells and redo the downstream work automatically. The reactive part wasn't the marketing pitch. It was the thing that made the tool feel magical to everyone who sat in front of one.

Excel inherited that model and scaled the reactive spreadsheet to hundreds of millions of users. In 2017, Satya Nadella called Excel Microsoft's most important consumer product. More people have written reactive code in Excel than have ever written a line in a reactive JavaScript framework.

Where the grid holds the reactive model back

The grid was a sharp answer to a 1979 question. It made structured data accessible to anyone who could read a table, and it mapped the reactive dependency graph onto a two-dimensional address scheme a non-programmer could navigate.

The grid is also the reason spreadsheets stop working at the exact moments reactive programming should be strongest.

The first grid failure is that the only way to group related values is to put them in adjacent cells. A UI component has a width, a height, a color, and a set of event handlers, and a spreadsheet cannot hold those four things as one named unit. You have to remember that A1 is "width" and A2 is "height" by convention, and the moment a row shifts, every formula that referenced A1 has to chase the value.

The second grid failure is that a cell can only hold a scalar value. A formula that returns a list has to spill across a row or a column, which means "a value" and "its shape on the sheet" become the same thing. Grouping, nesting, and parent-child relationships have no native representation. Every attempt to model hierarchy in a spreadsheet ends up as indented rows the computer cannot actually see as a tree.

The third grid failure is that the output is always a table. You can chart the data, but the chart is a projection of the grid rather than a first-class artifact. The grid is the source of truth, and everything the user sees is a view bolted onto it.

None of these are bugs in any particular spreadsheet. They are what happens when a 2D coordinate system is forced to carry a general-purpose reactive dependency graph.

A tree of cells instead of a grid

CoCube keeps the reactive model from the spreadsheet and throws out the grid.

Cells still exist, but they live on nodes in a tree instead of squares in a table. A node has named cells like Width, Height, Color, and Display, and each cell holds an expression the same way =A1*2 does in a spreadsheet. Setting Width to 200 and Height to 100 renders a rectangle. Setting Width to Height * 2 makes the width track the height reactively. Nodes can nest inside other nodes, and expressions can reach across the tree to read cells from parent or child nodes.

The reactive dependency graph is the same one you had in a spreadsheet. What changes is what a cell is attached to. In a spreadsheet, every cell is attached to a grid coordinate. In CoCube, every cell is attached to a named slot on a node in a tree, and that tree is also the visual output. Buttons, forms, charts, and dashboards are all trees of reactive nodes built the same way you would build a formula.

How CoCube fits the reactive programming model

CoCube is the answer to the question "what if the reactive-cell model didn't need a grid to live in."

Every CoCube document is stored as a Loro CRDT in a local database on your device, which is the same local-first model that drives the collaboration story across the rest of the site. Because nodes and cells are backed by CRDTs, two people can edit the same component on different devices and the results merge without conflict. Real-time collaboration is a property of the data model, not a feature bolted on after the fact.

The spreadsheet's reactive programming model was always the important part. CoCube takes that part, strips off the 2D container, and hands it back as a tree of visual nodes that can become whatever the document needs to be.

What to read next

If the part of this post that hooked you was the data-ownership story, the local-first software article is the framework for picking tools you won't regret in a decade. If it was the collaboration story, the CRDT article explains the sync technology that makes reactive components collaborative without a central server. If it was the visual programming angle, the visual programming language post is the next stop in this cluster. The larger practice these tools slot into lives in the personal knowledge management pillar, which anchors the whole cluster.

The question isn't whether the grid is the right container for a reactive model. It's whether any fixed container is.