Hey! This is my project!
Amazed to see this here.
I'll try to answer questions people might have
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.
Wish you guys the best.
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.
https://plausible.io/ironcalc.com
I think more than one folk in HN might be interested. All traffic is because of this post. I had no visitors as of today. This was work in progress :)
Only 13.4% of HN readers use Firefox. For shame. But seriously, it's interesting that safari is top by quite a margin.
I would imagine both solution being much more popular on Desktop / Laptop. Hence 75% of all views counted are actually from Smartphones.
I'm not sure how unusual I am, but would be interested in knowing:)
https://bossanova.uk/jspreadsheet/v4/ which is the open source version of
Serious question. I base a lot of work off the open source jspreadsheet. Curious about yours.
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.
trivia: js based https://ethercalc.net/ is in turn is derived from https://github.com/DanBricklin/socialcalc written by the spreadsheet inventor dan bricklin
If I were to go closed source, for instance, I think I loose 90% of my selling points.
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.
As soon as we possibly can
2) Will there be ability to use the engine as library? Would love to use something like this through Python bindings.
That is in place already! It is an MVP, so I haven't published all packages for all architectures but you can compile it from source:
https://github.com/ironcalc/IronCalc/tree/main/bindings/pyth...
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.
Let's see!
Do you have a detailed list tracking compatibility with Excel?
Do you have any great ideas where you can surpass it (in one way you can use yours without UI)?
There is not a detailed tracking of all Excel features. But we track:
1. Function implementations: https://github.com/ironcalc/IronCalc/labels/Functions 2. Dynamic arrays, defined names, pivot tables, ...
Excel is huge we only aim at implementing a subset.
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.
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.
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.
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.
Not sure if any of those ideas convinces you :)
https://www.nhatcher.com/post/a-rustic-invitation-to-parsing...
The implementation in IronCalc follows that.
A goal of IronCalc is to make things like integrating Polars trivial for a developer.
I don't necessarily respond every day immediately, but I am active.
You've added xlsx format to export. Is it legally allowed?
https://ecma-international.org/publications-and-standards/st...