I sincerely commend the enthusiasm, but working in the industry as the "excel expert", I think most outsider does not understand the "cult" aspect of Excel.
Excel works. That is it.
Trying to replace excel with anything will be percieved as replacing a calculator with some alien substance that does math. Excel is like Pencil and Pen. You can not replace it.
Excel is not software it is a tool.
I have had my fair share backlash when trying to introduce replacement and complimentary tools. To replace excel, you not only need to advocate for it's usefulness and you need to be also be liable to the complaints from excel users. If anything goes wrong no how minor with the new tool, you are the one who introduced all these mess.
So, in practice what usually happens is that, when people hit UX challenges they go to a consulting firm and commission a backoffice software to address the Excel limitations. Some business may pay for nocode but that is very rare. They go to backoffice software firm and they build a CRUD software that is now not replacing Excel but compliments it.
> Any sufficiently complicated startup or young company contains an ad hoc, informally-specified, bug-ridden, slow implementation of 10% of Excel.
Maybe we can use IronCalc for those cases?
Let's give Philip Greenspun due credit for this phrase. I'm going to guess there's at least one generation who isn't familiar with it.
Things will get real when your orgs problems/needs grow from something that was totally cool to do with spreadsheets to something requiring higher complexity, performance, resilience, testability, coordination, ... — and the point at which you cross over into the latter is not always clearly marked.
It would for example not be advisable to use Excel sheets as a replacement for a distributed database of central importance, unless your org is a lemonade stand with 3 employees.
I would also prefer maintaining a python script with written tests over maintaining an Excel file containing complex business logic, but maybe that is just personal perference.
Don't get me wrong here, Excel is amazing and we should all use it where it shines. But as with all tools we need to be aware of the fact that they heavily color the way we look at problems, as expressed by Maslows famous aphorism: "If the only tool you have is a hammer, you tend to see every problem as a nail."
Good engineers should not be blinded by their tools, but accutly aware of their limitations and know which to use when. Just like with hand tools you could probably also just hammer a nail in using a shovel or "drill" a hole using a screwdriver and Excel is very versatile in those regards: it can get you very far without being the best solution, a bit like a swiss pocket knife.
To extend your analogy too far, Excel is the 4mm allen key you get with all your Ikea furniture. It's good enough to build all the bog-standard, functional but not particularly nice furniture you need, but sure you'd rather have bespoke custom work. Sometimes you don't have or want the tools, or know how to use them and that's OK.
One can dream
Heh, where were you 6 month ago when my team was pitching some of our traders on replacing a system they'd built for balancing their strategy. It was built in excel of course, but what surprised me was the resistance to changing it at all. They all hated the thing, it was slow and crashed often, and right in the middle of the difficult part of the work too. Working with it was a terrible experience, even for people used to medium business enterprise crap. Yet they refused to consider any alternative to building some CRUD around it that would extract the worst parts.
The issue we faced was that there was no way we could contribute to this excel monster while still following the risk tolerance of our department. It's not that we're opposed to building something that is probably a bad idea, if it helps build relationships that let us build something better later. It's more that as soon as IT touches it, we get to own every legal aspect of it too. So they ended up with an external consultant that built them what was essentially an external database they could query, which was then supplied with data by some program somewhere.
It ended exactly as you say. They got a back-office firm to develop some one-off hack that alleviated the immediate problem, without replacing excel.
Relevant XKCD: https://xkcd.com/1172/
As someone that has had other software tools replaced with alternatives (think Slack replaced with Teams), the new solution almost always speeds up and fixes a lot of problems. It also invariably screws up at least one thing that I need the tool to do as a part of my job.
I love my IT colleagues, but (and I mean no offense to them or other IT folks) they don't understand that the way we use our internal tools is super flexible and doesn't adhere to an end to end process. It's how we ended up with an entire software platform that takes more manual steps, breaks in a way that we can't fix, and still requires the use of Excel to get the output into the formats that our stakeholders need. It also can't adapt quickly when we need to change things in our process.
It is a technically impressive tool that does the things they designed it to do super well. But we're like a month away from needing an Excel tool (or another piece of software) that can reliably do all the things we didn't realize relied on the "hot spacebar" from the XKCD.
Indeed, I have hardly used Excel in years. I do use Google Sheets at work, where they are used for adhoc tracking by engineering, product management, project managers, etc.
Our son who is 11, he uses Google Sheets - and I know he has used Apple Numbers in the past too. I’m not sure if he even knows what Excel is.
So if you've never used Excel, you can probably get away with an alternative. But if you already know Excel, why would you add another product for some subset of use cases?
I think this is where IronCalc like software could thrive: finding a non-complete competition to Excel, and Google Sheets that does the other part of the work better.
I am partially joking (they put it on the cloud in a way that's super useful and made collaboration remotely easier, along with other scripting inprovements), but I think it highlights that the main "benefit" to Sheets is that it's a fully featured product created by a mega-corporation that complements other tools they have to offer.
Put another way: how many companies use Microsoft for everything except Excel? How does that compare to companies that use Google Drive for everything except for spreadsheets?
A tool like this one has the upward battle of needing to be so useful, it is worth employing alongside your currently existing office software. It feels like spreadsheet software is a particularly hard arena to compete in, given the quality of the major ones you mentioned.
I proposed the CRUD solution to complement their use case but the solution was not received well. They couldn't allocate computer resources to host the solution within their infra easily. So they pushed back and asked us to develop some Excel add-on, PowerBI based dashboard or some kind of Microsoft no code I can't care enough to remember the name.
I had no experience with PowerBI at all. But had a lot of fun learning about it. Great ideas on that piece of software but ultimately it's too hard for Excel users and too finicky for real data processing other than very simple stuff.
It failed spectacularly in the end. We could never make it work reliably and the customer also skimped on the license and didn't want to add some extra features M$ft charges on the side such as power automate and some "advanced instances". Which meant the software runs have to be manually triggered on the managers machine to update the dashboards. It was nasty.
The end result is completely unmaintainable. A collection of "M" scripts inside a power bi dashboard, it pulled data from multiple spreadsheets from specific locations, joined and processed the data, and generated reports. The scripts runs on a Thinkpad so it needs to fit inside the machine constraints of memory and processing. Some of the files are manually updated so very easy to mess up the format or permissions to the point the whole thing broke.
It was a cool experience I'm never repeating
Nobody knows how long a software project will take, if it will deliver something that works or not, and if responsive support will materialize. Many if not most developers agree with this, even if they disagree as to the root causes.
One way to think of it is that it's a difference between a person and a process. A spreadsheet can be created and maintained by a person -- often the end user themselves. But since most people don't program, getting software written and maintained requires a process.
The same is true of driving a car versus flying in an airplane. When you drive, you feel like you're the person who's in control of getting yourself to your destination. When you fly, you're placing yourself at the mercy of processes that you don't control and that are not all aligned with your interests.
That is a universal issue of IT management: Any change implemented in IT systems (or anything else) will get that kind of resistance - bigger changes cause more resistance. If you change their primary tool, which they use all day and on which their jobs depend, expect a lot of resistance. The solutions:
1) Get management buy-in. They set the ceiling for acceptance - very few underlings will have more interest or make more effort than their management; if the manager dislikes it, doesn't use it, is disinterested, etc., then most others will do the same. Also, management is your support - when someone objects, they are not just objecting to you, they are objecting to their manager.
2) Get user buy-in. This is perfectly reasonable, if you think about it: Their tools, they use the tool all day, their jobs, probably they should have the biggest say. It means obtaining and utilizing their input from the start on what the tool should and should not do, etc. It may not be what you planned or expect; it may shatter your dreams; that's good - your fantasy was not aligned with reality. They provide the user end (e.g., 'don't change the keyboard UI that is in all our muscle memory and in all our documentation, and automated in macros'; 'of course you are migrating our macros, on which we depend, right?!'), you provide the technical end (e.g., 'we need a database with a spreadsheet UI and not a file-based spreadsheet').
3) Use all your development skills: test, mvp, deploy, iterate, etc.
4) Use some social intelligence: Deliver to the most interested, capable users first. Others will see them being uber-productive and want one too. Provide everyone with incredible, highly responsive support. Etc.
Every single person worked in Excel. It didn't matter how old our website was, how crappy our code was - all that matter was that we generated a CSV.
I used Excel often - I think many people underestimate how powerful Excel is and how much of finance / auditing relies upon it.
My co-workers used to joke that the world runs on Excel. That some of the most important economic documents are probably some .xlsx file named "economy-v3" that people send back and forth over email.
Data intake, preprocessing, solving performance limitations, executing automated decisions.
If it’s just a “better excel” it’s not better enough.
Google Sheets is used for all sorts of things.
Does it REPLACE Excel? No, not fully. But a lot of the time, it does.
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.
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 :)
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.
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.
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...
Excel compatibility, when fully realized, will remove the major obstacle to adoption. Given the current stronghold Excel has on the market.
Once that is achieved do you plan to offer a transition to more modern forms of calculations as vectors and arrays formula panels together with frozen sheets of raw data and output? Thus separating logic and model.
Also when your solution adoption will have grown much larger you should learn from the experiences Bavaria and CERN went through. Microsoft stronghold more often than not has nothing to do with technical prowess.
Can you elaborate on those experiences?
CERN tried to replace Office with NextCloud. It is now struggling to cope with a policy reversal under Microsoft fanboys.
Both cases were also discussed here.
The reason for Excel compatibility is twofold:
* You can use your workbooks as the are * You don't need to learn a new tool
> do you plan to offer a transition to more modern forms of calculations as vectors and arrays formula panels together with frozen sheets of raw data and output?
So far, nothing beyond Excel's compatibility
https://github.com/ironcalc/ironcalc.github.io/issues/14
As I said somewhere else I had really bad marketing skills. Maybe I should talk to someone who really knows what they are doing :)
The catchphrase was decided in 5 seconds when I was sending a proposal to the nlNet and stuck.
Thanks for the feedback!
Democracy is not the best analogy, free software projects have BDFLs. The difference is more indirect, in democracies citizens have rights and freedoms. In non-democracies typically less so.
Calling it democratic is is like calling cancer a completely natural phenomenon. It's true, but it's also completely beside the point
https://www.collaboraonline.com/code
https://hub.docker.com/r/collabora/code
(it's FOSS, the language about "home use" is there to scare large companies into buying commercial versions with support contracts.)
> Empowering SaaS Developers: Hundreds, if not thousands, of companies have implemented half-baked spreadsheets in their systems. IronCalc aims to provide these businesses with a superior, open-source alternative that enhances their SaaS applications.
I am currently creating SAAS and the idea of implementing LibreOffice on top of my offering just not gonna work.
MIT or Apache 2 (player's choice) if anyone else has grown deeply suspicious about any "open source" HN headlines of late
Thank you for posting!
Thanks for making this in the first place! I saw IronCalc in the list of projects supported by NLnet and it grabbed my attention.
By the way, if You don't mind me asking, how'd Tuta end up sponsoring IronCalc? It seems that lately they and Proton have been trying to expand their business away from just email. The fact that Tuta is interested in IronCalc makes me think they want to have an office-like offering.
Of course there's a lot missing, but what's interesting is what you've reached for and could not find.
I hope the backend engine can be used standalone embedded in other apps.
I've been looking out for projects like this over the years and I'm glad to see that this one takes Excel compatibility seriously! Also love the choice of Rust and WASM!
For me Dynamic Array support is a blocker and I can't play with it until you've got that. Very glad to see that's your top priority though[1]! That and everything in the Logical, Lookup and Reference, and Information sections (in that order). That covers probably over 95% of my work and I spend most of my time in Excel.
People could submit those and you'd get real usage stats of what functions people actually use in real world workbooks rather than guessing.
Users could also then use this to run a compatibility check to see if they could move over to your engine or not.
If you don't mind compiling yourself there is a somewhat rough tool tat does that:
https://github.com/ironcalc/IronCalc/blob/main/xlsx/src/bin/...
It will tell you exactly what cells evaluate differently.
I will also add mentions to unsupported formulas and features
https://github.com/logisky/LogiSheets
https://github.com/natefduncan/excel-emulator
https://github.com/jiradaherbst/XLFormula-Engine
I guess I have some reading to do!
What is the last one?
https://learn.microsoft.com/en-us/office/vba/excel/concepts/...
Not yet, there is heavy research in that direction. I will write on this soo-ish
> Do you take volatile functions into account?
Yes, for instance RANDBETWEEN and NOW are implemented. Things like `IF(RANDBTWEEN(1, 500)> 200,A1, A2)` work fine
Thnaks
- I think you should add a CHANGELOG.md, so people can see progress/features evolve (https://keepachangelog.com/en/1.1.0/)
- I think you should report the rev somewhere. I can’t tell what the “current rev” is in GitHub or in the running demo.
- The roadmap says what’s coming in 0.5 (October 2024), but it’s not clear whether 0.5 is “done” or if that’s what’s running on the demo site today.
IronCalc would be awesome as an “embedded viewer” for data. I’m currently implementing an internal web app where I’d love to provide “monitoring” by just dumping a whole lot of transactional data from the db into a “live” IronCalc spreadsheet as a “view” tool that you could also do some data exploration in.
The 0.5 roadmap says “API to set and read values from cells” but it’s not clear to me whether it would be possible or not to embed it today and inject data at “start” time from JS. The scope of the current docs is “using it as a spreadsheet” but they don’t cover “how to embed it / integrate it”.
Love love LOVE! Would embed it TODAY as a data viewer could. :) Nice work! I am watching with bated breath!
I will be working in coming weeks to make it easy to embed and use at the time being you would need a bit of plumbing and programming.
You can use IronCalc as an "embedded viewer" but that is not were it shines. If you are not using Excel formulas there are many other lighter and simpler alternatives out there.
There is currently a well defined API to set/read values from cells but you are right is not yet documented (on it's way). I is possible to have data from the start.
I will add a CHANGELOG as soon as possible. I am still recovering from the huge impact this thread had.
Thanks again for the kind words!
I'm excited to follow along with your progress, and to embed it into something fun when it's ready for embedding :)
Thanks for adding the changelog today! That will make it super easy for everyone to follow the progress.
Cheers!
I currently use univerjs to power the open source sql spreadsheet component I work on (https://github.com/sqlpage/sqlpage-spreadsheet/). My experience with it has been that it's very powerful, but quite difficult to use due to the boilerplate involved, the lacking documentation, and the fact that it seems to be developed mainly for the Chinese market.
I think at the time being you should stick to univerjs as it is a finalized product. Once we reach version 1.0, IronCalc should be easier to deal with and you cold consider using one or the other.
Admins use the ironcalc UI to create their formulas. Is there a way to get those formulas to a backend and run the calcs on the server itself (separate from the user's browser) to get results based on input from other sources?
The UI half looks great so far. I have a colleague I was going to recommend this to, but they more need the 'run the formulas on the server' part more than anything else. They've got some custom Rust stuff running already, but having admins come up with their advanced formulas, then translating that to server code - that takes the time. It seems they may be able to use this to have this handle both ends of the workload, without the translation layer.
Is that something supported, or even feasible?
Thanks!
I can see this becoming transformative and superseding Excel, which is a bold claim to make. But this is compliant (with Excel), performant, extensible, free, and in-browser. This could easily become almost an emacs-level editor.
Think of the interfaces that could be built to this in this?
I'll be sharing this with every student I know.
And the name is a winner.
I think this one is fairly clear. It’s because it’s a massive amount of work with a not necessarily large payoff for yourself?
I think some of these basically get made when someone gets too annoyed something similar doesn’t exist.
This is out of date, and not a priority ATM, but we will have a TUI for it:
I'm excited to see more players in this space though, all the standards are open and there are decent libraries with decent licenses that exist. A lightweight LibreOffice alternative would be neat and something truly open source and embeddable (MIT) is great.
Uncaught RuntimeError: unreachable executed pasteCsvText assets/index-BxqQcmeI.js:40
I just added csv copy/paste, most likely an error there. We don't support arbitrary precision arithmetic but I would like to.
Interesting to see all those different takes on the spreadsheet metaphor.
I think the take is a tad different form pysheets. Cool tool though!
The docs currently focus on the engine part but I’m more interested in the integrations (for example, with Java, Angular, Vue etc).
I’m currently on mobile but I’ll have to take a look at your React example to see if I can write a working Angular or Vue example.
I couldn't find docs on how to use it in languages other than rust. Perhaps via IPC?
The React front-end communicates with wasm compiled from Rust.
Java bindings are planed but not in the next ~6 months. A client/serve architecture (like libreoffice does) with IPC or sockets might be a good idea for languages that we don't provide bindings to. also not planned for the next 6 months
Just to clarify, this means that the entire engine is compiled into wasm and runs inside the browser? There is no server component?
Right now you can't just `npm install ironcalc`, but hopefully that will be in place in a month from now.
Consider making formula engine standalone as it might be used in other contexts, like Markdown or html tables.
> The democratization of spreadsheets > Empowering Everyone with Advanced, Open-Source Spreadsheet Solutions
It's a really fast spreadsheet engine that runs entirely in the browser and is fully open source. That's all the sales pitch I'd need, but I'm a developer...
So, serious question: who is this kind of marketing targeting?
This project targets both end spreadsheet users and developers. In its first an engine (a Rust crate) then a full fledged product.
FWIW, I'm over them moon this project is getting some traction :)
It doesn't seem to say "in browser" - so I'm wondering if it's Windows or Mac or ...?
Since it is in-browser there's then no detail on what the scope is - where are the spreadsheets stored? How are they shared? Do I host it on my server? Are they stored on your server ? Can I embed it on an existing page? Can I update cells via JavaScript? Or websockets?
And so on.
Some of the above is inferable from the comments here, but not all.
Congratulations on a cool project - but you may want to "set the scene " as it were for prospective users.
