Where were you when I started writing my code ;_; I have also written a spreadsheet engine in Rust from scratch, for an app built with the iced GUI library!
I'll take a deep dive through your repo and compare notes later this week. Congrats on the huge lift!!
1) mit license
2) using plausible instead of Google analytics. Practically speaking, uBO is going to block both by default, but for non-tech users this is great.
3) appreciate how the app respects your pc when the web app is running in the background. Very low footprint, no random CPU spikes or anything.
WRT: Plausible. I think I will remove all kinds of analytics, I'm not yet convinced I should be using them at all. That being said I had been longing to try Plausible for the a long time and this seemed like a good opportunity.
Thanks for the feedback, I will keep this on the back of my head. This and things like sensitivity analysis are not in our immediate roadmap, but this is the kind of thing that would be fairly easy to add. You can do it right now programmatically, of course.
At the moment they are a full production ready product, we only have an MVP.
If and when we reach version 1.0 we might be comparable. And you might want to use one or the other. It its difficult to say who the two product will compare in a year from now but probably IronCalc will be lighter, easier to integrate, faster in computations but not so feature full.
nice project ! and attempt to modernize the spreadsheet tech stack. be warned though, that the feature-set of the modern spreadsheet is gigantic, with tentacles in hundreds of nooks and corners. Any attempt to play catch-up is a losing proposition. Hence you could position it so as not to directly compete with excel - in areas that are new or emerging.
I've said this in some other comment. We can't and will never be as feature full as Excel. We want to find different use cases. A super light spreadsheet with MIT license that you can use anyway you want.
If I were to go closed source, for instance, I think I loose 90% of my selling points.
One of my dreams if I were to create my own web-based spreadsheet engine would be to make worksheets much more general purpose and not stuck in tab UI like Excel. You would be able to embed them separately in the page so multiple worksheets could be viewed at the same time. Example: you might have multiple small worksheets with financial summaries where the columns are slightly different. You could also do things like include text above/below worksheets, to present the data in a document-like format.
Very cool library. I like the goal of Excel support (it truly is an incredible platform). A couple of questions:
1) Any plans for programmatic manipulation of pivot tables? Looking across the Python ecosystem, outside of xlwings (which essentially requires FFI manipulation of a running instance of Excel), nothing else makes it possible. It does look like some .NET Excel libraries support it.
2) Will there be ability to use the engine as library? Would love to use something like this through Python bindings.
Thanks for your great work! I’d love to hear your thoughts on a recent “brainstorm” a few of us had here on HN about spreadsheets. How does this resonate with you? [1][2]
Hi wsih, thanks!
There is a lot to unpack on those threads but of the top of my head:
1. Clear separation between UX/backend
Done by design in IronCalc. It is first a spreadsheet engine.
2. Multi language support, language connectivity, enhanced data types, ...
You might very well be right, but out first step is to be as close to Excel as possible. We are ~ 1 year away from being formula compatible in a reasonable way. Once we are there we can do better in different directions.
I think strict typing might be very beneficial for spreadsheets engines. Anything you can do to reduce errors and human mistakes.
I strongly believe that having a competitive spreadsheet engine fully open source might be a good first step in extending and improving Excel.
Hyperfiddle and Quadratic implement some of the items on your wishlist (richer data types, modern programming languages, working with arrays, better connectivity to data tools).
Exactly because Excel is huge it'd be nice to have such a detailed reference, grouped by type: functions, UI, scripting, built in analysis tools etc
And some features could reduce pressure re compatibility in other areas. For example, if you had some kind of wasm plugin system, then people could easily write the lacking functions in their favorite language without having to wait for the core to add such a function.
I remember trying it out, yes. I yet need to do a serious comparative analysis.
For what I can see OnlyOffice is feature complete, it's a full office solution. The sheets component is way ahead from IronCalc.
On the plus side, IronCalc is way lighter. When you go to IronCalc you download < 1Mb (compressed), it is faster and able to load larger workbooks on the web. IronCalc is an engine, meaning you don't need a UI at all to run it.
I don't think IronCalc is an alternative today to OnlyOffice. At most one day might be an alternative to the sheets component.
Yes, the compiled WASM is significantly faster. Easily by an order of magnitude. I might be completely wrong about this but I _think_ if the brilliant folks at Microsoft research in the calc intelligence group would have waited a few years they might have used wasm instead of TypeScript (https://www.microsoft.com/en-us/garage/wall-of-fame/calc-ts-...)
As for Rust, could have been C or Zig. I just needed a language that minimally compiles to wasm.
There is another reason though. IronCalc runs in the bare metal, not only in the web and needs to have bindings to languages like Python, R or Julia. I can't get that today easily with TypeScript.
One of the recurrent topics is integration with spreadsheets done by non-developers.
Imagine a spreadsheet built by the finance department of an institution. It is also maintained by them. The developer team might want to integrate this tool in their workflow. With IronCalc the can add units test or compute it a thousand times, one for each user.
I don't think developers would choose IronCalc to do any actual development. They will be forced to by other parts of their tool chain being spreadsheets.
Another way would be developers wanting to build spreadsheets with some extensions for a company or organization. Imagine needing a spreadsheet that has a built in SAT solver (like https://github.com/shnarazk/splr). That would be easily built in IronCalc.
I haven't looked into the source for your project, but am curious if you are integrating any kind of existing engine/backend (Polars is what I am thinking) into it, or if that is even possible.
Not as of now. We first want to be a first class spreadsheet engine that implements 90% of Excel functions and features like array functions, LAMBDA, ...
A goal of IronCalc is to make things like integrating Polars trivial for a developer.
What a cool project! I intend to dive in and I'm sure I'll have questions as I do. Are you active in Discord? The invite link on the bottom of ironcalc.com isn't currently valid.
The first well known spreadsheet application was called VisiCalc[0] (the killer app!). The "Iron" side is because it is written in Rust and the domain was available.
I'll take a deep dive through your repo and compare notes later this week. Congrats on the huge lift!!