WLJS Notebook: a Wolfram Language notebook that runs locally and in the browser

A notebook frontend, not a Mathematica replacement

WLJS Notebook is described as an open-source, web-native notebook interface for Wolfram Language, and the project is careful about what it is and is not. It is free and open-source software that runs with the Wolfram Engine, which is freeware for personal use, and the readme states plainly that you do not need Mathematica to use it. It is also not affiliated with, endorsed by, or sponsored by Wolfram Research.

So the license question that usually stops people is answered differently. The notebook frontend is free software. What you need is a Wolfram Engine, and the project names the recommended version as 15.0. The engine is a separate product with its own licensing, and the distinction matters for any commercial use, where the freeware terms do not apply.

The audience is stated as researchers, educators and developers who value the Wolfram Language but want a notebook workflow that is local, works with the freeware engine, is Git-friendly, lightweight and easy to share. Each of those adjectives maps to a concrete decision. Local means no hosted service is in the loop. Git-friendly means the notebook file format is minimal and human-readable, something people, version control systems and LLMs can all inspect and diff.

The build target is stated plainly too: interactive research notebooks, scientific tools and presentations, with typeset math, rich media, live controls and JavaScript integration. The rest of the project, from the rendering model to the container deployment, is the implementation of that sentence.

The architecture table, where the real differences are

The readme is explicit that WLJS and Mathematica use different frontend architectures, and it puts them side by side in a table. This is the most useful thing in the documentation for anyone deciding whether to switch, and it is worth reading before anything else.

The rendering model differs. Mathematica is immediate mode; WLJS is retained mode with immediate-mode emulation. The reactive model differs too, with Mathematica pulling and WLJS pushing. Reactive updates are automatic with dependency tracking and reevaluation in Mathematica, and explicit and targeted in WLJS. Data binding is two-way symbol binding in Mathematica and one-way symbol binding with input events in WLJS.

Those four rows describe a genuinely different way of writing a dynamic interface. The readme says as much: WLJS emphasizes explicit events, targeted updates, browser rendering, and control over how interactive interfaces behave.

What that means in practice is that the code you would write in Mathematica is not the code you write here. The first quick start example already shows the difference, because a Manipulate is the canonical Mathematica construct and the WLJS example splits the same idea into a control and a 3D plot:

Manipulate[
  Plot3D[Sin[n x] Cos[n y], {x, -1, 1}, {y, -1, 1}],
  {n, 1, 5, 0.3},
  ContinuousAction -> True
]

ContinuousAction is the immediate-mode setting for whether the plot redraws while the slider moves. In a pushed, explicitly updated model, that flag does not do the same job. This is exactly the kind of difference the migration guide exists to explain, and it is the honest reason this project is not a drop-in replacement.

Installation, and the three ways to run it

The quick start is three steps. Install the recommended Wolfram Engine 15.0, download WLJS Notebook for your platform from the installation page or from GitHub Releases, then open a notebook and evaluate your first expression.

The platform list is more varied than a typical desktop application. Windows has an x86-64 installer. GNU/Linux has x86-64 and ARM64 packages in AppImage, DEB and RPM formats where available. macOS has Apple Silicon and Intel disk images. And there is a server option, either a Docker container or a direct launch with WolframScript.

That last option is what makes the project viable for a team, because a notebook frontend that only runs on a laptop is a single-user tool. The deployment guide covers Docker and remote server installation, and the container/ directory in the repository holds the image definition.

The package.json shows how the desktop application is assembled, and the build scripts are the interesting part. The main entry point is Electron/main.js, and the scripts include start for running through wolframscript with Scripts/run.wls, el for launching electron directly, and a set of dist targets that use electron-builder for macOS arm64 and x64, Windows x64, and Linux x64 and arm64 plus a Linux RPM variant. There is also a build-css script that runs tailwindcss over Assets/Styles/Tailwind.css, which tells you that the interface styling is Tailwind.

Official desktop releases are digitally signed, and the package configuration includes an afterSign step pointing at Electron/sign.js, so the signing key handling is part of the build rather than something done by hand.

What the repository actually contains

The top-level listing is a fairly detailed map of the project. Kernel/ is the Wolfram Language side, Scripts/ holds the wl scripts the start and pre-dist scripts invoke, and Assets/ and Views/ hold the interface and its styles. Common/ and Components/ are shared frontend pieces, Frontend/ is the bulk of the web frontend, and Electron/ is the desktop shell with its own build configs, its signing script and its main test.

Modules/ and Packages/ are where the extension mechanism lives, and PacletInfo.wl at the root is the package metadata in Wolfram Language form, which is a nice detail for a project written in that language.

The JavaScript side is small. package.json names the project wljs-notebook at version 3.1.4, the main entry is Electron/main.js, and the devDependencies are not visible in the repository listing, but the test setup is. There is a Playwright configuration file and a playwright.config.js in the root, and the test script runs npx playwright test, with a separate test for the Electron main process using the node test runner, and a test-update script that refreshes snapshots. Screenshot-based testing of a notebook frontend is a reasonable choice, since most of what the user sees is a rendered page.

The build script also records a recommended-client-version of 2.6.3, which is the version of a companion client the notebook expects, and the project publishes a Zenodo DOI badge, which is how research software gets a citable identifier.

Where WLJS Notebook is the wrong choice

The first limitation is the one the architecture table makes explicit. If your existing work is a body of .nb files that rely on Mathematica's immediate-mode semantics, converting them is a project, not an import. The project does offer to open and convert .nb notebooks and it has a migration guide, and the readme is honest that the frontend and dynamic-interface differences are why, but an existing large notebook corpus is the main obstacle to adoption.

The second is the Wolfram Engine dependency. WLJS is the frontend, and the engine underneath is a separate product with separate terms, where the freeware version is for personal use. A commercial deployment on a shared server has to deal with that, and no amount of open source in the frontend changes it.

The third is the front-end architecture cost. Explicit, targeted updates and pushed reactivity are more verbose than automatic dependency tracking. If you are writing a dynamic document with a lot of interdependent pieces, you are doing more work than in Mathematica, and that is a deliberate design choice rather than an oversight, but it is a cost.

The fourth is project size and funding. This is an independent project with a first funding goal of 300 euros a year, broken down as 100 for an Apple Developer membership and 100 for a domain name, plus a small budget for CDN edge requests, cloud credits for testing and coffee. Five supporters at five euros a month would reach the goal before fees. A production deployment depending on a project with a five-supporter budget is a real consideration, and the same is true of the speed of development, which is visible in the release history with three 3.1.x releases in September 2026.

The fifth is the offline claim. Local and offline is a listed feature, and it means notebooks and computation stay on your machine without depending on a hosted service. It does not mean the Wolfram Engine is not needed, so the environment still has to be provisioned per machine or per server, which is the part most likely to be overlooked by a team reading the feature list.

Editorial conclusion

WLJS Notebook fits a researcher, teacher or developer who wants the Wolfram Language without a Mathematica licence and who values notebooks that live in version control as readable text, since the whole stack runs locally against the freeware Wolfram Engine and nothing depends on a hosted service. It is the wrong choice if you need to open existing .nb files unchanged, because the frontend architecture differs enough that a migration guide is part of the deal, and it is the wrong choice if you need the exact Mathematica behaviour. Before installing, read the migration guide and the architecture comparison in the documentation, and note that the last push was on 2026-10-19 with version 3.1.4 released on 2026-09-26.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. WLJSTeam/wljs-notebook on GitHub