llselect vs the field

Two browser benchmarks against the native <select> (the baseline floor), Choices.js, Select2, Tom Select and Slim Select: building many selects at once (mass instantiation), and interacting with one (interaction latency). Everything runs in your browser. Lower is better; numbers depend on your machine.

Mass instantiation

A stress test: build many independent selects at once and measure it, with the widgets actually rendered in the scroll area below.

Heavy. Each library gets a time budget (about 20 s); a competitor that cannot finish in it stops early and its row shows how many it built before the cut-off. "Run all" walks the five libraries in turn, so it can take a while.

Render one:

One row per library. Every number is for the WHOLE run - the total across all widgets built, not an average per widget.
Library	Built / target	Build total (all widgets, ms)	DOM nodes (all, resting)	Teardown total (all widgets, ms)

What the columns mean

Built / target - how many widgets finished before the time budget. A competitor that cannot mass-instantiate at this scale shows e.g. 240 / 10000 (timeout) - itself a result.
Build total (ms) - total synchronous time to build all the widgets (the deliberate yields that keep the page responsive are excluded). One run, not a median: at this scale the signal dwarfs the noise.
DOM nodes (resting) - element nodes left under the scratch area after building, popups closed. llselect builds no option DOM until a popup opens, so this shows its lazy-render footprint.
Teardown total (ms) - synchronous time to destroy() every widget just built (the mirror of Build total). A library that leaks listeners or unwinds slowly shows here. Measuring it clears the scratch area, so the widgets appear during the build and are gone after. Like Build total it is one run, and a timed-out library tears down only what it built.

Filtering is measured in the interaction-latency section below, not here - it is about one widget, not about building many.

Comparison chart

Each metric is shown relative to its own best performer (100% = winner, longer is better), so they share one axis. Click a legend entry to show or hide that metric; hover a bar for the real value. Throughput stays fair even when a library timed out (it is a per-widget rate, not a total).

Run a scenario to see the chart.

Scratch area (widgets build here during a run, then the teardown measurement clears them)

Interaction latency

These numbers are best-effort, not a guaranteed-fair ranking. The libraries differ too much under the hood to time identically:

some debounce the filter input, with no setting to turn it off;

some animate almost everything - the popup opening and closing, tags appearing and being removed - and some of that runs on a JavaScript timer that disabling CSS animation cannot reach;

some do their work in a microtask (queueMicrotask / a Promise.then), others in a macrotask (setTimeout);

some paint on the next requestAnimationFrame rather than synchronously;

some phases a library's API simply does not offer (shown as n/a).

The harness normalises what it can (see Fairness) and times to the painted frame / settled DOM, but treat small gaps as noise. That is why the measured widgets are left live below - open, filter and select them yourself to feel the real latency, rather than trusting a single number.

The other axis: one dedicated widget per library. Each operation is timed separately (never mixed), so one phase's cost never leaks into another's - opening a big list in isolation is where llselect builds its option DOM (it renders nothing until you open). The widgets stay live below; click them yourself too. Native <select> is not in the tables: its dropdown is browser / OS-driven, so the page cannot time its open / filter / close, and what JS can measure (setting a value) is ~0 - no discriminative value, and it would hide the real latency you feel. Its widget is kept live below so you can open and scroll it by hand and judge that for yourself.

"Build + measure" fills that mode's table; or click one library to (re)measure just it, leaving the rest. Stacked chart: the whole bar is the sum of the phases (shorter is better), each segment a phase; click a legend entry to show or hide it. Details of how each phase is measured are under "What the columns mean" below each table.

What the columns mean

