comparison with other excel addin development systems

[Turhan8]

https://stackoverflow.com/questions/62911443/advice-on-which-excel-addin-development-system-to-use
This is a very helpful post for people making a choice. Could you please share your views of new add-in development approach? Would a JavaScript solution achieve same level of performance?
https://learn.microsoft.com/en-us/office/dev/add-ins/overview/office-add-ins

[govert]

I have no experience with the Javascript Office add-ins. Anecdotally it seems the development, performance and distribution are all rather painful, but it can be made to work.

If you need to support Excel on all platforms, it is the only option. If you are able to limit your target platform to Excel on Windows desktop, then the various libraries based on the C API with some COM seem preferable to me, and you'd choose one based on preferred development environment as I outlined in that post.

@Turhan8 What have you tried, and what choices are you facing, under what constraints?

[Turhan8]

Inherited an add-in library built with excel-dna in .net framework which has not been touched for a long time. Trying to decide whether to rewrite in javascript api or use the .net core version of excel-dna. Current solution has deployment issues and performance complaints. It is used from a common shared drive, takes a long time to load-up, it freezes excel for a while under load.

[govert]

If you only have to run under Windows, I suggest you fix it up as an Excel-DNA add-in.

• First step is to update to the current Excel-DNA release (1.7.0) and convert to an SDK-style project file if it isn't one. How hard that is would depend on how complicated the project is, but I suggest starting with a clean project file, and adding packages you need until it compiles again.
• Keep targeting .NET Framework, at least until the current functionality works well. .NET core will not solve any issues you are having, requires more changes from where you are now and needs the extra runtime distribution to be managed. It's certainly an option later and you can target both when you build, to identify potential issues early.
• Make a plan to not run directly from the shared drive. That kind of works but isn't great.
• Simplify distribution to a single .xll file or a few files. Or make a separate 'loader' add-in which downloads and registers the 'real' add-in. Or consider making a new WiX project from scratch based on the Excel-DNA WiX Installer.

I do provide formal support options for companies, if you think that can help you.

[keithalewis]

My anecdatum with Javascript Office add-ins is that @govert is right, as usual. It is painful to use and excruciatingly slow.
If you need to do high performance numerical computation in Excel, then is no substitute for the FP data type provided by the ancient Excel C SDK.