Pluto.jl: reactive Julia notebooks without hidden state

The problem Pluto.jl solves: notebooks whose state you cannot see

A conventional notebook kernel keeps a mutable workspace. You run cell 3, then cell 7, then go back and edit cell 2, and the variables in memory no longer correspond to anything on screen. The README states the guarantee Pluto.jl is built around: at any instant, the program state is completely described by the code you see. There is no mutable workspace, and deleted code leaves no trace.

That guarantee is aimed at a specific audience. Pluto was developed alongside the MIT course Introduction to Computational Thinking, and the repository lists designed-for-teachers and education among its topics. A teacher who hands a notebook to a room of students does not want a notebook that only works if the cells are executed in one particular order. A researcher who sends a notebook to a collaborator does not want to explain which cells to run first. The project's answer is that order stops mattering: cells can be placed in arbitrary order and syntax analysis works out the dependencies.

How reactivity works: syntax analysis instead of execution order

A Pluto notebook is a set of cells, each a small block of Julia code. Before anything runs, Pluto looks at the code once. The README is explicit that there are no code rewrites or wrappers: the tool reads your source, determines which cells define which variables and which cells refer to them, and builds a dependency graph. When you change a variable, every cell that refers to it is re-run.

The consequence is that the notebook behaves like a spreadsheet rather than a script. Change a parameter and the plots downstream of it update. The sample directory in the repository reflects this: there are files such as Basic no cell order.jl and Interactivity.jl, alongside Plots.jl.jl and PlutoUI.jl.jl.

Package handling sits on the same analysis. Pluto reads which packages a notebook imports and manages an environment for that notebook, so the README says you can import a registered package directly without installing it yourself. The information needed to reproduce that environment is stored inside the notebook file, so a collaborator opening the file gets the same package versions. Interactivity extends the same model through the @bind macro, which creates a live bond between a browser widget and a Julia variable; the PlutoUI package supplies sliders, buttons and other inputs. The README also notes that you can write your own widgets with Julia, HTML, JavaScript and CSS.

Installing Pluto.jl and running a first reactive cell

The README gives the shortest possible path: start Julia and run two lines. The project points to plutojl.org/#install for the full guide to installing Julia itself. If you do not have Julia yet, that page is where the project sends you; there is no separate package manager route documented in the README.

import Pluto
Pluto.run()

Running this starts the notebook server and, according to the README, opens a browser interface where you can create a notebook. The README does not document a command line flag for the port or for disabling the browser launch, so treat the defaults as the supported path.

The interactive example in the README is an ODE plot: changing the parameter A in the first cell re-evaluates the second cell and redraws the plot. To follow that pattern, write a value in one cell and a computation that uses it in another, in either order, then edit the first cell and watch the second update. If you want to try the environment without installing anything locally, the README links a Pluto demo running inside your browser through binder.plutojl.org.

For a widget, the README points at PlutoUI. A cell that imports PlutoUI and binds a variable to a slider is the standard way to make a notebook interactive; the docs link in the README (featured.plutojl.org/basic/plutoui.jl) is the reference for the available inputs.

Notebooks as pure Julia files, and what that costs you

Pluto saves notebooks as pure Julia files. The repository ships a sample/Basic.jl you can read as an ordinary Julia script, and the README says you can import a notebook as if you had been programming in a regular editor. Outputs can be exported as HTML and PDF documents, and you can reorder cells and hide code to control how the notebook reads.

The trade-off is that a notebook file is not a plain script. It carries the package environment needed to reproduce its dependencies, which is exactly what makes sharing work and also what makes the file larger and less portable than a bare .jl file. The sample directory contains both old_notebook_with_using.jl and notebook_with_metadata.jl, which suggests the format has changed over time and that older files exist in the wild. If you keep notebooks in version control, expect diffs that include environment metadata, not only code.

The reactivity model has a cost of its own. Because cells re-run when their dependencies change, a cell that performs a long computation will re-run whenever anything upstream of it changes. The README presents this as the feature, and it is, but it means the shape of your dependency graph determines how pleasant the notebook is to edit. A cell that reads a large dataset and is referenced by many others becomes a bottleneck you will notice on every edit.

Where Pluto.jl is the wrong choice

Pluto.jl is a Julia environment. The README describes cells as arbitrary Julia code and the built-in package manager as resolving registered Julia packages. If your notebook needs Python, R or another language in the same document, nothing here provides that.

The no-hidden-state guarantee is also a limitation in disguise. If you want a long-lived session where you build up state interactively, keep objects alive across runs, or deliberately mutate a workspace in ways the code does not show, Pluto is designed against you. The README frames the absence of a mutable workspace as the point, comparing it to Jupyter and Matlab, so this is not a gap that will be filled.

Reproducibility through a stored package environment also assumes the environment resolves on the other machine. The README states that the exact same package environment will be used when someone else opens your notebook, but it does not document a rollback or conflict-resolution path for the case where a package version is unavailable. If your work depends on private or unregistered packages, the automatic environment is not the part of the workflow you should rely on without checking it yourself.

Pluto.jl compared with Jupyter

The difference is architectural, not cosmetic. Jupyter notebooks run against a kernel that holds a mutable namespace; execution order is whatever you typed, and the notebook file stores inputs and outputs but not the state that produced them. Pluto.jl removes the mutable namespace and derives execution order from syntax analysis of the code. The README makes the contrast directly, naming Jupyter and Matlab as the environments whose mutable workspace Pluto does not have.

A second difference is the file format. A Jupyter notebook is JSON with embedded outputs; a Pluto notebook is a Julia file with the package environment stored inside it. That changes what a code review looks like, what a merge conflict looks like, and what happens when you open a file a year later. For a Julia-only project where reproducibility matters more than ecosystem breadth, the Pluto format is the stronger artifact. For a project that mixes languages or depends on Jupyter's extension ecosystem, the Jupyter model is the one with the tooling. The repository's own topic list and the teaching material around it make clear which of those two Pluto was built for.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-19. The recent releases listed are v1.0.1 on 2026-05-27, v1.0.2 on 2026-07-06 and v1.0.3 on 2026-07-07, so the project is on a 1.x line with patch releases arriving after the 1.0 announcement linked in the README.

Pluto.jl is MIT licensed. The README shows the MIT logo and the repository carries a LICENSE file, with a separate sample/LICENSE for the sample notebooks. MIT is permissive: it allows commercial and closed-source use, and it comes with no warranty. That is a statement about the licence text, not legal advice; if you are embedding Pluto in a product, read the LICENSE file in the repository rather than this paragraph.

Upgrade cost is mostly about the notebook format. Because the package environment lives inside the notebook, moving to a new Pluto release can mean the stored environment is re-resolved when you open an old file. The presence of both old_notebook_with_using.jl and notebook_with_metadata.jl in the sample directory is a reminder that files written by earlier versions exist and may behave differently. Pin the Pluto version you use for teaching material, and open the notebooks before a class rather than during it.

Editorial conclusion

Adopt Pluto.jl if your work is Julia code that you want to read, re-run and hand to someone else with the same package environment, and if reactivity fits how you explore a model. Do not adopt it if your notebook has to run Python or R cells, if you need a long-lived shared kernel that keeps hidden state between runs, or if you depend on Jupyter-only tooling. Before committing, open one of the sample notebooks from the repository, check that the package environment stored in that file resolves on your machine, and confirm that the cells you care about re-run cleanly after you edit a variable they depend on.

Frequently asked questions

Official sources

1. JuliaPluto/Pluto.jl on GitHub
2. License: MIT
3. Project website
4. README
5. Releases