About five years ago, I was building a spreadsheet-based web application with SpreadJS.
It worked well for most scenarios, but over time I realized the biggest challenge wasn't rendering spreadsheets.
It was helping people manage hundreds of Excel files that were almost, but not exactly, the same.
What was painful?
- Users already had hundreds of Excel workbooks, and asking them to migrate to a new format was simply unrealistic.
- Most workbooks shared the same structure, but each customer had made small manual changes over the years.
- We kept building more tools to simplify their workflow, but every new feature meant another button to learn.
- Most spreadsheet components are designed as UI libraries. That architecture makes background tasks(like auto-saving) surprisingly difficult.
My philosophy
The root problem was that businesses expected spreadsheets to behave like structured systems, while Excel was designed as a personal document. Every workbook became a slightly different source of truth, forcing backend systems to constantly validate, clean, and interpret the data.
I believe organizations should be able to define a contract for their spreadsheets. Users still work in the familiar Excel experience, but the workbook follows a well-defined structure instead of relying on conventions.
Once a workbook has a stable contract, it becomes much more than a document. Software can reliably access its data, automate repetitive tasks, and process thousands of workbooks without fragile scripts.
Finally, every business has its own workflow. It's impossible for a spreadsheet application to include every feature every team needs.
I like the philosophy behind VS Code: keep the core simple, and let extensions adapt it to different use cases. I believe spreadsheets should work the same way. Instead of building every workflow into the application, users should be able to extend it with their own business logic and automation.
Five years later
The company eventually shut down, but the idea stayed with me.
I open-sourced the project, which only included a formula parser and an OOXML parser, and continued working on it during evenings and weekends.
For a long time, it felt like an endless marathon. Every feature uncovered three more waiting to be implemented.
AI changed that. It didn't replace the engineering work, but it dramatically increased the amount of work one person could accomplish.
Today, I finally feel the project has grown into what I originally envisioned.
What I've done?
At the foundation is a set of Rust libraries that provide the core spreadsheet capabilities. They support features such as formula calculation, OOXML compatibility, undo/redo, and workbook manipulation.
Building the engine separately was important because spreadsheets are not just a user interface. They are also data and computation systems that need to run independently from the frontend. This architecture makes it possible to perform tasks such as background processing, automation, and server-side integration.
On top of the engine, I built two concepts to solve the problems I described earlier: Block and Craft.
A Block defines a stable structure inside a workbook. Instead of treating a spreadsheet as an arbitrary collection of cells, a Block describes what data exists, how it should be organized, and how software can reliably access it. Users can continue working with spreadsheets they already understand, while applications no longer need to depend on fragile cell coordinates.
Craft is the extension system built on top of this foundation. Inspired by the philosophy of VS Code extensions, Craft allows organizations to add their own business logic, automation, and workflows without modifying the core system, using JS.
I built a factory-simulator game(craft) to demonstrate how Block and Craft work together. If you play it carefully, you might be able to find some special formulas, that help you refer cell by (table name, key, field)! Isn't it cool?
Actually I have a lot more to share. If you're interested in this project, star it please!
Top comments (0)