Hi Proton Team,
First off, I want to say that what you've built with Proton Docs is genuinely impressive. End-to-end encrypted spreadsheets that actually work is no small feat, and I really appreciate the engineering that went into making this happen.
I've been using your spreadsheet app and thinking a lot about architecture lately. What you've accomplished is amazing—truly. But I also believe that trying to build the same thing in different ways can teach you a lot, even if you never ship it. I wish I could rewrite all my own apps in every language and framework just to see what I'd learn. But if I had to choose just one thing to rewrite, one experiment that felt like it might reveal something fundamental... I'd rewrite a spreadsheet app in SolidJS.
I know how this sounds. It feels a bit like suggesting someone reconsider their religion, and I've been hesitant to even bring it up. And look—I could be completely wrong about this. I don't know your codebase. I don't know what you've already tried or what constraints you're working under. I'm looking at this from the outside, and I'm sure there are a hundred things I'm not seeing.
But here's the thing that keeps nagging at me, and I could be completely wrong about this—I don't know all the facts of your architecture or the constraints you're working under—but: spreadsheet cells are literally signals.
I mean this in the most fundamental, computer science sense. A cell holds a value. When that value changes, dependent cells recalculate. That's it. That's a signal. And React... React doesn't really think in signals. It thinks in snapshots and reconciliation.
Right now, when I edit a cell in your spreadsheet, React has to:

Re-run component functions
Build a new virtual DOM tree
Diff it against the old tree
Figure out what changed
Update the DOM

Or at least, that's how I understand it works. I could be missing optimizations you've implemented that I can't see from the outside. But in principle, a spreadsheet cell doesn't need a diff. It knows exactly what changed—its value. And it knows exactly who needs to know—the cells that reference it.
This is where signal-based reactivity (like what SolidJS uses) becomes almost eerily perfect for spreadsheets. Not because SolidJS is "better" (I know how loaded that word is), but because the mental model matches the problem domain exactly:
A1 = 5 // This is a signal
A2 = A1 * 2 // This is a computed signal
When A1 changes, only A2 updates. No diffing. No reconciliation. No re-rendering parent components. Just: "A1 changed, tell A2." That's it.
I realize I'm oversimplifying massively, and maybe I'm missing something fundamental about why this wouldn't work in practice. I know you've got virtualization, you've got workers handling crypto, you've got complex state management for collaboration, and you've got a whole ecosystem built on React. There are probably architectural decisions I'm completely unaware of that make this harder—or maybe even impossible—than I'm imagining.
But I also can't shake this feeling that you're fighting React's fundamental architecture every time a cell updates. You've done an amazing job making it work (seriously, the fact that it works as well as it does is a testament to your engineering), but it's like... you've built a beautiful house with the wrong foundation for the soil type, you know?
Or maybe I'm completely off base. Maybe React is actually perfect for this and I'm just not seeing it.
Here's what I'm actually suggesting (and please feel free to ignore this):
Maybe it's worth experimenting with a signal-based approach for just the grid layer? Not a full rewrite. Not even for production. Just... to see. To learn what happens when the mental model aligns so perfectly with the problem. It could be SolidJS, or Preact Signals, or even a custom implementation. The framework doesn't matter as much as the fundamental reactivity model.
Because I genuinely believe you'd learn something valuable, even if you never ship it. Sometimes the act of building the same thing differently reveals insights about the original that you couldn't see any other way.
And if the theory holds—if signals really could be 5-10x faster for spreadsheet operations (which the benchmarks suggest, though I know benchmarks lie), and if they use significantly less memory—then for something like Proton Docs, which people use for work, where performance and reliability matter, those insights might be worth exploring. Even if it just confirms that React was the right choice all along.
I know this is a big ask, even as an experiment. I know you have a roadmap. I know React works and has a huge ecosystem and hiring is easier and a million other practical reasons to stick with what you have. And I'm not saying you're wrong for using React—it was probably the right choice when you started.
But if I could rewrite just one of my apps to learn something fundamental about architecture, it would be this. A spreadsheet in signals. Because it just... fits.
I'm just saying... spreadsheet cells are signals. And sometimes when something just makes sense at that fundamental level, it's worth exploring. Even just as an experiment.
Or maybe it's not worth it. Maybe you've already run these numbers and they don't add up. Maybe there's something about signals that breaks with encryption, or collaboration, or some other piece I can't see from here. I genuinely don't know.
Again, I love what you've built. I'm rooting for you. And if you've already considered this and decided against it—or if I'm just fundamentally misunderstanding the problem—I completely understand.
Thanks for listening to my rambling.