DemoIt, a live-coding presenter that keeps the terminal in the slide

The context switching problem a talk audience sees

DemoIt is a tool for creating live coding demonstrations, and the README states the goal plainly: live coding demos without context switching. The author describes doing a lot of live coding at conferences and liking reveal.js for slides, but wanting a tool with some of reveal.js's properties plus the ability to code and run commands in front of an audience.

The problem being solved is not authoring slides. It is the performance of a talk. Attendees do not want to watch a presenter moving between a browser, an IDE and a terminal, because each switch costs the audience their place in the story and costs the presenter a reset of attention. DemoIt puts the whole demonstration surface in one window so the only thing changing is the content.

Two design commitments follow from that. First, for a given presentation the slides live in the same repository as the code, so a demo is versioned with the thing it demonstrates and a broken live example can be fixed in the same commit. Second, the tool has to support context-switching-less live coding, which is what the terminal component is for.

The audience for this is narrow and specific: conference speakers, meetup presenters and anyone demoing a terminal tool to a room. It is not a documentation generator and not a screen recording tool.

What DemoIt serves: web components, terminals and a browser view

DemoIt is described as a small command line tool written in Go that serves rich web content composed of text, images and smart web components. The README attributes most of the effect to those components rather than to the server side.

Three of them carry the weight. One component displays multi-tab ttys that can be used to run any command, which is what lets a demo run a real tool in front of people rather than a mock-up. Another is a web browser view that auto refreshes itself, so a served web application can be shown and updated without leaving the page. A third is a code viewer with syntax highlighting and tabs that the README says looks like a real IDE, which addresses the second half of the context switching problem, the IDE window.

The server side is a Go binary with a small dependency list that tells you a lot about the design: gorilla/mux for routing, gorilla/websocket for the live connection, creack/pty for spawning shells, alecthomas/chroma for syntax highlighting, rjeczalik/notify for filesystem watching and stretchr/testify for tests. The handlers directory holds JavaScript, and the browser terminal is built on an embedded Ghostty web terminal whose assets are compiled into the binary. The go.mod file also names a vendored directory, so the module ships with its dependencies checked in.

Multi-tab ttys matter more than they first appear. Each tab is a separate shell, so a demo can keep a server running in one tab and a client in another, both visible at once.

Installing the binary and starting from the bundled sample

The README gives two ways to install. The first is a single release binary from GitHub, downloaded and installed into the path:

curl -L -odemoit https://github.com/dgageot/demoit/releases/download/v1.0/demoit-`uname -s | tr '[:upper:]' '[:lower:]'`-`uname -m`
sudo install demoit /usr/local/bin/demoit

The filename is derived from uname, so the command picks a macOS or Linux archive for the machine architecture. Note that the version segment v1.0 is the only release listed for the project.

The second option is to build from source, which the README says requires Go 1.26 or later:

git clone https://github.com/dgageot/demoit.git
cd demoit
go install

To see it working without writing anything, the README suggests fetching the bundled sample into an empty directory:

cd $HOME; mkdir my-demoit-presentation; cd $HOME/my-demoit-presentation
curl -L https://github.com/dgageot/demoit/archive/master.tar.gz | tar xvf - --strip-components=2 demoit-master/sample
demoit

Then you browse to http://localhost:8888. The curl line is worth reading before running it: it downloads a tarball over the network and unpacks it into your home directory with strip-components=2, so the directory has to be empty as the first comment says.

There is also a font note that saves confusion later. The README advises installing the font Inconsolata for Powerline, which it links to the powerline fonts repository, because the web terminal displays incorrectly without it.

Customising slides, live reload and the shape of a presentation

A DemoIt presentation is deliberately plain. The slide content goes in a file called demoit.html at the root of the project, with all the html slides separated by --- markers. Assets such as images, fonts and scripts go in a .demoit folder at the root, and the stylesheet is customised at .demoit/style.css. The sample directory in the repository contains exactly this layout, with .demoit, demoit.html, a folder and a sources directory.

