Spreadsheets Reimagined: JSON Structures, Vim Bindings, and the Quest for a Better Data Tool

The familiar grid of rows and columns that defines modern spreadsheets has remained fundamentally unchanged for decades. We've layered formulas and pivot tables on top, but the underlying model - a two-dimensional array of cells - struggles with data that doesn't fit neatly into tables. What if we could work with spreadsheets that understand JSON's nested structures, arrays, and objects natively, while retaining the keyboard-first philosophy of Vim?

This is the question driving awalgarg.me's experimental project, currently in pre-pre-alpha, which reimagines the spreadsheet as a JSON-aware editor with Vim keybindings. The core insight is that most real-world data is hierarchical, not tabular. Consider a configuration file, an API response, or a dataset with nested relationships - these map awkwardly onto traditional spreadsheets, requiring workarounds like multiple sheets or flattened representations. The proposed system treats data as a JSON-like tree, allowing users to navigate and edit nested structures with the same fluidity that Vim provides for text.

The Interaction Model: Vim Philosophy Meets Data Editing

The project's interaction design reveals a thoughtful synthesis of Vim's modal editing principles with data manipulation. Navigation uses arrow keys, but the editing commands follow Vim's mental model:

• i edits the focused cell's value
• I edits the key of a focused cell (when within a hash/object)
• d clears a value by setting it to null
• D deletes the cell entirely
• y, Y, a, A, o, O follow the expected Vim patterns

This isn't merely Vim aesthetics grafted onto a spreadsheet. The key insight is that Vim's text objects map naturally onto JSON structures. Just as Vim understands words, sentences, and paragraphs, this system understands keys, values, arrays, and objects. When you're inside a hash, pressing I doesn't just put you in insert mode - it specifically targets the key, recognizing that in a key-value pair, the key is a distinct object worth editing separately.

The demonstration shows this in action: navigate to a cell with arrow keys, press i, and a textarea above focuses for editing. Press enter to update. This immediate feedback loop, combined with the ability to address cells via JSON paths like this["complex key"].your_table[1].structField, suggests a system where data navigation becomes as precise and efficient as code navigation.

Data Types Beyond the Cell

Unlike traditional spreadsheets that store everything as either numbers, strings, or formulas that evaluate to one of these, this system embraces JSON's type system:

• Numbers and booleans work as expected
• Strings remain fundamental
• Arrays can be heterogeneous, containing mixed types
• Hashes (objects) store key order alongside values, preserving the original structure
• Tables are a special case: homogeneous arrays of structs where values can be derived

The example provided - a currency table with dynamically formatted values - hints at powerful capabilities. The "formatted" column isn't stored data but computed: EUR 100 becomes € 100, GBP 50 becomes £ 50. This suggests the system supports derived values, though the implementation details remain to be seen. More importantly, the note that "tables can't be navigated into yet" reveals the project's honest, work-in-progress nature.

Planned Features: From Local Editor to Distributed System

The roadmap reveals ambitious scope:

Layout Management: The tension between automatic grid-based arrangement and manual freeform control reflects a deeper question about spatial organization of hierarchical data. Should the system impose structure, or trust users to arrange their workspace?

Addressing and Path Resolution: The ability to reference cells via JSON paths opens up programmatic access. Combined with relative addressing, this could enable powerful formulas that traverse the data tree rather than just referencing adjacent cells.

Scripting and Computation: Perhaps most significantly, the plan to support "your choice of scripting language" with optional server-side computation suggests a system that bridges local editing and distributed processing. Large documents could lazy-load, with computation offloaded to servers when needed. This moves beyond the single-file paradigm of traditional spreadsheets into a networked data editing environment.

Auto-completion and Undo/Redo: Standard features, but their inclusion alongside path-based addressing suggests intelligent completion that understands the data structure.

Formal Specification: Creating a formal spec for the document format indicates serious intent toward interoperability and perhaps open-sourcing.

Desktop and Mobile Clients: QT for desktop and Android app for mobile shows cross-platform ambition.

The Broader Pattern: Spreadsheets as Code

This project sits within a larger trend of rethinking spreadsheets for modern development workflows. Tools like VisiData have long shown that terminal-based data manipulation can be powerful. The innovation here is the explicit JSON data model combined with Vim's editing philosophy.

The implications extend beyond convenience. By treating data as code-like structures, the system could enable version control workflows, collaborative editing, and integration with development tools. Imagine git-diffing spreadsheet changes, or using the same linters and formatters you use for JSON files.

Challenges and Trade-offs

The approach isn't without challenges. Hierarchical data can be difficult to visualize in two dimensions. The project acknowledges this with planned layout management features. There's also the question of discoverability: Vim keybindings are powerful but have a steep learning curve. Will users accustomed to Excel's menus embrace modal editing for data?

The decision to store hash key order is interesting - it suggests the system values preserving the original structure exactly, even though JSON objects are technically unordered. This prioritizes fidelity over strict spec compliance.

A Vision for Data Work

What awalgarg.me is building feels less like a spreadsheet replacement and more like a new category of tool: a structured data editor that understands both the programmer's mental model (JSON, Vim) and the analyst's need for derived values and tables. It's a tool for people who live at the intersection of data and code, where the friction of converting between representations costs more time than the actual analysis.

The project's pre-pre-alpha status means these ideas are still fluid. But the core vision is clear: spreadsheets should understand the data structures we actually work with, and editing should be as efficient as the best text editors. For developers who've ever tried to edit a complex JSON configuration in a traditional spreadsheet, that vision can't come soon enough.