Choose a Surface
Formulon exposes the same core through several packaging surfaces.
Same engine, different host contracts
Surface choice affects packaging, memory lifetime, deployment, and error reporting. It should not change spreadsheet semantics.
| Surface | Best for | Package |
|---|---|---|
| WebAssembly | Browser apps, workers, Node services | @libraz/formulon |
| Native Node | Node services that can build or stage a .node addon | packages/npm-native |
| Python | Notebooks, batch jobs, data pipelines | formulon |
| CLI | Shell scripts, CI checks, workbook inspection | GitHub Releases |
| C ABI | Host applications and custom bindings | repository build |
Pick the highest-level surface that fits your deployment. Drop to the C ABI only when you need a binding that is not already packaged.
Decision guide
Where does it run?
Browser→ WASM (@libraz/formulon)
Server / job→ next: which language?
Shell / CI→ CLI (GitHub Releases)
Agent / LLM→ MCP server (formulon-mcp)
Server / job: which language?
Python→ Python (formulon)
Node→ next: native install OK?
Other→ C ABI (repository build)
Node: native install OK?
Yes→ Native Node (packages/npm-native)
No→ WASM (@libraz/formulon)
| Requirement | Recommended surface |
|---|---|
| Browser upload, local preview, worker-side recalculation | WASM |
| Node service with no native install assumptions | WASM |
| Node service with large workbooks and native deployment | Native Node |
| Batch job or notebook | Python |
| CI workbook snapshots | CLI |
| New language binding | C ABI |
All surfaces share the same engine. Differences should be about packaging, lifetime management, and host error reporting, not formula semantics.