Algebrite is a JavaScript CAS that shows its work in a cons-list representation

Every operation returns a cons object, not a string or a number

Algebrite is a JavaScript, and now TypeScript, library for symbolic mathematics, designed to be comprehensible and easily extensible. The interface is small, and the README shows the whole of it:

var Algebrite = require('algebrite')

Algebrite.run('x + x') // => "2 x"

Algebrite.factor('10!').toString() // => "2^8 3^4 5^2 7"

Algebrite.eval('integral(x^2)').toString() // => "1/3 x^3"

// composing...
Algebrite.integral(Algebrite.eval('x')).toString() // => "1/2 x^2"

Two details in that snippet are the whole API philosophy. First, strings are automatically parsed as expressions, numbers are converted into the appropriate representation, and the internal cons objects are returned. The return value is a cons list, a linked structure rather than a string, so you can compose calls directly. The integral of the result of eval is the second line of output.

Second, the cons objects carry a toString method that converts them into a pretty-print notation. That is why the examples call .toString() explicitly. The library does not force a single output format, it offers a readable one. For a system meant to be comprehensible, that is a deliberate choice, and it is also the main thing to check if you plan to consume results programmatically rather than display them.

The feature list is broad, and each item is a subsystem to maintain

The README lists what Algebrite supports: arbitrary-precision arithmetic, complex quantities, simplification, expansion, substitution, symbolic and numeric roots, units of measurement, matrices, derivatives and gradients, tensors, integrals, multi-integrals, computing integrals and much more.

That last phrase, much more, is doing some work, because the list covers most of what a textbook computer algebra course covers. Units of measurement and tensors are the two entries that stand out as beyond the usual scope of a small library, and both pull in significant machinery.

The scope has a direct consequence for anyone considering the project. A CAS is not a small library in the way a date formatting helper is. Every one of those areas is a set of algorithms with edge cases, and each is a candidate for divergence from textbook expectations. The feature list tells you the surface area exists; it does not tell you how often each area is exercised, and the README does not claim comprehensive coverage.

The exact arithmetic is the part that is least optional. The only runtime dependencies are big-integer and the Node type definitions, so arbitrary-precision integers come from big-integer and everything else is implemented in the project itself.

The build is Bazel, and npm install alone gives you nothing

This is the practical surprise for anyone arriving from npm. The build instructions have two parts, and neither is a plain npm run build of a TypeScript project.

For a build that runs the tests, npm has to be installed, then the dependencies are installed, and then the Bazel launcher builds the project:

npm install
bazelisk build algebrite

bazelisk is the launcher for the Bazel build system, and the README says the Bazel build system tends to be smart and cache things. A thorough clean is bazelisk clean followed by removing the dist directory contents.

The so-called npm build, which produces builds for npm and for the browser, is npm install, then bazelisk build npm, then opening index.html. The repository has a BUILD.bazel, a WORKSPACE.bazel, a .bazelrc and a .bazelversion, plus a cloudbuild.yaml, so the Bazel setup is not incidental.

The test commands are the same shape. The full test run is bazelisk test :all, and when caches get in the way the README gives bazelisk test :all --cache_test_results=no. The package.json scripts mirror this as bazel build //... and bazel test //..., so the package manager is a thin wrapper rather than the build system itself.

The output format is a design decision, and a whole class of bug follows from it

The pretty-print notation is where most of Algebrite's character lives. Algebrite.run('x + x') returns the string "2 x", and Algebrite.factor('10!') prints as "2^8 3^4 5^2 7" rather than as a product of symbols. That is not LaTeX and not MathML, and it is not a canonical algebraic form. It is a compact linear rendering of the internal cons structure.

The trade-off is real. A library that returns a readable linear form is far easier to debug, to log, and to show a user than one that returns an opaque tree you have to render yourself. The cost is that parsing the result back is a separate problem, and that you cannot assume the string form is a stable contract. If you are building a LaTeX renderer or a step-by-step explanation on top, you are working from the cons objects rather than from the printed text, and the README does not document a stable public API for that beyond toString.

The cons representation itself is inherited, and that is the other half of the design. Algebrite starts as an adaptation of the EigenMath CAS by George Weigt, and the README also points at SMIB by Philippe Billet as another fork of EigenMath worth looking at. The adaptation is why the project can be comprehensible: it is a port of an existing design rather than a fresh architecture.

Two other JavaScript CAS exist, and SymPy is the one to weigh

The README names the alternatives, which is useful, and it names them with a description of scope rather than a judgement.

On the JavaScript side there is javascript-cas by Anthony Foster, supporting differentiation, complex numbers, sums, vectors with dot products, cross products, gradient and curl among them, and Coffeequate by Matthew Alger, supporting quadratic and linear equations, simplification of most algebraic expressions, uncertainty propagation, substitutions, variables, constants and symbolic constants. There is also Algebra.js by Nicole White, which among other things can build and solve equations through a chainable API.

The list is differentiated by emphasis. Coffeequate is a solver rather than a general manipulator, and its uncertainty propagation feature is the kind of niche that a general CAS does not prioritise. Algebra.js goes the other way, toward a chainable API rather than a text parser, which is a different programming model for the same class of problem. javascript-cas sits in the middle with an emphasis on vector calculus.

The alternative the README points at most directly is SymPy, the Python computer algebra system. The difference in approach is the runtime and the ecosystem. SymPy is a Python library, while Algebrite is a TypeScript library that runs in the browser without a Python toolchain. If your work already lives in Python, that is the comparison that matters, and the choice is usually made for you.

The maintenance signal is the thing to check before you depend on it

The licence is MIT, and the author is Davide Della Casa, with the homepage at algebrite.org where the examples and manual live. The package is published to npm as algebrite, and the package.json points the main entry at dist/algebrite.js, the module entry at dist/index.js, and the browser bundle at dist/algebrite.bundle-for-browser-min.js.

The dates are less comfortable. The last push to the repository was on 2026-05-12, so the code is being touched, but the most recent GitHub release is v1.4.0 from 2021-04-16, and the package.json version field reads 1.3.1 with a comment reminding the maintainer to also change the version in the Algebrite variable at the top of the defs file. Those three facts together describe a project that is still receiving occasional work but whose published artefacts are several years old.

For a library that others build on, that gap is the risk to weigh. An npm install pulls a package whose version predates the most recent commit, and the README does not document a migration path or a compatibility policy between versions.

The repository layout is worth a glance for anyone planning to contribute. There is a sources/ directory, a runtime/ directory, a dist/ for built output, an index.ts and an inspector.ts at the root, a test-harness.ts, a run-micro-tests.ts, gen_tests.bzl, and separate tests/ and tests-from-master/ directories with a shell script to run the master tests. The contribution guide is a separate file, contributing.md.

Editorial conclusion

Algebrite fits a team that needs symbolic mathematics inside a browser or a Node.js application and wants a readable result rather than an opaque one, and it does not fit a team already standardised on Python, where SymPy does the same job with a larger ecosystem. Before adopting it, run bazelisk test :all on your target platform, since the build is Bazel-based rather than a plain npm install, and note that the published release on GitHub is v1.4.0 from 2021-04-16 while the package.json in the repository still reads 1.3.1.

Frequently asked questions

Official sources

1. davidedc/Algebrite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases