[strongpigeon]

I worked on the Excel Add-Ins platform at Microsoft, yes. By OM call I mean "Object Model" call, basically interacting with the Excel document.

The reason those calls are expensive on Excel Web is that you're running your add-in in the browser, so every `.sync()` call has to go all the way to the server and back in order to see any changes. If you're doing those calls in a loop, you're looking at 500ms to 2-3s latency for every call (that was back then, it might be better now). On the desktop app it's not as bad since the add-in and the Excel process are on the same machine so what you're paying is mostly serialization costs.

Happy to answer more questions, though I left MSFT in 2017 so some things might have changed since.

[com2kid]

Does Excel for Web still spin up an actual copy of Excel.exe on a machine somewhere? I heard that is how the initial version worked.

[strongpigeon]

No, as the other comment mentioned. But I’ve heard of more than a few customers running their own “server excel workflow” where they have an instances of excel.exe running a VBA macro that talks to a web server (and does some processing).

[p_ing]

Never did this. WAC was the original version (integrated with SharePoint Server). Everything was server-side.

[com2kid]

While working at MS I remember someone in the office team saying that the original version of Excel online spun to the actual Excel backend and had it output HTML instead of the usual win32 UI. Was I misinformed by chance?

[p_ing]

Excel Online was a component of WAC. It was an ASP.NET (and C++???) web application that used OAuth between SharePoint Server and Exchange Server.

So I mean yes, you viewed Excel docs through a webpage just like you do today via ODSP or OneDrive consumer. The backend is completely different in the cloud service, though.

[strongpigeon]

> WAC

Now that’s an acronym that I had forgotten about.

[Acmeon]

Yeah, that makes sense. For some reason, I was under the impression that all calculations run locally in the browser, which would have been comparable to how Excel desktop works (i.e., local calculations). Is there a reason for why the Excel calculations run on the server (e.g., excessive workload of a browser implementation, proprietary code, difficult to implement in JavaScript, cross browser compatibility issues, etc.)? Furthermore, if the reason for this architecture is (or was) limitations in JavaScript or browsers, do you find it plausible that the Excel calculations will some day be implemented in Webassembly?

Regardless, I have always preferred Excel desktop over Excel web (and other web based spreadsheet alternatives). This information makes me somewhat less interested in Excel web. Nonetheless, I find Excel Add-Ins useful, primarily because they bring the capabilities of JavaScript to Excel.

[strongpigeon]

I don’t think Excel web will ever be running the calc engine browser side, no. The only way I could see this happen would be via compiling the core to wasm, which I don’t think is worth the engineering effort.

Excel has this legacy (but extremely powerful) core with very few people left that knows all of it. It has legacy bugs preserved for compatibility reasons as whole businesses are ran on spreadsheet that break if the bug is fixed (I’m not exaggerating). The view code for xldesktop is not layered particularly well either leading to a lot of dependencies on Win32 in xlshared (at least back then).

Is it doable? I’m sure. But the benefits are probably not worth the cost.

[uticus]

> Excel has this legacy (but extremely powerful) core with very few people left that knows all of it.

Would love to hear more about this. Especially history and comparison to Lotus etc.

[strongpigeon]

So the first thing that's important to understand is that Excel is the product of another era. One where resources like memory were very constrained and compilers and optimizers weren't as good as they are today (so much so that the Excel team at one point wrote their own because MSVC sucked, but I digress)...

And so, a lot of the core code is used to that. Cell formatting data for example is super tightly packed in deeply nested unions to ensure that as little memory is used to store that info. If something only needs 3 bits, it'll only use 3 bits. The calc engine compiles all of your formulas to its own (IIRC variable-instruction-width) bytecode to make sure that huge spreadsheets can still fit in memory and calc fast.

And a lot of it still carries the same coding and naming practices that it started with in the 80s: Hungarian notation, terse variable and file names, etc. Now, IMO, Hungarian notation by itself is pretty harmless (and even maybe useful in absence of an IDE), but it seemed to encourage programmers to eschew any form of useful information from variable names, requiring you to have more context to understand "why" something is happening. Like, cool, I have a pszxoper now (pointer to zero terminated string of XOper), but why?

So the code is tight, has a lot of optimization baked in and assumes you know a lot about what's happening already.

But more importantly, a lot of "why" information also just lives in people's head. Yes, some teams would have documentation in an ungodly web of OneNote notebooks, or spread across SharePoint pages, which had the least useful search functionality I've ever witnessed, but finding anything you wanted was hard. But that didn't use to matter, since the core team had been there for a long time, so you could ask them question.

That being said, I joined MSFT in 2012 and started working on Excel closer to 2014. At that point, heavyweight like DuaneC (who wrote like 10% of Excel and I don't think I'm exaggerating) had already retired and while others people were very knowledgeable in some areas, nobody seemed to have a good cross view of the whole thing.

You have to understand that I was in the Office Extensibility team. We were building APIs for the whole thing. I had to touch the calc system, the cells and range, the formatting, tables, charts and images (the whole shared oart system was interesting), etc. Answering "How do I do X" was always a quest because you would usually:

- Find 3 different ways of achieving it

- One of them was definitely the wrong way and could make the app crash in some situations (or leak memory)

- All the people on the "blame" had left

- One of them was via the VBA layer which did some weird stuff (good ol' pbobj)

- Be grateful that this wasn't Word because their codebase was much worse

And so, a lot of the API implementation was trial and error and hunting down someone who understood the data structures. The fact that full sync and rebuild took about 6 hours (you ran a command called `ohome` and then you went home) meant that experimenting was sometimes slow (at least incremental builds were OK fast). The only lifeline back then was this tool called ReSearch2 that allowed you to search the codebase efficiently.

But the thing is, once you got thing to work, they worked really well. The core was solid and performant. Just slightly inscrutable at time and not the kind of code you're use to reading outside of Excel.

[Acmeon]

Thanks for the interesting info! Yeah, maybe Excel web will someday support local calculations via wasm, but for now I think I will stick with Excel desktop with add-ins.

[philipallstar]

Surely picking that apart is a good idea. Even if it costs a fortune, there have to be benefits.

[DaiPlusPlus]

> though I left MSFT in 2017 so some things might have changed since.

Honestly, I struggle to think about what has actually changed between Office 2013 and Office 2024 (and their Office 365 equivalents); I know the LAMBDA function was a big deal, but they made the UI objectively worse by wasting screen-space with ever-increasingly phatter non-touch UI elements; and the Python announcement was huge... before deflating like a popped party balloon when we learned how horribly compromised it was.

...but other than that, Excel remains exactly as frustrating to use for even simple tasks - like parsing a date string - today just as it was 15 years ago[1].

[1]: https://stackoverflow.com/questions/4896116/parsing-an-iso86...