That format is a feature for the stated goal. Slides are HTML you can read in a diff, next to the code they demonstrate. There is no proprietary project format to open in a proprietary editor.

For iterating during a talk, the README offers a development mode:

demoit -dev

This gives live reload each time the content of the slides changes. The README describes the ignore rules in detail: when Git is available and the presentation sits inside a repository, live reload skips Git-ignored files and directories, including nested .gitignore rules, .git/info/exclude and global excludes. Tracked files still trigger reloads even when they match an ignore rule, and outside a repository or without Git, live reload simply continues normally.

The keyboard detail matters more than it looks. Pressing the command key with K in a focused terminal clears that screen and its scrollback, then sending Ctrl-L redraws the shell prompt and any pending input without executing it. Other terminals are unaffected and the session is not restarted, so a demo can clean up a screen mid-talk without killing the running process.

Testing, embedding assets and the limits of a single release

The README documents a testing setup that is unusually precise about what it does not measure. The Go tests run under the race detector, the linter is golangci-lint, and the JavaScript tests run through the Node test runner:

go test -race ./...
node --test handlers/terminal*_test.js

The browser test uses an installed Chrome or Chromium, or the CHROME_BIN environment variable, together with a mock WebSocket, and it never starts shells or presentation commands. The benchmark reports Canvas CPU time for single-row edits and full redraws, explicitly not keyboard-to-display latency. Node tests also exercise the shipped WASM without a browser.

The asset story is spelled out because it is a common source of confusion. Terminal assets are embedded in the binary, so after changing them you run go install, restart DemoIt and reload the presentation. Local emulator patches are recorded in handlers/resources/ghostty-web/provenance.json, and the README instructs you to update asset digests and the versioned route when bytes change, so that immutable browser caches cannot serve stale code. This is a well-documented approach, but it does mean a custom build has a fixed sequence of steps.

The limit that deserves a headline is the release history. The only listed release is v1.0, dated 2022-11-23, while the last push to the repository was on 2026-10-05. The project is moving, but it has not published a new binary in years, and the install instructions therefore point at a 2022 artefact unless you build from source. A dependency list that has moved on, with go.mod requiring Go 1.26, means the old binary and the current source are not the same thing.

How DemoIt compares with slides tools and screen recording

The comparison a presenter will actually make is against a slide tool plus a separate terminal window, or against a screen recording of the demo. DemoIt's approach is a live server: the slides are HTML, the terminal is a component in the same page, and the code viewer replaces the IDE window. Nothing is pre-recorded, so a demo that fails on stage fails identically to what the audience would see locally, which is either a virtue or a disaster depending on the talk.

Against reveal.js, the difference is that DemoIt is not a slide framework with an extension ecosystem. It is a small Go binary with a fixed component set: multi-tab ttys, an auto-refreshing browser view and a code viewer. There is no plugin API, no theme marketplace and no PDF export. If your talk needs transitions, animations or a slide numbering scheme, reveal.js or a similar deck tool remains the better answer.

Against a screen recording, the difference is liveness and effort. A recording gives you perfect playback and zero risk, but it cannot respond to a question from the audience, and it hides the fact that the demo is scripted. DemoIt trades that safety for the ability to take a question and change the code on the fly.

One more alternative worth naming: running the demo in a plain browser window and switching with a window manager. It needs no tool at all, and it fails the exact requirement the author set out to meet, since the audience still watches the switch.

Editorial conclusion

Adopt DemoIt if you give conference or internal talks and want slides, a real shell and a refreshing browser view on the same page, and you are willing to run the tool from source because the only published release is v1.0. Skip it if you need a slide deck with animations and export to PDF, or if a frozen binary with no maintenance matters more than the live terminal. Verify first by building with go install on Go 1.26 or later, running demoit -dev from the sample directory, and checking that the Inconsolata for Powerline font renders correctly in your terminal view.

Frequently asked questions

Official sources

1. dgageot/demoit on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases