4 ms·

Oh wow, I used to work on Excel Add-Ins about 10 years ago. Even got a patent for it. I'd be curious to see how they implemented the calls. We came up with wha

Oh wow, I used to work on Excel Add-Ins about 10 years ago. Even got a patent for it. I'd be curious to see how they implemented the calls. We came up with what I still consider a pretty cool batch-rpc mechanism under the hood so that you wouldn't have to cross the process boundary on every OM calls (which is especially costly on Excel Web). I remember fighting so hard to have it be called `context.sync()` instead of `context.executeAsync()`... That being said, done poorly it can be slow as the round-trip time on web can be on the order of seconds (at least back then).

Acmeon 6mo ago
Do you mean that you worked on the Excel Add-Ins platform in Excel (and not on a specific Add-In)? If you were working on the platform itself, then I would be interested in hearing your more detailed thoughts on the matters you mentioned (especially since I am developing an open source Excel Add-In Webcellar (https://github.com/Acmeon/Webcellar https://github.com/Acmeon/Webcellar)). What do you mean with a "OM" call? And why are they especially costly on Excel web (currently my add-in is only developed for desktop Excel, but I might consider adding support for Excel web in the future)? In any case, `context.sync()` is much better than `context.executeAsync()`.
- strongpigeon 6mo ago
  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.
  - Acmeon 6mo ago
    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 6mo ago
      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.
      - Acmeon 6mo ago
        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.
      - uticus 6mo ago
        > 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.

Acmeon 6mo ago

Do you mean that you worked on the Excel Add-Ins platform in Excel (and not on a specific Add-In)? If you were working on the platform itself, then I would be interested in hearing your more detailed thoughts on the matters you mentioned (especially since I am developing an open source Excel Add-In Webcellar (https://github.com/Acmeon/Webcellar https://github.com/Acmeon/Webcellar)). What do you mean with a "OM" call? And why are they especially costly on Excel web (currently my add-in is only developed for desktop Excel, but I might consider adding support for Excel web in the future)? In any case, `context.sync()` is much better than `context.executeAsync()`.

strongpigeon 6mo ago
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.
- Acmeon 6mo ago
  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 6mo ago
    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.
    - Acmeon 6mo ago
      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.
    - uticus 6mo ago
      > 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.