Open popup - timed once: the FIRST open, which builds the popup's option DOM (for a big list this is where llselect builds its option DOM - it renders nothing until you open). Not a median of repeats, because a library that keeps the DOM on close has cheap warm reopens that would hide the build cost: Slim Select closes with a CSS scaleY(0) and never removes the option DOM, so its second open is nearly free - only its first open is honest. Timed to after the next paint.
Filter candidates - focus the search box and type q (narrows the list), then clear it: a round-trip reported as the SUM of both directions, five reps. It goes through each library's real search - including its debounce / throttle (Tom Select ~300 ms, Slim Select ~100 ms), which is latency the user really waits through. (Focus matters: Choices ignores an unfocused input, which is why this used to read ~0.) Timed to when the DOM settles.
Choose candidate - click a not-yet-chosen option in the open list - a real click, not an API select, so it does the work the user's click does. Multiple: click 10, the popup staying open. Single: click one (it closes), repeated.
Columns differ per mode. The single-select table stops at Open / Filter / Choose / Close (no tags, no in-popup unchoose). The multiple-select table adds the two deselect columns below.
Unchoose (in popup) - multiple only. CLICK an already-chosen option in the open list - with a full mouse sequence, because Select2's results fire on mouseup, not a synthetic click - and time the toggle-off. The harness checks the chosen count actually dropped and reads n/a if not. llselect, Select2 and Slim Select (with allowDeselect) deselect on click. Choices and Tom Select read n/a: their dropdown is add-only - clicking a chosen option just re-adds it. That does not mean they cannot deselect; they do it elsewhere - via the tag's x (the Remove-tag column), and Tom Select also via Backspace. (Tom would deselect from the list only with a plugin that turns every option into a checkbox.) All verified headless.
Remove tag (x) - multiple only, and only when test close button on multiple tags is ticked. CLICK each tag's remove (x) button and time the removal + re-render - the "press x to drop a tag" path. The option is off by default because Choices and Tom Select only grow a tag x through a setting / plugin (the others show one anyway), so forcing it on everyone would not be their default rendering; ticking it enables the x on those two and reveals this column.
Close popup - open first, then time closing.
Timing. Open / close are timed to after the next frame is painted (two requestAnimationFrames + a forced layout): Choices reveals a display:none list whose real cost - laying out and painting N options - lands on the frame, not in the synchronous call, so a plain timer reads ~0 (floor ~one to two frames). Filter / choose are timed to when the DOM settles so debounced renders count. Transitions / animations are disabled during a run so a CSS transition (Slim Select) is not counted as work. Median of a few repeats (first dropped as warm-up). Native <select> is not in the tables (browser-driven dropdown, nothing meaningful for JS to time) - its live widget is below to try by hand.

Single-select

Build + measure to see the chart.

Multiple-select

Build + measure to see the chart.

Fairness: making every library do the same work

The point of a comparison is that every library is measured doing the same work, timed the same way, with no library flattered by an artifact of how it renders. These are the rules the harness enforces (each one fixes a real trap hit while building this - see docs/llm/SPEC_BENCHMARK.md for the gory detail):

In the interaction tables above, a ^* in a cell means that one number involved per-library tuning - hover the star for a short explanation; the full per-library list is in docs/llm/BENCHMARK-LIBS-TUNE-FOR-FAIRNESS.md.

Minified vs minified. Every library loads its minified build, llselect included (its UMD is run through terser), so parse and build cost are compared like for like - not one library's dev build against another's .min.js.
Everyone renders all N candidates. Tom Select caps the dropdown to 50 options by default; it is forced to maxOptions: null so it builds the whole list like the others, instead of a fraction that looks fastest for free.
Selected options stay in the list. Choices and Tom Select drop a chosen option from the dropdown by default, so choosing one shrinks their list and they re-render less than llselect / Select2 / Slim Select (which keep it and just re-mark it). They are set to keep it (renderSelectedChoices: 'always' / hideSelected: false) so every library re-renders the same-size list while you choose and filter.
Timed to the painted frame, not the function return (open / close). Libraries reveal a display:none list on a later requestAnimationFrame (Choices), so the real cost - laying out and painting N options - lands on the next frame, not in the synchronous call. The timer waits for that frame to actually paint. This is exactly the "the benchmark says fast but I can see it hang" case: a library cannot look instant while you are still waiting for the list to appear.
Debounce is measured, not hidden (filter / choose). Tom Select and Slim Select debounce the filter input. Rather than disabling the debounce (which would hide latency the user really feels), the timer watches the DOM and waits until it stops mutating, so the debounce delay is included - and a debounced render is never mis-read as 0 ms. llselect filters synchronously.
Transitions and animations are disabled during a run. An injected * { transition: none; animation: none } means a CSS open / close animation (Slim Select) is not counted as work - the number is the render, not the tween.
Widgets are measured on-screen. llselect refuses to open an off-screen trigger (a real-use correctness guard), which would read ~0; so each widget is scrolled into view first, and manual scrolling is blocked by the run overlay so a stray scroll cannot move one off-screen mid-measure.
Each phase is timed on its own. Open, filter, choose, unchoose, remove-tag and close are measured separately, never in one mixed cycle, so one phase's cost never leaks into another's. Median of a few repeats, the first dropped as warm-up.
Multi renders tags. llselect uses triggerDisplay: 'tags' so it draws one tag per chosen item like every competitor, not its cheaper count summary.
No collapsing tags into a summary. Slim Select shows a single "{n} selected" tag once more than maxValuesShown (default 20) items are selected - one node instead of n. It is set to maxValuesShown: Infinity so it renders one tag per selected item like the others; otherwise its multi DOM-node count and its tag / choose work would collapse to near-nothing past 20 selections.
Multi keeps the popup open on choose. Select2, Tom Select and Slim Select are configured (closeOnSelect / closeAfterSelect) so choosing does not close the dropdown and skip the open-list re-render that the others pay for.
Filter keystrokes are always real changes. The query is cleared between timed keystrokes, so re-typing the same letter is never a no-op (some libraries keep the query after a selection, which would read 0).
Deselect is enabled from each library's own API, not assumed. Unchoose-in-popup uses Slim Select's allowDeselect; where a library genuinely cannot deselect from the open list (Choices, Tom Select) the phase is n/a, detected by checking the chosen count actually dropped - never timed as if a no-op click worked.
The tag close button is opt-in. Choices and Tom Select only grow a tag x through a setting / plugin, so it is off by default (each library's own tag rendering) and forced on for all only when you tick the box.
The custom renderer reaches the chosen display too - or is marked. The icon is added to list items and tags / triggers. Slim Select's v2 tag has no per-tag HTML hook, so its tag stays plain rather than being faked with a free CSS ::before; the limitation is documented, not hidden.
The chart is drawn only after a run. Animating a chart between libraries polluted the next library's timing, so it is deferred to the end.
Adapters are guarded. A library the adapter cannot drive on its loaded version shows - / error for that cell instead of breaking the page or silently reporting a wrong number.

Bundle size

Minified transfer bytes, uncompressed - the same method for every script: each cell fetches the library's minified UMD build live (competitors from the CDN, llselect its own dist/index.umd.js - the very script this page runs) and reports the byte length; gzip shrinks them all by roughly 3x. llselect's number is the complete usable library: the built-in English UI strings are inside it, and the optional dist/i18n.umd.js (every other language pack) is neither required nor counted. Select2 also requires jQuery, listed separately.

Script	Version	Minified bytes

Method and caveats

Widgets are built in small chunks with a yield between them, so the page stays responsive and a runaway library can be cut off at its time budget. A forced reflow ends each build so deferred layout is not hidden. Tick no timeout to build every widget regardless (it may take minutes or run out of memory).
The chart defaults to throughput (widgets built per second) because that stays a fair comparison even when a library timed out - it is a per-widget rate, not a total. Switch the metric to compare init time or DOM nodes instead; a bar from an incomplete run is shown in amber with its built count.
Every widget is independent - its own chosen state, no cross-widget interaction (that would be an integration test, not a render stress test).
Libraries render differently, which is the point of the DOM-nodes column: llselect lazy-renders options on open; Tom Select caps rendered options; Choices, Select2 and Slim Select render eagerly. None is cheating.
The custom-renderer variant adds one MDI icon per item through each library's item-render hook, and to the chosen display too (llselect tag / trigger, Select2 templateSelection, Tom Select render.item, Choices HTML label). Slim Select limitation: its v2 multi tag is textContent = option.text with no per-tag HTML hook, so the icon reaches its dropdown options but its tags stay plain text. A CSS ::before could fake the look but that is free compositor work, not the per-tag rendering the others do, so it is deliberately not used - Slim Select simply does less tag work here, which its Choose number reflects. This benches a plain filterable select otherwise; tagging, remote data and templating are out of scope.
A "-" or error means the adapter could not drive that library on the loaded CDN version - tell me which cell.
Versions under test:

Hands-on playground

Not a benchmark: nothing is measured here. Each library just builds one live single-select and one live multi-select with n candidates, so you can judge the feel yourself - open, filter, choose, scroll - and reproduce environment-specific issues (pinch-zoom alignment, IME, screen readers) against every library at once.