dat.GUI: A Lightweight JavaScript GUI for Tweaking Variables at Runtime

The problem dat.GUI solves: variables that need a dial, not a rebuild

Most JavaScript parameters live in source code. A camera distance, a particle count, an easing constant. Changing one means editing a file and reloading. dat.GUI exists to remove that loop. The README describes it as "a lightweight graphical user interface for changing variables in JavaScript", and that is a narrow, honest scope. You hand it an object, and it renders controls bound to that object's properties.

The audience is equally narrow. This is a tool for people writing demos, generative sketches, visualization prototypes, physics experiments and internal tuning panels. It is not a form library, not an application shell, and not a design system. If you are building a product interface that end users will operate, the controllers dat.GUI produces are the wrong vocabulary: they are labelled by property name and arranged for a developer, not for a customer.

How dat.GUI works: one object in, controllers bound to its properties

The mechanism is straightforward. You construct a GUI instance and pass it a plain object. dat.GUI walks the object's properties and creates one controller per property, choosing a widget from the value's type: a number becomes a slider or a numeric field, a boolean becomes a checkbox, a string becomes a text field, and so on. The controller holds a reference to the property, so moving a slider writes back into the same object your render loop is already reading. There is no separate state store and no change event you must wire up for the common case.

The repository layout matches that design. The `src` directory holds the source files, `build` holds compiled output, and `tests` holds the test suite. The API documentation lives in `API.md` at the repository root, and the README points there directly rather than duplicating it. The build pipeline is Rollup plus Sass, with QUnit and jQuery listed among the libraries used in development. The package exposes `build/dat.gui.js` as the CommonJS entry and `build/dat.gui.module.js` as the ES module entry, so bundlers pick up the module build while older tooling resolves the CommonJS one.

One consequence of binding directly to object properties is worth stating plainly: dat.GUI is a view over your object, not a source of truth. If something else mutates the same property, the controller's displayed value can drift from the actual one. The README does not document a synchronization mechanism for that case.

Installing dat.GUI from npm and building a first panel

The README gives two installation paths. The npm path is the one to use if you are already bundling. The command is exactly as documented:

$ npm install --save dat.gui

After that, the README shows both a CommonJS require and an ES6 import. The import form is:

import * as dat from 'dat.gui';

const gui = new dat.GUI();

Calling `new dat.GUI()` with no arguments creates a panel. The README does not show what you pass next in this snippet; the API documentation in `API.md` is where the controller methods are described. What you should see after the import and construction is an empty panel rendered in the page, which is the expected starting state before you add anything to it.

The second path avoids a bundler entirely. The README calls the packaged build "the easiest way to use dat.GUI in your code" and points at `build/dat.gui.min.js`, noting that these built files bundle all the necessary dependencies. You include it in the head tag:

<script type="text/javascript" src="dat.gui.min.js"></script>

If you would rather produce those files yourself, the README gives the build commands. `npm install` first, then `npm run build`, which the package.json defines as running Rollup twice: once with `rollup.config.js` and once with `rollup.config.min.js`. There is also `npm run dev`, which the package.json defines as a concurrent Rollup watch plus a static server on port 8080, so you can open a browser against the working build.

Content Security Policy is the failure mode to check first

The README has a short, specific section on Content Security Policy, and it is the most concrete limitation documented. If your server sends a CSP that blocks `unsafe-inline`, dat.GUI will have problems, because the library injects style information into the page. The documented workaround is to load `build/dat.gui.css` as an external stylesheet instead of relying on the injected styles.

That is a real constraint, not a theoretical one. It means dat.GUI assumes it can write styles at runtime, which is a pattern many hardened deployments disallow. If you cannot add an external stylesheet to your build, or your CSP is stricter than blocking inline styles alone, dat.GUI may simply not render correctly, and the README offers no second workaround.

There is a second, softer limitation: the project's own release history. The most recent release listed is v0.7.9 from 2022-02-19, with v0.7.8 and v0.7.7 both from 2022-02-17. The last push to the repository was on 2026-06-21, so the repository is not archived and has seen activity, but the published version has not moved since early 2022. Anyone pinning a dependency should treat 0.7.9 as the version they will get, and should not expect a stream of fixes.

dat.GUI versus lil-gui, and why the difference matters

The most common comparison in search data is dat.GUI against lil-gui, and the two take different approaches to the same problem. lil-gui is a separate project that reimplements the controller-panel idea in a smaller, dependency-free form. The practical difference is packaging and maintenance posture rather than features: lil-gui is distributed as a modern module with no build step required on your side, while dat.GUI ships a Rollup-built bundle plus a separately loadable CSS file.

That distinction shows up in the CSP case above. A library that injects styles at runtime needs the external stylesheet escape hatch; a library that does not inject styles does not. It also shows up in how you consume the package. dat.GUI's package.json points `main` at `build/dat.gui.js` and `module` at `build/dat.gui.module.js`, which is a dual-package arrangement that works but leaves you choosing which entry your bundler resolves.

The honest framing is that dat.GUI is the older, more widely copied design, and lil-gui is the newer take on it. If you are starting a project today and have no existing dat.GUI code, the newer library is worth evaluating on packaging grounds alone. If you already have dat.GUI panels wired into a demo, the migration cost is real and the benefit is mostly about the dependency, not the API.

Licence and the cost of staying on 0.7.9

dat.GUI is published under Apache-2.0, both in the README's package metadata and in the repository's `LICENSE` file. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters if you are embedding the library in a product rather than a demo. It also carries notice requirements: you keep the licence and attribution intact. This is a description of what the licence says, not legal advice; if your organisation has a policy on third-party notices, route it through that process.

The upgrade cost is the more interesting question. Because the newest release is 0.7.9 from February 2022 and the repository's last push was 2026-06-21, there is a gap between repository activity and published artifacts. If you depend on the npm package, you get 0.7.9. If you need something that landed in the repository after that release, you would be building from source with `npm run build`, which the README documents, and then carrying that build yourself. That is a maintenance decision, not a technical one, and it should be made before adoption rather than after.

Editorial conclusion

Adopt dat.GUI if you are building a demo, a visual experiment or an internal tool where a small panel of sliders and checkboxes is enough, and you are comfortable pinning 0.7.9 because that is the newest release. Do not adopt it if you need a maintained dependency with a recent release cadence, or if your interface needs layout control, accessibility work or a component set beyond the controllers the API documents. Before committing, verify two things yourself: that build/dat.gui.min.js loads under your Content Security Policy, and that the controllers you need are listed in API.md rather than only in an example.

Frequently asked questions

Official sources

1. dataarts/dat.gui on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases