xllify

Choosing the right Excel add-in approach

There are plenty of good ways to extend Excel. This page tries to give you an honest take on which tool to pick for your situation.

Approach Setup
complexity		 Performance Cross-
platform		 Distribution
ease		 Code
reusability		 Learning
curve		 Cost AI
assistance
xllify Simple Excellent Yes Easy High Gentle $ Strong
VBA Simple Moderate Mac / Win Workbook only Low Gentle Free Moderate
LAMBDA Simple Moderate Yes Workbook only Moderate Moderate Free Strong
Excel-DNA Moderate Excellent No Moderate High Moderate Free Moderate
PyXLL Moderate Moderate No Workbook only High Gentle $$ Strong
Office.js Complex Slow Yes Moderate High Moderate Free Strong
Python in Excel Moderate Network call Partial Workbook only Moderate Gentle $$$ Strong
C API / XLL Complex Excellent No Moderate Moderate Steep Free Limited

Detailed comparison

Best for: Automating Office tasks, quick one-off scripts, legacy workbooks that already rely on VBA. If you know it and it does the job, there's no reason to change.

Key tradeoffs vs xllify
  • Code lives in the workbook, hard to version or share as a library
  • Macro security warnings put users off and require policy changes in corporate environments
  • No real distribution story beyond "share the file"
  • macOS support is deteriorating with each release
  • No cross-platform runtime, no web support
Where xllify wins
  • Code in files, versioned in git, tested before deploy
  • Single installable file, no macros, no warnings
  • Works on Windows, Mac, and the web from one build
Use VBA instead when: You already have VBA and it works. You're automating Office more broadly (not just custom functions). You're in a locked-down environment where installing an XLL isn't allowed.

Best for: Encapsulating formula logic you'd otherwise repeat across cells. Great for self-contained calculations that don't need external data or complex control flow.

Key tradeoffs vs xllify
  • Logic stays in the workbook, no git, no testing outside Excel
  • Can't call external APIs, query databases, or do I/O
  • Sharing across workbooks is manual copy-paste
  • Complex recursive LAMBDAs are hard to read and debug
  • Requires a recent Microsoft 365 version
Where xllify wins
  • Multi-threaded recalculation at native speed
  • Cross-platform from the same source
  • Distributable as a self-contained file independent of the workbook
  • Testable locally before deploy
Use LAMBDA instead when: You want zero setup, the logic is purely formula-based, and distribution outside the workbook isn't needed.

Best for: Teams already writing C# or F#, who need maximum performance or deep Excel integration (menus, ribbon, dialogs). Good RTD and async support via observables. Great documentation and responsive support on Google Groups. The best-in-class option for .NET developers on Windows. It really is excellent and highly recommended.

Key tradeoffs vs xllify
  • Windows-only, no Mac or web support
  • .NET toolchain required (SDK, NuGet, build config)
  • No built-in AI assistant or high-level abstraction
Where xllify wins
  • Cross-platform from the same source
  • No toolchain to install, remote builds available
  • AI assistant purpose-built for the task
Use Excel-DNA instead when: You're a .NET team, you want the absolute maximum Excel integration, you need ribbon UI or custom dialogs, or you want to stay in a language you already know well.

Best for: Data-science and quant teams already living in pandas, numpy, and scipy. If your logic is already in Python and you need it in Excel, PyXLL is the most direct path. It's mature, well-regarded, simple to use, and highly recommended, with good support for RTD and async, and great documentation.

Key tradeoffs vs xllify
  • Windows-only
  • End users need Python installed, deployment is complex
  • Commercial licence required per developer
  • Python interpreter must be installed and loaded on the end user's machine
Where xllify wins
  • Cross-platform, same add-in on Mac and web
  • No end-user install required (XLL is self-contained)
  • Free tier available
Use PyXLL instead when: Your logic is deeply tied to the Python data science stack (pandas, sklearn, matplotlib). You're already on Python, your team is on Windows, and PyXLL's richer feature set (task panes, ribbon) matters to you.

Best for: When you need rich UI (task panes, ribbon customisation, dialog boxes) or when you're building something that goes beyond custom functions. The officially supported direction from Microsoft.

Key tradeoffs vs xllify
  • Custom functions run in a JavaScript sandbox, not in-process, slower for computation-heavy work; notably poor performance on macOS
  • Requires hosting a web server and distributing a manifest
  • Node.js project setup, manifest XML, SSL certificate for local dev
  • Distribution typically via domain policy or the Office Store, deeply tied to the Microsoft ecosystem
Where xllify wins
  • For pure custom functions: much simpler setup
  • Native XLL performance on Windows
  • Single-file XLL distribution, no hosting required
Use Office.js instead when: You need task panes, ribbon buttons, dialog boxes, or any UI beyond cell functions. You're building something that needs to work everywhere Microsoft supports, long term. xllify uses Office.js under the hood for its web add-in output, so you can use Office.js features directly if you need to.

Best for: Exploratory data analysis, visualisation, and statistics directly in a workbook without leaving Excel. The matplotlib and seaborn integration is genuinely useful for analysts.

Key tradeoffs vs xllify
  • Code runs on Microsoft's servers, every recalculation is a network round trip
  • Not deterministic (Microsoft document it as potentially non-deterministic)
  • Requires a Microsoft 365 plan that includes the feature (not universally available)
  • No way to package or distribute the result as a standalone add-in
  • Per-session usage limits
Where xllify wins
  • Runs locally, no internet connection required after install
  • Deterministic by design
  • Distributable as a standalone add-in
  • No per-use cost or usage limits
Use Python in Excel instead when: You need visualisation in the workbook (matplotlib/seaborn), your team already has the Microsoft 365 plan, and you're doing exploratory analysis rather than building something to deploy.

Best for: xllify's own runtime is built on this. If you need absolute control over every byte, non-standard Excel integration not supported anywhere else, or you're maintaining a legacy XLL, this is the level to work at.

Key tradeoffs vs xllify
  • C/C++ only, no higher-level language
  • Manual XLOPER memory management, type conversion, and error handling
  • Windows and MSVC only, no cross-platform build
  • No significant API changes since Excel 2013, documentation is sparse
Where xllify wins
  • Write in Luau or describe in plain English instead of C/C++
  • All XLOPER handling, registration, and memory management handled automatically
  • Remote builds, no MSVC required
Use C API instead when: You need raw native performance or direct integration with existing C libraries, and you're fine dealing with the complexity yourself.

Spot anything wrong? Let us know.