Fragment: a browser workbench for canvas sketches

Fragment is a workbench, not just a library

The project describes itself as a modern toolkit for creative coding, and the repository description marks it as alpha. The README summary is more specific: Fragment lets you sketch, render and export canvas-based graphics with ease, from quick experiments to production-ready visuals.

The word that matters is workbench. Fragment is not a single rendering library that you import and call. It is a development environment with a command line interface, a browser interface, a live GUI generated from your own code, and export paths, and it can produce a static bundle for deployment. The examples directory shows the range: canvas2d-shape, p5js-grid, p5js-shader and threejs-webgl-cube.

Templates exist for Canvas 2D, p5.js and three.js, so you can start from a familiar library and still get the surrounding tooling. The people it fits are creative coders who iterate visually: the tool is built around a loop of edit, look, adjust a slider, look again, and the slider is generated rather than hand-wired.

The project is MIT licensed, the homepage is fragment.tools, the default branch is dev, and the last push was on 2026-10-18. Tagged releases are v0.2.15 from 2026-07-01, v0.2.14 from 2026-06-01 and v0.2.13 from 2026-05-29.

Props are the interface, so the GUI writes itself

The mechanism that makes Fragment different from a plain canvas library is the props export, and the README example shows it in full.

A sketch exports a props object where each key describes one control. A value creates the control, and a params object tunes it. A numeric value with min and max becomes a range slider, a string value with an options array becomes a select, and colours become colour inputs:

export let props = {
	background: {
		value: '#0057B8', // create a color input GUI
	},
	fill: {
		value: 'rgba(255, 215, 0, 1)', // create a color input GUI
	},
	size: {
		value: 256, // create a number input GUI
		params: {
			min: 64, // add a range slider
			max: 512,
		},
	},
	shape: {
		value: 'circle', // create a string input
		params: {
			options: ['circle', 'square'], // turns the input into a select with different options
		},
	},
};

The point is that the interface and the parameters are one declaration. There is no separate control panel file to keep in sync with the sketch, and the values are read straight from props inside the draw routine, where the example reads props.background.value and props.shape.value.

The rest of the sketch contract is visible in the same example. An exported update function receives context, width, height and pixelRatio, and the drawing code multiplies by pixelRatio to stay sharp on high density displays. Additional exports set the rendering mode with rendering, the frame rate with fps, a display name with name, and build behaviour with buildConfig, where resizing is set to window in the example.

Shaders reload live, and input arrives as ordinary events

Two of the iteration features deserve their own reading, because they are the ones that change how long a shader takes to write.

The first is GLSL reload on the fly. In a p5.js or three.js shader workflow, a change to a fragment shader normally means a page reload, and a reload loses your place. The p5js-shader example in the repository is there to be used with that reload path.

The second is input. The README states that mouse, keyboard and MIDI inputs can be attached directly from the interface or from your code. Attaching from the interface matters for a musician or a live performer, because a MIDI controller mapped through the workbench does not require a separate event layer in the sketch, while attaching from code keeps the mapping inside the source file for a sketch you intend to keep.

The workspace side of the tool is flexible window layouts, so a sketch, its controls and its output can be arranged together rather than as a fixed page.

Under the hood the stack is Vite for the dev and production builds, Svelte for the interface, and a command line interface built on sade and clack, with milliparsec for argument parsing and kleur for terminal colour. The package metadata pins svelte at version 5, vite at 8, sade at 1.8, @clack/core at 1.3, ws for the WebSocket layer, get-port, changedpi for display scaling, convert-length for unit conversion, gifenc, and is-unicode-supported for terminal capability detection. Mediabunny handles video encoding in the browser.

Export to video happens in the browser

The export path is where Fragment differs from the libraries it templates, and it is a design decision with consequences.

The README lists export of sketches as images or videos in standard formats, and separately that static bundles can be built ready for production deployment. The video work is done in the browser through Mediabunny, which the README names as the tool for video encoding in the browser, and Mediabunny appears in the dependencies at version 1.13.

Doing the encoding in the browser is convenient. There is no encoder binary to install, no ffmpeg command to remember, and the recording happens in the same environment where the sketch runs, so what you see is what is captured. It also means the export path depends on the browser's own capabilities and on the user's machine doing the encoding work, which is a different profile from a server-side render farm.

The static bundle path is the production answer. A sketch built into a static bundle is deployable as files, which is what you want when the visual ends up on a site rather than in a local tool. The build behaviour is expressed in the sketch itself through buildConfig, with resizing set to window in the example, so the same source can be a development sketch and a deployed piece.

The example interface described in the screenshot shows a canvas with effects on one side and colour, shape and grid controls plus an export module with video capabilities on the other, which is a fair picture of how the pieces sit together.

First sketch: three commands and a template flag

The installation options are given plainly, and the fastest path is one command.

The quick route runs the tool without installing it:

npx fragment-tools sketch.js --new

A global install gives you the fragment command directly:

npm install fragment-tools --global

After that you can check the installation with:

fragment -v

A local install is also possible with npm install fragment-tools, and the README notes the flag options are documented in the CLI docs at docs/api/CLI.md.

The usage section then shows the normal working loop. You make a directory for your sketches, move into it, and create a sketch from a template, in JavaScript or in TypeScript:

mkdir sketches
cd sketches
npx fragment sketch.js --new --template=2d
npx fragment sketch.ts --new --template=2d --typescript

Running an existing sketch is the same command without the creation flags:

npx fragment sketch.js

The template flag selects the starting point, with 2d shown in the example, and the extra --typescript flag produces a TypeScript sketch instead. The two commands above are the whole onboarding: a directory, a template, and the file open in the workbench.

Running from a clone with npm link

Contributors run the tool from a checkout, and the README gives a separate path for that.

Clone the repository, move to its root, and run the CLI entry point directly against an example:

git clone https://github.com/raphaelameaume/fragment.git
cd fragment
node ./bin/index.js examples/shape-2d.js --dev

The same works from a sketch folder by pointing at the repository path, which is what a contributor with sketches in another directory needs:

node [path-to-root]/bin/index.js sketch.js --dev

The --dev flag is deliberately narrow. The README states that it only enables the Vite info logLevel and is helpful during development, and that otherwise the behaviour is the same as when running from the npm package. That is a useful detail for anyone who expected a debug mode with different semantics.

The alternative to passing the path is to point npm at the cloned folder, from the root of the repository:

npm link

After linking, the fragment command behaves as before but resolves to the repository instead of the globally installed package. If it does not, the README has the fix: uninstall fragment-tools globally, make sure the fragment command is no longer found, then link again from the root of the repository. The package metadata shows why this matters, since the bin entry maps the fragment command to bin/index.js and the main entry to src/index.js, so a stale global install shadows the local one.

Where Fragment is the wrong tool

There are honest reasons to look elsewhere, and the project itself supplies the first one.

The repository description says alpha, and the version tells the story more precisely. The package version is 0.2.15 and the tag history is v0.2.15, v0.2.14 and v0.2.13, so the tool is pre-1.0 and the API is still moving. For a sketch you experiment with over a weekend, that is irrelevant. For a visual that has to keep working while you upgrade the toolchain, it is a real cost, and the changesets setup in the dev dependencies suggests a changelog-driven release process but not a stability promise.

The second limit is the browser. The interface is a browser workbench, the video encoding happens in the browser, and the build output is a static bundle served as files. If your pipeline needs headless rendering on a server, a batch export over a large number of sketches, or integration into a toolchain that has no browser at all, nothing in the README describes that route, and you would be building it yourself.

The third is the dependency on Svelte and Vite being current. The package pins svelte 5, vite 8 and the Svelte Vite plugin 7, and the interface is written in Svelte with a Prettier configuration and a Prettier plugin for Svelte. A project that needs a specific, older Svelte version for other reasons may find itself in dependency negotiation.

The fourth is the credit line that points at the origin. The README gives a special thanks to Matt Deslauriers for canvas-sketch and his multiple projects around generative-art tools. The README does not describe how canvas-sketch works internally, so the comparison has to stay at the level of the design each project documents. Fragment treats a sketch as a document with an interface attached, and every documented feature, the generated controls, the live shader reload, the MIDI attachments, the in-browser video export, follows from that. A workflow built around running a sketch as a plain script, with no workbench and no export panel, needs none of that, and adding it would be a cost rather than a benefit.

Editorial conclusion

Fragment fits a creative coder who wants a browser workbench with controls generated from the sketch itself, quick iteration on shaders and a path from experiment to exported video, and it fits someone coming from p5.js or three.js who wants a CLI and a GUI without hand-writing either. It does not fit a production visual pipeline that needs a stable contract, because the project is labelled alpha and sits at 0.2.15, and it does not fit a team that only wants the underlying library. Before adopting it, run npx fragment-tools sketch.js --new to see the generated interface, read the CLI docs in docs/api/CLI.md for the flag set, and decide whether the browser-based export path or the static bundle build fits your deployment.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. raphaelameaume/fragment on GitHub
4. README
5. Releases