languages and sets #

The harness owns the language ids. Each library names its languages differently, so an adapter maps these ids onto its library's own. bench/langs.ts is the source of truth, and a results file carries the list, so the tables on this page are read from the results this site renders.

The languages measured are fuz_code's built-in set, so the list favors it. Prism and Shiki each support hundreds of languages, and none of that shows here.

Language ids
#

The language ids of the results this site renders.
id	language	timed
`ts`	TypeScript	yes
`js`	JS	yes
`css`	CSS	yes
`html`	HTML	yes
`xml`	XML	no
`json`	JSON	yes
`svelte`	Svelte	yes
`md`	Markdown	yes
`bash`	Bash	yes
`rust`	Rust	yes

The timed languages are the ones every library in the starting roster supports, so a timed comparison is never missing a library by design.

A language that is an id but is not timed is one the roster doesn't share: XML is the case today, since Twinkleplop has no XML language. It appears in the coverage matrix and in feature sets. A cold-start scenario that loads one language loads a timed one, so it never names an untimed id.

The measured libraries support many more languages than these. An id is added when a feature set or a second library needs it.

Unsupported and excluded
#

A library can be missing from a comparison for two different reasons:

unsupported — the library's adapter doesn't claim the language. Adapters declare their languages explicitly and never fall back to plain text, which would otherwise benchmark as very fast.
excluded — the adapter claims the language, but its output failed the check that runs before measuring, described in adapters.

Neither is recorded as a zero or counted in an average, and the results file keeps the two apart.

Feature sets
#

A feature set is a named list of language ids that bundle size is measured over, and that a cold-start scenario imports. The sets are declared in bench/sets.ts before any numbers exist, so a set can't be chosen to flatter a result.

The feature sets of the results this site renders.
id	label	languages	note
`core`	core	none
`docs`	docs	js, ts, css, html, md, bash, json
`web_rust`	web + rust	ts, js, css, html, xml, json, svelte, md, bash, rust	fuz_code's full set (home turf)
`all`	all	ts, js, css, html, xml, json, svelte, md, bash, rust
`timed`	every timed language	ts, js, css, html, json, svelte, md, bash, rust
`single:<lang>`	the language's name	one, for each language id
`without:<lang>`	timed less the language	every timed language but one, for each timed language

What each is for:

core — the library with no languages registered: its runtime floor.
single:<lang> — subtracting core gives what that language adds, which the results page shows for every language.
docs — what a documentation site imports, matching Twinkleplop's docs bundle. It is also the set a cold-start process loads in the set scenario.
web_rust — everything fuz_code supports, so it is home turf for that library, and its note says so. It is named by its content because the site is neutral.
all — every language id. While it holds the same languages as another set, the two are one bundle, and the results page shows them as one row.
timed — every timed language, which every library claims, and without:<lang> — the same less one of them. Subtracting the second from the first gives what one more language adds, without the runtime the first language pays for. deterministic metrics says how to read it.

A set is measured for a library only when the library supports every language in it. Otherwise the result names the languages it lacks. deterministic metrics describes how a set is built and measured.