Skip to content

Formualizer vs HyperFormula: Which Spreadsheet Engine Should I Choose?

I hit a wall when evaluating spreadsheet engines for a commercial financial application. Both Formualizer and HyperFormula looked solid on paper - they both parse Excel formulas, handle dependency graphs, and support hundreds of functions. But when I dug into the license implications, the choice became clear. Let me save you the research pain.

TL;DR

Choose Formualizer if:

  • You need permissive MIT/Apache-2.0 license for commercial use
  • Your backend is Rust or you need WASM for browser performance
  • Performance is critical for large datasets
  • You want native Rust performance without JavaScript overhead

Choose HyperFormula if:

  • Your stack is JavaScript/TypeScript
  • You’re already using Handsontable
  • You need ~400 functions (vs 320+ in Formualizer)
  • Your project is open-source (GPL-compatible)

The license is the elephant in the room. If you’re building proprietary software, Formualizer’s MIT/Apache-2.0 has no strings attached. HyperFormula’s GPLv3 requires your entire application to be open-source OR you must purchase a commercial license.

License: The Real Decision Factor

I made the mistake of assuming both were “open source” and therefore equivalent. They’re not.

Formualizer: MIT / Apache-2.0

MIT License - Use freely:
- Commercial products
- Proprietary software
- Internal tools
- Client deliverables
- No attribution required
- No license keys
- No fees ever

HyperFormula: GPLv3 (or pay)

GPLv3 License - Complex rules:
- Free ONLY if your app is also open-source
- Proprietary use requires commercial license
- Any modifications must be shared
- "Viral" license affects your code
- License key REQUIRED in config

Real-World Scenarios

ScenarioFormualizerHyperFormula
Open-source projectFreeFree
Proprietary SaaSFreeMust buy license
Internal enterprise toolFreeMust buy license
Startup MVPFreeFuture cost
Financial/banking appNo compliance issuesAudit required

The hidden costs of HyperFormula aren’t just the license fee - it’s the ongoing budget allocation, vendor lock-in, and compliance overhead. With Formualizer, there’s zero license management.

Architecture: Rust vs JavaScript

This isn’t just about language preference - it’s about runtime characteristics.

Formualizer (Rust)

  • Core: Pure Rust with zero runtime overhead
  • Bindings: Python (PyO3), WASM for browser/Node.js
  • Memory: Rust’s ownership model - no GC pauses
  • Deployment: Native binary or WASM module

HyperFormula (JavaScript)

  • Core: TypeScript/JavaScript
  • Runtime: Node.js or browser V8 engine
  • Memory: JavaScript garbage collection
  • Deployment: npm package

Performance Characteristics

AspectFormualizerHyperFormula
Startup Time~1ms~10ms
Calculation SpeedNativeV8-optimized
Memory (100K cells)~20MB~80MB
Large Dataset HandlingExcellentGood (JS heap limit)
WASM Bundle~2MBN/A

I tested both with 10,000 rows and 100 formulas. Formualizer finished initial calculation in ~50ms while HyperFormula took ~200ms. The gap narrows for small datasets, but if you’re processing financial calculations at scale, the difference matters.

Feature Matrix

FeatureFormualizerHyperFormula
Parse/Evaluate FormulasYesYes
Read Excel FilesYesNo
Write Excel FilesYesNo
Functions320+~400
Dependency GraphYes (incremental)Yes (incremental)
Undo/RedoYesYes
Dynamic ArraysYesYes
Named RangesYesYes
Cross-Sheet ReferencesYesYes

HyperFormula wins on function count (~400 vs 320+), especially in statistical and engineering functions. But Formualizer brings something unique: Excel file reading/writing and Apache Arrow integration for efficient data pipelines.

Ecosystem Integration

Formualizer:

Rust App --> Native lib
Python App --> PyPI (PyO3)
Browser --> WASM npm package
Node.js --> WASM npm package

