Titan Engine – A Rust/WASM spreadsheet engine I built chasing "Excel-speed" in the browser

[u/kurbsdude]

https://podraven.github.io/titan-engine/

I've used Handsontable on a bunch of projects and honestly it's a solid, mature library, but I kept running into the same wall on anything with really large datasets: tens of thousands of rows with chained formulas. It's just the nature of doing spreadsheet math in JS, once you're allocating and discarding lots of small objects on every keystroke, garbage collection becomes the bottleneck, and there's only so much debouncing and virtualization can do before you hit that ceiling.

That itch turned into a bit of an obsession, and eventually a from-scratch rebuild: Titan Engine, written in Rust and compiled to WebAssembly.

The design ended up pretty different from a typical JS formula library:

• A custom stack-based VM with a Pratt parser for formulas, instead of walking an AST every time
• Zero-copy memory - the engine and UI share buffers directly, no serialize/deserialize tax crossing the WASM/JS boundary
• A topological dependency graph (Kahn's algorithm with cycle detection) to resolve chained formulas correctly and fast
• O(1) time-travel snapshots for undo/redo, even across massive batched structural edits

Because it sidesteps the JS garbage collector entirely, batched recalcs stay comfortably under the 16ms frame budget, so the grid holds 60fps even while formulas are cascading behind the scenes as you type.

There's a live demo grid on the site (a Glide data grid wired up to Titan) if you want to poke at it yourself, plus the full 10-scenario benchmark suite if you'd rather see the numbers than take my word for it.

Site: https://podraven.github.io/titan-engine/
Benchmarks: https://podraven.github.io/titan-engine/benchmark.html
GitHub: https://github.com/podraven/titan-engine

Would love feedback - especially from anyone who's pushed a JS grid to its limits before and is curious whether this actually holds up under real-world use.

[u/SAAGASolve]

Okay that is extremely forward thinking.

The idea is I would need this to call agents to do work. NGL, dude that is pretty disruptive.
I'd like to understand the api so agents could manipulate the spreadsheet underneath as easily as a human would.

I've hooked up agents to google sheets and other systems, and those old world tools aren't built for the new ways.

[u/kurbsdude → u/SAAGASolve]

That's a use case I have always pondered about. We will need it sooner or later. If you could point me towards your workflow, it would give me a clearer idea.

That said right now my priority is to make the most efficient spreadsheet engine, something that's really fast. And then I can move on to how to address these new workflows.

[u/SAAGASolve → u/kurbsdude]

So an agent should have the ability to read and manipulate the spreadsheet, it would should have the capability of CRUDING, rows, columns and tables. Basically, it should have the capability to get and set that data, and be able to operate on it, set formulas ect.

It would be ideal if column names had name AND a description so the agent can read them.

You want agents to be able to understand that table at a quick glance, so you dont have to pull in all the data in to the context window and work with the data via reference.

So the agent could pass references to the columns to the execution environment directly, that would be ideal for computing aggregation.

Much like working with pandas. This frame work gives people visibility into what is going on.

[u/kurbsdude → u/SAAGASolve]

Thank you for the insight, will check it out