Most searches for a JavaScript spreadsheet library mix four different jobs:
Those are not the same product. A polished grid can still be the wrong backend primitive. A great file library can still leave a service unable to recalculate formulas before Excel opens the file. A formula-function package can be useful without giving you a workbook document, dependency graph, persistence, or post-write readback.
@bilig/headless fits the fourth job. It is a TypeScript WorkPaper runtime for
Node.js services, workbook automation, and coding-agent tools. It is not a
visual spreadsheet grid, and it is not a finished Excel clone.
Research date: 2026-05-13.
If people need to edit cells in the browser, start with a grid or spreadsheet component such as Handsontable, JSpreadsheet, AG Grid, or another UI-first library.
If the workbook file is the product, start with SheetJS, ExcelJS, or another XLSX-focused toolkit.
If formula calculation is the product, start with HyperFormula when mature spreadsheet-engine coverage matters most, or Formula.js when you only need Excel-like functions as direct JavaScript calls.
If a Node.js service or coding agent needs to create a workbook, change inputs,
read calculated cells, persist state, restore it, and prove the values after the
edit, try @bilig/headless.
| Job | Better first tool | Why |
|---|---|---|
| Let people edit a spreadsheet-like table in React, Vue, Angular, or plain JavaScript | A browser data grid or spreadsheet component | The main problem is UI behavior: rendering, keyboard navigation, copy/paste, selection, validation, and editing. |
| Import, export, or transform spreadsheet files | SheetJS or ExcelJS-style tooling | The main problem is file interchange, workbook structure, styles, tables, or generated reports. |
| Evaluate many spreadsheet formulas inside JavaScript | HyperFormula | The main problem is calculation-engine maturity and formula coverage. |
| Call individual Excel-style functions from code | Formula.js | The main problem is function calls, not a workbook document. |
| Put formula-backed workbook state behind an API, queue worker, or agent tool | @bilig/headless |
The main problem is a mutable workbook object with formula readback, persistence, restore, and verifiable edits. |
The decision gets easier when you name the user. If the user is a person at a browser grid, use a grid. If the user is Excel, use file tooling. If the user is another backend process or a coding agent, use a headless workbook runtime.
@bilig/headless gives a Node process a WorkPaper object. A WorkPaper has
sheets, cells, formulas, computed values, structural operations, JSON
persistence, and restore paths. That makes it useful for service code such as:
The important habit is readback. Do not stop at “the service wrote a formula.” Read the calculated value from the WorkPaper, persist the document, restore it, and read it again.
Start from an empty directory:
mkdir bilig-javascript-spreadsheet-eval
cd bilig-javascript-spreadsheet-eval
npm init -y
npm pkg set type=module
npm install @bilig/headless
Then run the npm-only smoke test:
The maintained repo example is the next step:
git clone https://github.com/proompteng/bilig.git
cd bilig/examples/headless-workpaper
npm install
npm start
npm run agent:verify
npm run agent:verify changes workbook inputs, checks dependent formula
readback, serializes the document, restores it, and verifies that formulas and
values survived the round trip.
Do not choose @bilig/headless just because the phrase “spreadsheet library”
appears in a search result.
Use a browser grid when the product is human editing. Use XLSX tooling when the product is a file. Use HyperFormula when broad formula compatibility is the deciding constraint today. Use Formula.js when isolated function calls are enough.
Use @bilig/headless when the product needs a workbook-shaped backend object
that can be changed, recalculated, saved, restored, and inspected by code.