Comparing Querylight TS to Other Browser Search Libraries

Browser-first search libraries optimize for different use cases.

This article summarizes the strengths and weak points of several widely used alternatives.

Note: this overview is not exhaustive.

• Fuse.js and GitHub repo
• Lunr.js
• MiniSearch
• FlexSearch
• Pagefind and GitHub repo
• Orama and GitHub repo
• search-index
• Stork and GitHub repo

This comparison explains why Querylight TS is positioned as the most feature-rich local-first option in this set for teams that want one browser-first toolkit to cover structured lexical search, aggregations, highlighting, vector retrieval, sparse retrieval, geo queries, and JSON-serializable index state.

High-level feature comparison

✓ = strong support, ~ = limited or partial support, × = not a core capability

Querylight TS

Querylight TS is a local in-memory retrieval toolkit with:

• fielded documents
• BM25 and TF-IDF ranking
• bool, phrase, range, term, prefix, and multi-match queries
• aggregations and significant terms
• highlighting
• JSON-serializable index state
• vector and geo search

Feature breadth is the main differentiator here, not a claim that every individual feature is the strongest possible implementation on performance, scalability, or algorithmic sophistication. Querylight TS is aimed at small local datasets where that tradeoff is often acceptable, and the project welcomes feedback and pull requests that improve feature quality, behavior, or performance.

Strong points:

• structured fielded retrieval
• BM25 and TF-IDF ranking
• bool, phrase, range, term, prefix, and multi-match queries
• aggregations and significant terms
• highlight support
• vector and geo search
• JSON-serializable index state
• no backend service required

Weak points:

• more moving parts than a fuzzy-only search library
• larger API surface than narrower search-box libraries
• some features are still new or experimental
• not widely used yet compared to older and more established alternatives
• intended for small local corpora rather than very large search deployments

Fuse.js

Links:

• Fuse.js website
• Fuse.js on GitHub

Fuse.js is widely used and excellent at fuzzy matching over in-memory JavaScript objects with very little setup. Its feature set is small, but well thought out.

Popularity: this is one of the most widely used libraries in this group, with about 20k GitHub stars.

Strong points:

• extremely fast to adopt
• great for typo-tolerant searching over small to medium object arrays
• widely used and easy to find examples for
• lower conceptual overhead for simple search boxes
• often the right answer when you only want fuzzy ranking over a few fields

Weak points:

• less structured than an index-based fielded search toolkit
• logical and structured search support is limited
• not designed around facets, aggregations, or filter-heavy search interfaces
• not a natural fit for vector or geo retrieval

Lunr.js

Links:

• Lunr.js on GitHub

Lunr is one of the classic client-side full-text search libraries. It is widely used, indexes JSON documents, and provides a compact browser search experience. Its feature set is relatively small, but it covers the basics well.

Popularity: this remains one of the more widely known libraries in the category, with about 9.2k GitHub stars. However, there has not been a stable npm release in the last year. The latest stable npm release is 2.3.9, published on August 19, 2020.

Strong points:

• mature and well-known static-site-search pattern
• simple full-text indexing model
• a familiar choice for classic docs-site search
• widely used and easy to evaluate against existing examples

Weak points:

• narrower query model
• structured query support is useful but limited
• less support for structured discovery features such as aggregations
• not aimed at vector or geo search

MiniSearch

Links:

• MiniSearch on GitHub

MiniSearch is a small full-text engine for browser and Node.js use, and it occupies a pragmatic middle ground between very simple fuzzy libraries and heavier search systems.

Popularity: this is a well-established mid-sized project in this group, with about 6k GitHub stars.

Strong points:

• compact API for full-text search
• strong fit for small-to-medium local corpora
• lower complexity if you mainly want lexical search, prefix search, fuzzy search, and field boosts

Weak points:

• more limited as a general retrieval toolkit
• less emphasis on structured query composition
• not positioned around geo or vector retrieval

FlexSearch

Links:

• FlexSearch on GitHub

FlexSearch is known for performance focus and flexible indexing structures for browser and Node.js search.

Popularity: this is one of the more popular libraries here, with about 13.7k GitHub stars.

Strong points:

• strong performance-oriented positioning
• broad indexing options
• attractive for search-heavy UIs where raw responsiveness is the main goal

Weak points:

• less centered on search-engine-style query semantics
• discovery features such as aggregations are not the main focus
• can be more about indexing speed and lookup performance than structured retrieval behavior

Pagefind

Links:

• Pagefind website
• Pagefind on GitHub

Pagefind is more of a static-site search system: it indexes built HTML ahead of time and ships a chunked search experience optimized for static websites.