HyperFormula:

JS/TS App --> npm import
Handsontable --> Native integration
React/Vue/Angular --> Wrappers available

Code Comparison

Here’s what the API looks like side-by-side.

Formualizer (Rust)

use formualizer_workbook::Workbook;
use formualizer_common::LiteralValue;
let mut wb = Workbook::new();
wb.add_sheet("Sheet1")?;
wb.set_value("Sheet1", 1, 1, LiteralValue::Number(1000.0))?;
wb.set_formula("Sheet1", 1, 2, "=A1*1.1")?;
let result = wb.evaluate_cell("Sheet1", 1, 2)?;
println!("Result: {}", result); // 1100.0

HyperFormula (JavaScript)

import { HyperFormula } from 'hyperformula';
const hf = HyperFormula.buildEmpty({
licenseKey: 'gpl-v3' // Required!
});
hf.setCellContents({ sheetId: 0, row: 0, col: 0 }, [[1000]]);
hf.setCellContents({ sheetId: 0, row: 0, col: 1 }, [['=A1*1.1']]);
const result = hf.getCellValue({ sheetId: 0, row: 0, col: 1 });
console.log('Result:', result); // 1100.0

Notice the license key requirement? That’s your first sign that commercial use isn’t straightforward.

Decision Framework

Here’s the decision tree I wish I had:

Need spreadsheet engine?
|
v
Proprietary/commercial app?
|
+-- YES --> Want to pay for license?
| |
| +-- NO --> Formualizer
| |
| +-- YES --> Continue
|
+-- NO --> Continue
|
v
Primary language?
+-- Rust --> Formualizer
+-- Python --> Formualizer
+-- JavaScript --> Continue
|
v
Performance critical? (>100K calcs/sec)
+-- YES --> Formualizer
+-- NO --> Continue
|
v
Need >320 functions?
+-- YES --> HyperFormula
+-- NO --> Continue
|
v
Using Handsontable?
+-- YES --> HyperFormula
+-- NO --> Either works

Use Case Recommendations

Financial Services Backend: Formualizer - permissive license, Rust performance, no vendor lock-in.

SaaS Spreadsheet App: Formualizer (WASM) - no license cost for commercial use, browser performance.

Data Pipeline ETL: Formualizer - Rust performance, Python bindings, Apache Arrow integration.

React Dashboard: HyperFormula or Formualizer WASM - JavaScript ecosystem integration.

Internal Tool: Either - license matters less, consider team skills.

Migration: If You’re Already on HyperFormula

If you’re facing license renewal costs, here’s the migration path:

  1. Audit your HyperFormula usage - check function coverage
  2. Test critical formulas with Formualizer (320+ functions likely cover 95%+)
  3. Migrate workbook structure
  4. Update API calls (similar patterns)
  5. Remove license key configuration
  6. Deploy and monitor

The API similarity makes migration straightforward. The hard part is the function audit - some edge statistical functions might need workarounds.

Community and Support

Formualizer:

  • Growing Rust community
  • GitHub Issues for support
  • Documentation in development
  • Commercial support available

HyperFormula:

  • Large JavaScript/Handsontable community
  • Comprehensive docs site
  • Commercial support through Handsontable

HyperFormula has the maturity edge. Formualizer is newer but moving fast.

The Bottom Line

For commercial projects, Formualizer wins on license alone. The performance advantages of Rust are real but secondary. When you’re building something you’re going to sell, explaining GPL compliance to legal is a conversation you don’t want to have.

Choose Formualizer if:

  • You’re building something you’re going to sell
  • Performance matters for your workload
  • You want zero license concerns

Choose HyperFormula if:

  • You’re already deep in the JavaScript ecosystem
  • Using Handsontable makes sense for your UI
  • Your project is genuinely open-source

I went with Formualizer for my commercial project. Zero license headaches, solid performance, and the Rust ecosystem keeps growing.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments