The dynamic document tradition — Victor, Observable, Jupyter, Glamorous Toolkit
The web’s collapse of the document-application distinction has, in recent decades, produced a counter-tradition that takes the collapse seriously and tries to redeem it. The argument of the counter-tradition is that a document and a computation should not be different categories of thing. A document should be able to compute. A computation should be able to read as a document. The reader should be able to change parameters and see the document respond; the author should be able to compose code, prose, and visualization into a unified artifact that is neither a static page nor a packaged application but something in between, something specifically designed to support the reader’s exploration of an idea. The counter-tradition has been articulated most prominently by Bret Victor, and elaborated by the various computational-notebook systems that descend from the Wolfram Mathematica notebooks of the late 1980s, by D3.js and Observable, by Jupyter, and most recently by Tudor Gîrba and the Glamorous Toolkit team. The user base of these systems is, taken together, small. The intellectual influence is large. This chapter is about what the dynamic document tradition has been proposing, what it has built, what has been adopted, and what remains absent.
The proposition
The proposition of the dynamic document tradition is older than the web. It is older than the personal computer. The clearest early statement of it is Donald Knuth’s 1984 paper “Literate Programming,” in which Knuth proposed that programs and their documentation should not be separate artifacts but a single document, written in a system that produced both an executable program and a human-readable description as transformations of the same source. Knuth implemented his proposal in a system called WEB (no relation to the later web), used it to produce TeX, the typesetting system that has been the standard for mathematical and scientific publication ever since, and continued to use it for his other major projects through the next four decades. Literate programming did not, despite Knuth’s stature, become a widespread practice in software development. The reasons are several — the tooling was awkward, the cognitive load of writing both program and prose was high, the audience for serious mathematical documentation was small — but the proposition Knuth had made remained, after his demonstration, available as an articulated alternative to the prevailing practice. Knuth’s proposition was that the document and the computation should be the same thing, with each providing what the other needed.
A parallel tradition came out of Smalltalk at Xerox PARC in the 1970s and from Engelbart’s NLS earlier. The Smalltalk workspace was an interactive environment in which code, data, and prose lived in a single textual surface, with any expression executable in place and any result returned into the surface for further use. The workspace was a kind of dynamic document: a single textual artifact that the user constructed, modified, and computed with continuously. Smalltalk’s environment did not separate the editor from the interpreter or the document from the program. They were the same thing, and the consequence was that Smalltalk users developed a working style — alternating between writing prose, writing code, examining intermediate values, and refining each — that was structurally different from the file-based programming of Unix and from the strict-document-strict-program model of mainstream practice.
Wolfram Mathematica’s notebook interface, released in 1988 with Mathematica 1.0, was the first widely deployed system that took the dynamic-document idea to a mass-market product. A Mathematica notebook was a structured document containing text cells, code cells, output cells, and graphics cells, with the code cells being evaluable in place and the outputs being live results. The notebook could be saved, shared, reopened, and re-executed. The combination of prose and computation made Mathematica notebooks usable for technical communication in a way that previous mathematical software had not been. Stephen Wolfram has, in his more recent writing, called the notebook format the “computational essay” and argued that it should be a standard form of technical writing across many disciplines. The position is somewhat self-interested — Wolfram sells the system that produces these essays — but it is not wrong, and Mathematica’s notebooks have been used for substantial technical and educational work since the late 1980s.
Bret Victor
The figure who has most articulated the dynamic document tradition in its modern form is Bret Victor. Victor’s career has consisted of a series of essays, talks, demonstrations, and design proposals about what computing should look like if it took seriously the proposition that the medium should support the thinking. His most-cited talk is “Inventing on Principle,” delivered at the CUSEC conference in January 2012, in which Victor demonstrated working interactive programming environments in which a programmer could see, immediately and continuously, the consequences of changes to their code. The demonstrations were beautiful and unsettling: they made the standard practice — write code, save file, compile, run, observe output, iterate — look obviously primitive by comparison.
Victor’s essays have included “Magic Ink” (2006), which argued for static-information-display as a design discipline against interactive applications; “Up and Down the Ladder of Abstraction” (2011), which demonstrated explorable documents in which the reader could move between levels of abstraction continuously; “Learnable Programming” (September 2012), which critiqued the standard programming-education materials and proposed a different design philosophy; “Media for Thinking the Unthinkable” (April 2013), which proposed that the appropriate response to complex problems was the construction of media that made them thinkable; and several others. The essays are themselves dynamic documents in many cases, with interactive widgets that let the reader manipulate the examples while reading. They model, on the page, what their author is arguing for.
Victor’s “Tangle” library, released in 2011, was a small JavaScript framework for embedding interactive numbers and other reactive elements in web pages. A document written with Tangle could contain prose with parameters that the reader could drag to change, with the consequences of the changes propagating through the document — equations recomputing, charts updating, prose adjusting to reflect the new values. The library was small, well-designed, and demonstrated the technique convincingly. It has been used in essays by Victor and by others; a number of explainer pieces — Nicky Case’s various interactive essays, the explorables collected at explorabl.es, the Distill.pub journal articles on machine learning — descend technically and aesthetically from Tangle’s example.
Victor founded the Dynamicland research lab in Oakland, California, in 2014, with the longer-term goal of building physical interactive environments that took the dynamic-document idea off the screen and into the room. Dynamicland’s work has been less widely distributed than Victor’s essays — it requires being in the physical space — but it is part of the same intellectual program. The lab has continued operating into the present, though its work has been less visible to the broader programming community than Victor’s earlier essays.
The cumulative effect of Victor’s work has been substantial, despite the fact that none of his specific systems has become mainstream. He has been the most articulate voice in the past decade for the proposition that computing media should support thinking rather than merely host applications. The essays have been widely read and cited; the demonstrations have been widely watched and discussed; a generation of designers and engineers have been influenced by them. The influence has been disproportionate to the user base of his specific projects.
The notebook lineage
The other major thread in the dynamic-document recovery has been the computational-notebook lineage, which descends from Mathematica through several decades of evolution.
IPython, the interactive Python shell, was released in 2001 by Fernando Pérez, then a graduate student at the University of Colorado. IPython improved on the standard Python interpreter with better history, better introspection, and various tab-completion and pretty-printing features. The IPython Notebook was added in 2011, providing a browser-based interface with code cells and output cells in the Mathematica style. The IPython Notebook spread quickly in the scientific Python community, which had been growing through the 2000s and which needed a tool for interactive computation that matched what Mathematica and R provided in their domains.
In 2014, the IPython project rebranded as Project Jupyter to reflect its support for multiple language backends. Jupyter (the name a contraction of Julia, Python, and R, the three languages most prominently supported) is a notebook system that can run cells in any of dozens of programming languages, with the cells being evaluable in place and the outputs being displayed inline. Jupyter notebooks are JSON files that can be saved, shared, and re-executed. The format has become, over the past decade, a standard for scientific and analytical computing, with substantial use in data science, machine learning research, scientific publishing, and education.
Jupyter notebooks are, in functional terms, a Wolfram Mathematica notebook implemented in the open-source ecosystem and runnable in a browser. They have inherited Mathematica’s strengths and many of its weaknesses. The strengths are that they let authors mix code, prose, mathematics, and visualizations in a single document; that the document is executable, so that readers can re-run the computation; and that the format has been adopted widely enough that there is significant tooling for processing notebook files in various ways. The weaknesses are that the JSON format is hard to diff and version-control, that the execution order of cells is implicit and can produce non-reproducible state, that the notebook interface encourages a particular working style that has been criticized for various reasons, and that the notebooks tend to drift from their published state as authors continue to work on them after sharing.
Despite the weaknesses, Jupyter has been a major success. The Project Jupyter ecosystem includes JupyterLab (a more capable IDE-like interface), JupyterHub (multi-user notebook servers for classes and teams), Voilà (turning notebooks into standalone web applications), and many other tools. The notebook format is widely accepted by journals (with Distill.pub being a notable example) and is used by major research groups across the sciences. Jupyter is, in 2026, one of the few computational tools whose adoption has expanded steadily for over a decade with no sign of decline.
Observable, created by Mike Bostock (the original author of D3.js, the data-visualization library) and a small team starting around 2016, is a different take on the notebook idea. Observable notebooks are reactive: a cell’s value automatically updates when the cells it depends on change. This is structurally different from Jupyter, where cells execute in sequence and the state depends on what has been run when. Observable’s reactive model makes it easier to build interactive documents in which the reader’s manipulations propagate through the notebook coherently. The platform is web-based, with notebooks shared at observablehq.com, and has accumulated a substantial corpus of computational documents in fields including data visualization, journalism, education, and recreational mathematics.
Observable has been particularly visible in data journalism, where it has been used to produce interactive graphics and explanatory pieces by major news organizations. The combination of the dataflow model, the visualization-friendly D3 ecosystem, and the publishing platform has made Observable a natural fit for the kind of explanatory work that the New York Times graphics department, the FiveThirtyEight team, and various others have been producing through the late 2010s and 2020s. The user base remains smaller than Jupyter’s but the per-user influence is significant.
Glamorous Toolkit
The most recent and most ambitious project in the dynamic-document tradition is Glamorous Toolkit, developed by Tudor Gîrba and the team at the Swiss software company feenk since around 2020. Glamorous Toolkit is built on top of the Pharo Smalltalk environment and inherits Smalltalk’s commitment to integrated programming environments in which everything is live and modifiable. The project’s principal innovation is what Gîrba calls “moldable development”: the practice of building, for every kind of object or problem you work with, a custom visualization or inspector that makes the object’s structure legible. The argument is that programming is, fundamentally, a reading activity — reading code, reading data, reading state — and that the tools should support the specific reading each piece of work requires rather than treating all reading as the same.
Glamorous Toolkit’s user interface is a series of panes, each containing a view of some object — a method, a class, a data structure, a database query, a graph of dependencies. The views are not generic; they are constructed specifically for the kind of object being shown, with the developer being able to add new views as needed. The result is an environment in which a complex piece of software can be inspected at many levels and from many angles, with the inspections being themselves modifiable code that the developer maintains as part of the project.
The system also supports what Gîrba calls “knowledge ingestion”: the construction of integrated documents that combine code, prose, visualization, and analysis into a unified artifact that can be navigated, modified, and shared. A Glamorous Toolkit notebook is, in functional terms, a Jupyter notebook with first-class support for arbitrary visualizations of arbitrary objects, executed inside an integrated programming environment where the language is Smalltalk and the runtime is the whole environment.
Glamorous Toolkit’s user base is small — Smalltalk has remained a niche language despite periodic predictions of its revival — but the system is the most thorough recent implementation of the dynamic-document idea, and the team has been productive in producing both the system and the writing that explains it. Gîrba’s various talks and essays on moldable development have been influential in the small community of developers who care about programming-environment design. Whether Glamorous Toolkit will reach a broader audience is uncertain. The intellectual contribution is solid regardless.
The audience
A useful question to ask of the dynamic-document tradition is: who uses these tools, for what?
The honest answer is: relatively few people, in specialized domains. Jupyter notebooks are used by data scientists, scientific researchers, and educators in technical fields, and the user base in these domains is in the millions. Observable notebooks are used by data journalists, visualization designers, and a community of recreational mathematicians and explainer writers, with a smaller user base in the tens of thousands. Glamorous Toolkit is used by a small community of Smalltalk developers and people interested in moldable development, with a user base in the low thousands. Mathematica is used by researchers, engineers, and educators in mathematics-heavy fields, with a user base in the hundreds of thousands. The total user base of the dynamic-document tradition, summed across systems, is probably in the low millions — substantial in absolute terms but small as a fraction of the consumer internet’s billions of users.
The reason the user base is small is that the dynamic document is, structurally, a tool for thinkers and explainers, not a tool for consumers. The audience for a Jupyter notebook is a person who wants to do analysis or to follow analysis someone else has done. The audience for an Observable notebook is a person who wants to interact with a visualization or to read a piece of computational journalism. The audience for a Mathematica notebook is a person who wants to do mathematics or to follow a mathematical exposition. These are real audiences with real needs, but they are not, in aggregate, the consumer-internet audience. The dynamic document tradition is, in its current form, a tradition of tools for technical work.
This is not, in the broader argument of this book, a failure. HyperCard had a mass audience because it shipped on every Mac. The hypermedia systems before HyperCard did not have a mass audience because they ran on workstations. The dynamic document tradition is more like the workstation-class hypermedia systems: it produces tools that, for their users, are genuinely powerful, but the floor for use is high and the user base is correspondingly narrow. The question for the recovery is whether the floor can be lowered to bring the mass audience along. The Bret Victor essays and the Observable platform are, in different ways, attempts to do this, and the results have been mixed: the audience for explorable essays has grown, but the audience for the production of explorable essays is still small.
What has been recovered
A summary of what the dynamic-document tradition has recovered from the pre-web alternatives:
The document as a computation. Bush’s Memex had associative trails; Engelbart’s NLS had executable structures; HyperCard had scripts on cards. The dynamic-document tradition has restored, for technical audiences, the proposition that a document is something a reader can interact with, with the interaction being computation, not just navigation.
The integration of prose and code. Knuth’s literate programming proposed it; the workshop tradition had practiced it; the dynamic document tradition has reinstated it as a working possibility for technical work. Jupyter notebooks, Observable notebooks, Glamorous Toolkit pages — all of them treat prose and code as first-class citizens of the same document.
The reader’s manipulation of the document. Victor’s Tangle library, Observable’s reactive cells, and the various explorable-explanation tools have made it possible for a reader to manipulate a document’s parameters and see the consequences propagate. This is, in a small way, a recovery of the bidirectional reading-and-writing continuum that HyperCard had implemented.
The document as a teaching tool. The explorable essays at explorabl.es, the Distill.pub interactive papers, the Observable visualizations, the Jupyter teaching notebooks — these have become, for the audiences that use them, the preferred form of technical communication. The form is more powerful than the static print equivalents, and it is being adopted, in specific domains, as a serious mode of publication.
What has not been recovered
The dynamic-document tradition has not recovered, and probably cannot recover by itself, several things:
The mass audience. As discussed, the systems are tools for technical work, not consumer products. The mass audience that HyperCard had does not exist for the current dynamic-document tools, and the floor for production is too high to bring that audience along.
The local artifact. Most dynamic-document systems are tied to specific platforms (Observable to observablehq.com, Glamorous Toolkit to Pharo, Mathematica to Wolfram). The documents do not generally exist as self-contained files that the user owns and can preserve indefinitely. Jupyter is the partial exception — the .ipynb file is a portable artifact — but Jupyter notebooks depend on their kernel environments to execute, and the environments drift over time, with the practical consequence that a notebook from five years ago may not run today without effort. The HyperCard property of having an artifact that lives on your disk and runs forever is not, in the current tools, present in robust form.
The end-user authorship culture. The audience for using these systems is broader than the audience for producing them. The tools are still oriented toward people who are comfortable writing code, manipulating data, and thinking computationally. The audience that HyperCard had — the teachers and doctors and hobbyists who made things they would not have called software — has not been recovered by the dynamic-document tools. The Observable community has more non-programmer participants than the Jupyter community has, and the Tangle examples can be read by anyone, but the production of new dynamic documents remains a specialist activity.
The longer trajectory
The dynamic-document tradition is, in the trajectory of this book, the recovery that is most clearly intellectual and least clearly mass-cultural. The work being done is serious; the influence is real; the user base is growing slowly; the practical effects on what serious technical writing looks like have been substantial. The work is not, however, on a trajectory to displace the application web or to reach the audience that the document web of the early 1990s had. It is on a trajectory to remain a small but high-quality tradition of work, used by the technical audiences that need it and admired (or unknown) by everyone else.
This is a fair outcome and one that the tradition’s practitioners are mostly comfortable with. Bret Victor has been clear, in various essays and interviews, that the work he does is intended to influence longer-term thinking about what computing should be, not to ship products that compete in the current market. The Jupyter team, Observable team, and Glamorous Toolkit team are similarly oriented: they are building serious tools for serious work, with no aspiration to be the next consumer platform. The recovery they offer is, accordingly, partial. They are recovering, for specific audiences, properties that the document web once had broadly, with the recovery confined to the audiences that take advantage of it.
The next chapter takes a different recovery: local-first software, which is trying to recover, at the architectural layer, the property that the user’s data lives on the user’s machine. Local-first is more ambitious than dynamic documents in terms of who it wants to reach (everyone) and less ambitious in terms of what it wants to do (just make the data ownership work). The two recoveries are complementary; together they would address two of the larger losses the platform decade has produced.