Popularity: this libary is actively maintained, and has built meaningful adoption in the static-site segment, with about 5k GitHub stars.

Strong points:

• excellent fit for static documentation and content sites
• build-time indexing workflow
• chunked loading optimized for bandwidth
• strong default experience when your corpus is a generated site

Weak points:

• more specialized for generated static sites than general search application logic
• less about custom structured retrieval APIs
• not centered on geo, vector, or fielded discovery features

Orama

Links:

• Orama website
• Orama on GitHub

Orama is one of the more ambitious browser/server/edge search libraries and explicitly positions itself around full-text, vector, and hybrid retrieval.

Popularity: this is one of the larger newer projects in the group, with about 10.3k GitHub stars.

Strong points:

• stronger out-of-the-box positioning around modern semantic and hybrid search
• broader “search engine platform” ambition
• attractive if you want one library centered around AI-era search patterns

Weak points:

• broader platform scope can mean a larger conceptual surface area
• may be more than you need for straightforward local lexical search
• less specifically about a small Lucene-inspired local toolkit

search-index

Links:

• search-index on GitHub

search-index is a persistent full-text search library for browser and Node.js use.

Popularity: this is smaller than the most visible libraries in the group, with about 1.4k GitHub stars. There has not been a stable release in the last year.

Strong points:

• explicit positioning around persistence and browser-plus-Node portability
• a better fit when local index durability matters
• more search-engine-like than fuzzy-only libraries

Weak points:

• less current mindshare than Fuse.js, FlexSearch, or Pagefind
• less centered on vector, geo, or broader hybrid retrieval
• less obviously aimed at static-site search UX than Pagefind or Stork

Stork

Links:

• Stork website
• Stork on GitHub

Stork is a static-site search system built around a Rust indexer and a JavaScript plus WebAssembly frontend.

Popularity: this has a smaller but still visible footprint in static-site search, with about 2.8k GitHub stars. There has not been a stable release in the last year.

Strong points:

• purpose-built for static sites and search-box UX
• build-time indexing with a polished frontend integration story
• strong fit for Jamstack-style deployments

Weak points:

• more specialized than a general application search toolkit
• less relevant if you need custom structured retrieval APIs
• narrower project momentum than actively expanding options in this category

Other adjacent options

Two more adjacent options:

• TinySearch is another Rust and WebAssembly static-site search engine. It is closest to Pagefind and Stork, with more emphasis on small payloads and simple full-text search.
• Elasticlunr.js is a Lunr-derived library with a more flexible API.

Where Querylight TS sits

Relative to these libraries, Querylight TS sits in a fairly clear place:

• more complex to use, but also more feature rich
• intended for local corpora that still fit comfortably in browser or Node.js memory
• a practical way to combine lexical, structured, vector, and geo retrieval on the same set of documents
• a good fit for documentation sites, blogs, magazines, and similar content-heavy websites where local indexing and shipping JSON state are acceptable

Relative to Fuse.js, it offers a much richer retrieval model at the cost of more setup.

Relative to Lunr and MiniSearch, it adds more search-engine-style features such as bool queries, aggregations, and a path toward hybrid retrieval.

Relative to FlexSearch, it is less centered on raw lookup speed and more centered on structured retrieval capabilities.

Relative to Pagefind, it is less specialized for generated static sites and more flexible as an application-level search toolkit.

Relative to Orama, it is narrower in scope but easier to reason about if your focus is local structured retrieval instead of a broader search platform story.

Relative to search-index, it is more ambitious on query composition, aggregations, vector search, sparse retrieval, and geo support, while search-index has a clearer persistence-first story.

Relative to Stork, it is less specialized for Jamstack search-box deployments and more flexible if the same local index also needs to support filters, facets, vectors, or application-specific retrieval logic.

Relative to Solr, Elasticsearch, and OpenSearch, Querylight TS is intentionally much smaller in scope. That comparison does not just apply to Querylight TS; it applies to all of the browser- and local-first options discussed on this page. Full server-side search engines are far more sophisticated in terms of features, algorithms, optimization, and scalability. Querylight TS borrows more of that query-building style than most browser-first libraries covered here, but it is still aimed at a very different problem size.

Those systems are the right tools when you need serious search infrastructure at scale. Querylight TS is for the opposite end of the spectrum: situations where a small local corpus needs capable search features without the operational weight of running a full search server, and where those larger systems would be overkill. And beyond Solr, Elasticsearch, and OpenSearch, there are many server-side alternatives that are also designed for far greater scale than anything in this article is targeting.