I should probably post the code for my n-gram fuzzy search with an inverted index. Without tests, the entire code fits on a single screen (I love ClojureScript). It works on the backend (JVM) and the frontend (Javascript) and has been in production use for the last [checks notes] 8 years.
Show HN: Frontend Fuzzy Search
21–30 of 38 posts
Re: Show HN: Frontend Fuzzy Search
#22Looks like a neat library. I’m curious if there’s a tl;dr on how this is better or different to Fuse, which is a very popular established client side fuzzy searching library. https://github.com/krisk/fuse
I had a similar question. I've been using fuse for years and have had almost no qualms with the data it returns after some light tuning.
Re: Show HN: Frontend Fuzzy Search
#23Thank you. We need more libs like that. I just researched the field yesterday and https://github.com/leeoniya/uFuzzy looked pretty good. But there is a gap in the market of such libs. Just few allow to send the whole html document, serialize and deserialize index to be used in browser, highlighting the matches is desired feature.
Most importantly very few fuzzy search libs can get a simple substring match as a priority, which is understandable but not helpful. Imagine searching for “xample” and not having “example” among the results.
Re: Show HN: Frontend Fuzzy Search
#24Great library, thanks for sharing it. As someone else mentioned, perhaps looking into WASM if you have time might be interesting. One DB that has been getting in this space is DuckDB, which recently announced WASM support for extensions like full-text search [1]. On the other hand, I haven't seen it in practice to check if it is a good benchmark or if it has different use cases.
[1] https://duckdb.org/2023/12/18/duckdb-extensions-in-wasm.html
Re: Show HN: Frontend Fuzzy Search
#25I should probably post the code for my n-gram fuzzy search with an inverted index. Without tests, the entire code fits on a single screen (I love ClojureScript). It works on the backend (JVM) and the frontend (Javascript) and has been in production use for the last [checks notes] 8 years.
Please do, that would be awesome.
Re: Show HN: Frontend Fuzzy Search
#26Thank you. We need more libs like that. I just researched the field yesterday and https://github.com/leeoniya/uFuzzy looked pretty good. But there is a gap in the market of such libs. Just few allow to send the whole html document, serialize and deserialize index to be used in browser, highlighting the matches is desired feature. Most importantly very few fuzzy search libs can get a simple substring match as a priori…
Thank you for your comment! It is indeed a problem in plain fuzzy search libraries (like this one) that substring matches can have a lower quality than unequal strings of similar length. A solution to that is to implement a higher level search controller that queries the fuzzy searcher, as well as a suffix array searcher. The controller than mixes the matches and returns the best matches across the two searchers. One can even add more searchers, e.g. a phonetic one. With the correct parameters this approach works well.
Re: Show HN: Frontend Fuzzy Search
#27oh very cool. would love to see the comparison/benchmark against the library I've used in projects for years (Fuse - https://github.com/krisk/Fuse).
Keep up the great work!
Re: Show HN: Frontend Fuzzy Search
#28Looks like a neat library. I’m curious if there’s a tl;dr on how this is better or different to Fuse, which is a very popular established client side fuzzy searching library. https://github.com/krisk/fuse
I had a similar question. I've been using fuse for years and have had almost no qualms with the data it returns after some light tuning.
Glad to hear that it works well, will look into it.
Re: Show HN: Frontend Fuzzy Search
#29Earlier quoted context omitted.
What is your definition of "accuracy" within the context of fuzzy search?
It's subjective, I have to admit. I would say a search is accurate if most people find what they are looking for in their dataset in the first try. Distance definitions such as the Levenshtein and Damerau-Levenshtein distances provide a solid basis for discussions on accuracy. However, they are costly to compute and hence not widely adopted in fuzzy search libraries. I started by using the known filter equation for t…
> It's subjective, I have to admit. I would say a search is accurate if most people find what they are looking for in their dataset in the first try.
I'd say a search is accurate if it finds what most closely matches the query, for some definition of "matches". A search is useful if most people can find what they are looking for on the first try.
That is, a search being accurate doesn't necessarily translate to usefulness, if people don't (or can't) know how to write those accurate queries.
I'd imagine this is why fuzzy searches exist. Fuzzier queries allow for a larger spectrum of possible matches, which means a larger set of queries can turn up those results someone is looking for. Queries do not have to be as precise, and writing useful queries is easier.
But to me it seems diametrically opposed to accuracy. Usefulness is a much more intuitive measure, because the query does not have to be perfectly accurate in order to find the right result.
Alternatively, you could focus on the quality of ranking of the returned matches: how often the correct result is near the top (and how near) when the user finds what they are looking for. Ideally you want this as high as possible.
Re: Show HN: Frontend Fuzzy Search
#30Any comparison data with https://github.com/nextapps-de/flexsearch?
Also what player are using to play/pause gif in your readme?