LLSelect - Low-Level Select
A low-level JavaScript library aims to be an alternative of <select>.
This is a low-level <select>-liked component library written in TypeScript. Focus on performance and flexibility. You can easily wrap and integrate into your existing UI library / framework / style.
[!TIP]
Why not native <select>?
Native <select> was designed in the 1990s, and the lots of limitations have caused innumerous indescribable discomfort to OCD developers and designers for over two decades:
- Unable to customize the HTML template of
<select>, <option>, <optgroup> Behavior of dropdown are platform-dependent (popup/dropdown list are OS-native controls, which are rendered by system instead of browser)
- No filter feature, especially for East-Asian languages.
- Values can only be stored as
string.
- Unable to accept mouse event when
<select disabled="true"> (to show tooltip to explain why it's disabled, for example).
Arrrrgh... Yet another select library? Why not existing select libraries? Are you too bored?
Yeeeee, it's just because all of the existing libraries are unable to satisfy my requirements, mainly on aspect of performance (initializing hundreds of instances), then flexibility, and explicitly.
At least as of May 2026, this situation was still not solved. The only way was implement one to fit my ideal.
It's AI era! Why a library instead of using LLM agent to write an ad-hoc select component directly?
If you are sensitive enough, you should know a select component is a terribly long-tailed piece of UI. Lots of detailed behaviors and edge cases that you won't want to waste time to struggle with. Includes but not limited:
- ARIA (detailed behavior of keyboard navigation,
lang attribute... etc)
- Popup width, layout and position on small-sized screen, or items containing long text content.
- CJK characters and layout problem (ex: unexpected newline).
- System and browser compatibility (Desktop / Mobile / Touchscreen; Firefox / Chromium / Safari)
[!WARNING]
I know Semantic Versioning, but the API of versions < v0.1.0 is unstable currently and may have breaking changes. I'm still trying to eat my own dog food in real-world projects and trying to make the API stable. Thanks for your understanding.
Contents
Features
- No external JS / CSS dependency.
- Fast where it is measured: mass instantiation is sometimes even faster than native
<select> (see Benchmark).
- Does not rely on a native
<select> and its string to store data: use number, customized object or any JavaScript value as the data model directly, without type-casting hell.
- Native TypeScript support.
- Customizable HTML renderer functions.
- Search candidates in input, friendly for Eastern-Asian languages.
- ARIA, A11Y and keyboard support, including native-style prefix typeahead.
- I18n packages and RTL languages support.
[!WARNING]
Browser support floor: Firefox 78+, Chrome/Edge 87+, Safari 14.1+. No polyfills or legacy-browser workarounds are included.
Design principles
- Minimalist
- No external JS / CSS dependency. Auditable.
- Do only one thing: "a minimal replacement of
<select>", not aimed to be an omnipotent monster.
- Performance
- Create minimal elements on DOM when instantiating to optimize the page loading latency.
- The DOM of popup and candidates are lazy-rendering, and remove unneeded element from DOM when unneeded to minimize memory usages.
- Mutate minimal DOM if possible. Toggling a candidate in the popup list replaces only the affected candidate rows and refreshes the trigger, instead of rebuilding the whole list. (Features that change which rows are listed or add a summary row -
hideChosenRows, chooseAllRow - rebuild or update those parts too.)
- Flexible
- Highly customizable: HTML templates of the select component itself, popup, candidates list, candidate row, arrow icon, ...etc.
- Easy to integrate into an existing project / library / style.
- Settings configure one instance; subclassing extends the library.
- Explicit
- Explicit is better than implicit - API names are long, but hold no surprise or ambiguity.
- Consistent & comprehensible API naming convention, avoid user from guessing the meaning of APIs.
- Single-select and multiple-select are separate classes, avoiding ambiguous / over-abstracted APIs (for example,
select2 uses T[] adopted on single & multiple modes.).
- Improves some UI/UX anti-patterns of the legacy
<select> (e.g. aria-disabled instead of native disabled, so a disabled control still receives hover events and can show a "why is this disabled" tooltip).
以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗
